Consider the following scenario:
A and B have a TCP connection. A sends B four bytes, then an OOB byte,
then another four bytes, and finally another OOB. Only then process B
reads the data. (without OOB inline).
Under BSD the first OOB byte is lost forever, and process B will
read 8 bytes before stopping at the second OOB, and nothing else (but
naturally the second OOB itself with MSG_OOB flag in recv()).
Under Linux, the first OOB byte is inserted into the stream (!) and
thus process B will get 9 bytes before the second OOB. This would
still happen EVEN IF process B ALREADY read the first OOB byte but
did not yet consume the data prior to it (thus - the first OOB is
received twice: once as OOB and once in stream).
The reason for the difference is the following: In BSD, whenever an OOB
byte arrives it is immediately taken out of the stream (unless OOB_INLINE
is specified) so there is no need for special handling in the regular
receive routine. This byte is saved in a special field (so it can be
retrieved later by the process). In Linux, it is not removed from the
stream, but instead a special field holds its sequence number, and the
receive subroutine takes care of not copying this byte to the user. Thus,
when a second OOB arrives before the entire data prior to the first OOB is
consumed, the field is overwritten by the new value, and the old byte
remains as a regular byte in the stream (EVEN IF IT WAS CONSUMED BY THE
PROCESS, as long as data prior to it in the stream is still buffered).
It seems like the behaviour the TCP stack in Linux broken (or I missed
something in the RFC). In that case, the fix would naturally be to change
the code to either (1) work like BSD and remove the byte from the stream
or (2) keep multiple OOB pointers (which is expensive and complicated).
Comments ?
Oren.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/