Rao Shoaib writes: > IBM: > http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzab6/rzab6coobd.htm > > The SIOCATMARK ioctl() request determines if the read pointer is > pointing to the last OOB byte. > Note: > If multiple occurrences of OOB data are sent, the OOB marker points to > the last OOB byte of the final OOB data occurrence.
That sounds to me like the historical BSD behavior, and since sockets are a BSD invention, I'd use their definition. (It's worth checking the on-line BSD source, of course.) > MSFT: http://msdn.microsoft.com/en-us/library/ms740102(VS.85).aspx [...] > *Note* When the SO_OOBINLINE socket option is set, the SIOCATMARK IOCTL > always returns TRUE, and OOB data is returned to the user as normal data. That's just wrong. Oh, well; Windows isn't our problem. > It seems that Solaris behavior of setting RCVATMARK for every OOB on the > way to the last OOB is incorrect. Agreed. > 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. A given TCP stream has at most one URG pointer. It points to a single byte of data that can be received as "out-of-band" if desired (no sane application ever does), but all data up to that point are considered "urgent." Remembering received URG pointers after the pointer has moved again makes no sense to me. Note that if the sender is stuck due to a closed window, the application may make multiple "urgent" writes that all end up advancing the URG pointer only once when the window opens up again, because only the latest pointer position is sent. This means that remembering them on the receive side as though they're distinguishable events is at best misleading. > We are reimplementing sockets as part of project Volo and would like to > get the correct semantics without breaking any applications. So we are > looking for input or a pointer to a standard that specifies the socket > semantics in these cases. Use the source: go check 4.4BSD behavior. ;-} -- 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]
