>>>>... if you send, say, "ABC" as OOB, the end result is that "AB"
>>>>gets sends as normal data, and the "C" ends up as the OOB byte. ...
>>>OOB data is implemented using the TCP Urgent pointer. ...
>>... the sockets API [snips out] that last byte and shuffles it off
>>somewhere else ... but it leaves the others ("AB" in my example) inline
>>as normal data. Right?
Quote:>Correct. Since TCP doesn't have a way of indicating the start of urgent
>data, only the end, how is it supposed to know that "AB" should have been
>shuffled away as well? Remember, TCP is a byte-stream protocol, it doesn't
>have any way of indicating message boundaries, so there's no way for a
>receiver to know that "ABC" should be treated as a unit.
Indeed, there is a major disconnect between "urgent data" and "out
of band", and setting that "in line" option (snipped above) is
probably the best way to deal with the situation at all. The
"urgent pointer" in TCP is associated with each tcp segment, but
does it mean that *all* the data in that segment is "urgent", or
does it mean only that *some* of the data in that segment is
"urgent"? And in any case, this has no effect on type- or
quality-of-service at lower layers. Presumably, if data-set-X is
"more urgent" than data-set-Y, you would want it sent with a higher
You can achieve this by opening two separate sockets. Send "out
of band" data on the second (high-priority low-usage) socket, and
it will truly be out of band.
In-Real-Life: Chris Torek, Berkeley Software Design Inc