braden@VENERA.ISI.EDU (05/26/90)
From tcp-ip-RELAY@NIC.DDN.MIL Fri May 25 01:59:41 1990 Date: 24 May 90 14:20:20 GMT From: matrix!venkat@uunet.uu.net (D Venkatrangan) Organization: Matrix Computer Systems, Nashua, NH Subject: TCP Urgent Mode. Sender: tcp-ip-relay@nic.ddn.mil To: tcp-ip@nic.ddn.mil I am looking for ways to determine where exactly in the sequence space at the receive side, Urgent Data begins. The RFC793 on Transmission Contol Protocol does not appear to be very clear on this. TCP also provides a means to communicate to the receiver of data that at some point further along in the data stream than the receiver is currently reading there is urgent data. TCP does not attempt to define what the user specifically does upon being notified of pending urgent data, but the general notion is that the receiving process will take action to process the urgent data quickly. The above paragraph describes the general philosophy. Urgent Pointer: 16 bits This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence number of the octet following the urgent data. This field is only be interpreted in segments with the URG control bit set. Does this mean than Urgent Data starts at the beginning of this segment and extends up to current segment's sequence number + urgent data pointer? Yes. Up to, but not including. See RFC-1122 p. 84 for more info. This again describes when "urgent mode" starts, but not where urgent data starts. Do users of TCP, such as Telnet, agree on how many bytes of urgent data exist and thereby know the start of urgent data? Urgent data starts as soon as an Urgent Ptr appears. Is there an update to RFC793 since Sept. 1981 that describes changes if any to the TCP urgent mechanism? If one were to implement the TLI API on top of TCP and were to provide the t_rcv(fd, buf, nbytes, flagsp) call, how would they be able to provide T_EXPEDITED data? TLI appears to treat normal and expedited data as two independent streams. Thanks. It's not clear you can map TCP urgent into a user interface that has two independent streams. The essential piece of information that the receiving application has to be able to get is: How many bytes of urgent data remain to be read? As long as the answer is non-zero, the application has to be in "urgent mode"; when the result reaches zero, normal mode resumes. Bob Braden
guy@auspex.auspex.com (Guy Harris) (05/26/90)
>If one were to implement the TLI API on top of TCP and were to provide the > > t_rcv(fd, buf, nbytes, flagsp) > >call, how would they be able to provide T_EXPEDITED data? TCP doesn't really have expedited data in the same way that, say, TP4 does; it has an urgent pointer. >TLI appears to treat normal and expedited data as two independent streams. Yup. S5R4's streams code implements the notion of a "marked" message for precisely that reason; that's how it handles the urgent pointer. It may also support the notion that the last byte of urgent data is treated as expedited data, as per, say, 4.2BSD, and 4.3BSD when SO_OOBINLINE isn't set.