Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!mit-eddie!uw-beaver!uw-june!ka From: ka@june.cs.washington.edu (Kenneth Almquist) Newsgroups: comp.unix.wizards Subject: Re: BSD:sockets::SVID:(what?) Summary: No such thing as out of band data in TCP Message-ID: <5252@june.cs.washington.edu> Date: 10 Jul 88 04:33:19 GMT References: <379@halley.UUCP> <1093@nusdhub.UUCP> <6844@ico.ISC.COM> Organization: U of Washington, Computer Science, Seattle Lines: 49 > These are mostly nits, but sockets have these capabilities and I've > hit them all while trying to port applications from a socket > environment to TLI. The one case that TLI doesn't even have even > close to the mechanism that sockets have is in the case of TCP urgent > data. This almost maps to expedited data, but expedited data is > in-band. There is no way to signal the process that this data has > appeared in the data stream until it reaches the front of the Stream > head. Sockets provide a signal for async notification and an ioctl to > query. It makes it difficult to use urgent data for things like data > stream flushing if you can't detect the urgent data until you read it. TLI includes support for "out of band" data which has priority over normal data. My streams manual is back in New Jersey, so I can't check whether it provides notification via signals, but some sort of support for this feature is there. It is not usable with TCP because the TCP protocol does not include a facility to permit out of band data. The urgent data pointer in TCP is intended to allow all the data written up to a given point to be made available to the receiver as soon as possible. The Berkeley sockets facility, unlike TLI, does not allow the user to determine whether the underlying protocol supports out of band data. Probably for that reason, the Berkeley TCP implementation includes limited support for out of band data. The idea they used is that since their implementation of TCP makes all data available to the receiver as soon as it arrives, the intended function of the urgent data pointer is not needed with their implementation. They therefore decided that, when the user specifies that a block of data is to be made available to the user as soon as possible, the last byte of the block should be treated as out of band data. This is a poor way to implement out of band data. In particular flow control on normal data will also hold back the "out of band" data, which destroys one of the main reasons for having out of band data in the first place. It is not hard to implement out of band data on top of TCP. Multiplex the out of band and regular data onto a single TCP connection using some scheme to allow you to distinguish between the two. Make your program read data as the data arrives, using SIGPOLL. The out of band data can be processed directly inside your signal handler for SIGPOLL, while in band data can be put on a queue. Reading the data when it arrives will keep the flow control in TCP from going into effect. Implement your own flow control for in band data only by acknowledging in band data as it is processed. An alternative is to use two TCP connections, one for in band data and the other for out of band data. In any case, there is in my view little justification for using nonstandard extensions to TCP to get out of band data since this feature can be build (with a few deficiencies relating to retransmission) on top of standard TCP. Kenneth Almquist