Connected: An Internet Encyclopedia
RFC 1122 - 4.2.2.4 Urgent Pointer: RFC-793 Section 3.1

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1122
Up: 4. TRANSPORT PROTOCOLS
Up: 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP
Up: 4.2.2 PROTOCOL WALK-THROUGH
Prev: 4.2.2.3 Window Size: RFC-793 Section 3.1
Next: 4.2.2.5 TCP Options: RFC-793 Section 3.1

### 4.2.2.4 Urgent Pointer: RFC-793 Section 3.1

The second sentence is in error: the urgent pointer points to the sequence number of the LAST octet (not LAST+1) in a sequence of urgent data. The description on page 56 (last sentence) is correct.

A TCP MUST support a sequence of urgent data of any length.

A TCP MUST inform the application layer asynchronously whenever it receives an Urgent pointer and there was previously no pending urgent data, or whenever the Urgent pointer advances in the data stream. There MUST be a way for the application to learn how much urgent data remains to be read from the connection, or at least to determine whether or not more urgent data remains to be read.

DISCUSSION:

  Although the Urgent mechanism may be used for any application, it is normally used to send "interrupt"- type commands to a Telnet program (see "Using Telnet Synch Sequence" section in [INTRO:1]).

  The asynchronous or "out-of-band" notification will allow the application to go into "urgent mode", reading data from the TCP connection. This allows control commands to be sent to an application whose normal input buffers are full of unprocessed data.

IMPLEMENTATION:

  The generic ERROR-REPORT() upcall described in Section 4.2.4.1 is a possible mechanism for informing the application of the arrival of urgent data.

Next: 4.2.2.5 TCP Options: RFC-793 Section 3.1

Connected: An Internet Encyclopedia
RFC 1122 - 4.2.2.4 Urgent Pointer: RFC-793 Section 3.1