If there are multiple OOB data bytes outstanding, Currently Solaris
sets RCVATMARK for every OOB data byte, However it only returns the
last OOB data byte when OOB data is read (SO_OOBINLINE is not set).
Solaris documentation does not seem to specify what the behavior should
be. However it seems other OS's have different behavior.
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.
MSFT: http://msdn.microsoft.com/en-us/library/ms740102(VS.85).aspx
With SO_OOBINLINE enabled, the urgent data remains in the data stream.
As a result, the OOB data block is never lost when a new TCP segment
arrives containing urgent data. The existing OOB data mark is updated to
the new position.
*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.
It seems that Solaris behavior of setting RCVATMARK for every OOB on the
way to the last OOB is incorrect. 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.
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.
Thanks,
Rao.
_______________________________________________
networking-discuss mailing list
[email protected]
