Rao Shoaib writes: > James Carlson wrote: > > Rao Shoaib writes: > > > >> It is also not clear if a read can > >> consume intermediate OOB bytes and what the behavior should be when > >> SO_OOBINLINE is set/cleared while OOB bytes are pending. > >> > > > > They ought to become ordinary bytes if a second URG pointer is > > received. > > > This seems to be true only for the inline processing case else the byte > is over written.
The simple answer (to me at least) is that the out-of-line processing scheme is just crack-headed. ;-} Applications built on that model are likely not terribly portable, and probably don't do what the original author intended or expected anyway. > I agree, Since sockets semantics should not be tied to TCP behavior I I'm not sure I get that "since." Sockets were developed by Berkeley to use with TCP/IP ... right? What other out-of-band mechanism matters here? I suppose that if you're designing a generic sockets layer and you're assuming that some new transport will come in and take over for TCP, despite the 26 year head start it's got, then it might make some sense to aim for some more generic definition ... but specifically when used with TCP, I argue that it should certainly follow the defining model, which is BSD. The "generic" form could do otherwise, if it wanted. > wanted to make sure that other protocols that use urgent data and might > use our code to build their sockets will work. I guess I find it hard to worry about those other protocols. > Actually Volo currently implements BSD semantics, but some discussion > led us to look at the code and we realized the difference in semantics > and hence the search for a standard. Since there does not seem to be a > published standard for handling OOB data we will go with BSD semantics > and if something breaks we will deal with it when it happens. OK; sounds good. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
