Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.tcp-ip Subject: Re: TCP Urgent Data Handling Message-ID:Date: 28 Sep 89 23:02:17 GMT References: <4982@omepd.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 20 The urgent bit is sort of odd. Your questions suggest that you want to be able to tell exactly what data is urgent and what isn't. That's not really what the original intent was, I don't think. There are no "messages" in TCP, nor is there any intent in the spec to define where urgent data begins, only where it ends. Urgency is intended to indicate a condition that takes effect immediately. Its beginning is not synchronized with the data stream. Thus urgent should be set in the next datagram to be sent, even if it is a retransmission and did not have urgent set last time. (This may be hard to implement of course, and as far as I know is not. But conceptually it would make sense, and it would improve some aspects of telnet and rlogin behavior.) Furthermore, if two sections of "urgency" are adjacent, they may look like one. Both of the uses of urgent data that I know -- telnet and rlogin -- are designed with these concepts in mind. This means that the concept of "urgent message" is not well defined. Only the concept of "last urgent byte" makes any sense, and with the off by one fiasco, even that is ambiguous. I would suggest that you *not* try to "clarify" urgent, but stick with the 4.3 semantics. Anyone who needs urgent "messages" should arrange to delimit the messages by some sort of marker in the data.