4.3 BSD out-of-band handling

Richard Fox rfox at tandem.Tandem.com
Thu Aug 3 09:32:53 AEST 1989


I have been looking at how 4.3 handles out-of-band data. After reading
the  "The Design and Implementation of the 4.3BSD UNIX Operating System"
there seems to be a discrepancy between the implemtation and the documentation
in the book.

In the book it says that if more than 1 byte of out-of-band data is sent
and ready to read when the user issues a read with the MSG_OOB flag set
then all of the data is passed up at once. However, looking at the code
shows that there is 1 byte in the socket structure for out-of-band data
and the rest of the data is stored on the normal socket buffer rcv_cc.
Thus, when you issue a read(MSG_OOB) you get only 1 byte. If 4 messages
with out-of-band data arrives before a read then the byte is over-written 
3 times. The rest of the out-of-band data is stored properly as normal
data. 

Another problem I have seen is an inconsistency on which byte is stored
in the socket structure as the out-of-band data. Sun 3.5 seems to store
the first byte while the lastest sun 4.0.x.x.x.x.x stores the last byte.
This inconcsistency should be clarified so future implementations can agree.


I would like to see either the book (in the next edition) change to truly
reflect what is implemented, or have the next release of unix agree more to
the book. I realize that most applications do not send more than 1 byte of
out-of-band data (partially due to the sun problem mentioned above) and this
inconsistency of the code versus book isn't very important but we are starting
to have users develop applications that do send more than 1 byte of OOB. I
think its a gross error to read data as OOB and treat it as normal data unless
the user has explicity asked to do so.


Are there any opinions out there as to how unix should handle OOB data and
does anybody have any idea if Berkeley is going to change the code of the
book? All comments are welcomed.


thanks Rich
rfox at tandem.com
(408)865-4420



More information about the Comp.unix.wizards mailing list