Messages in this thread | | | Subject | Re: Behaviour of OOB in TCP ? | Date | Thu, 29 Apr 1999 12:26:17 -0700 | From | Craig Milo Rogers <> |
| |
>> It doesn't work that way; OOB data isn't mapped well onto TCP's notion of >> urgent data, so it should not be used as such. Use a separate socket for >> real out-of-band data. > >Basically you are right. But the real problem with the Linux way of >handling is this: if your application has an internal protocl (over TCP) >, like in a client-server paradigm, and it ALSO uses urgent data (which >is translated to OOB) -- then there is a problem ! Suppose the server >uses OOB to notify the client of some event. If that byte get into the >"normal" stream - it corrupts the "normal" data and breaks the internal >protocol.
As I said, before: TCP, as originally specified, does not directly support out-of-band data; it supports "urgent" data (using its own semantics for "urgent"). If an application has "urgent" data (matching the TCP semantics), then it shouldn't attempt to translate it to OOB data (as you suggested above) before sending it via TCP! If an application wants out-of-band data, it *must* encode the data in-band, using an appropriate mechanism (escape sequence, octet count, flattened structure). Please read the TELNET Options RFCs for details on one way to do this (note: if the BSD folk had kept the TELNET option encoding, but not the negotiation, the world might have been a happier place).
A simple way of putting this is that multiplexing "OOB" and "normal" data in a single stream is simply not a service provided by TCP (as originally defined). An application that expects TCP to provide this service is mistaken.
Craig Milo Rogers
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |