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.
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.
I agree, Since sockets semantics should not be tied to TCP behavior I
wanted to make sure that other protocols that use urgent data and might
use our code to build their sockets will work.
Use the source: go check 4.4BSD behavior. ;-}
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.
Jim thanks for your comments.
Rao.
_______________________________________________
networking-discuss mailing list
[email protected]
