Re: Behaviour of OOB in TCP ?

Mattias =?ISO-8859-1?Q?Engdeg=E5rd (f91-men@nada.kth.se)
Thu, 29 Apr 1999 19:04:50 +0200 (MET DST)


>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).

This sounds dubious, but BSD's behaviour of losing the first urgent
byte isn't always desired either. On the other hand, any application
not tolerating loss of urgent data will probably use SO_OOBINLINE
(telnet, for example). It is hard to say if the Linux behaviour is
erroneous

>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).

It doesn't work that way; OOB data isn't mapped well onto TCP's notion of
urgent data, so it should not be used as such. Use a separate socket for
real out-of-band data.

While we're on the topic, I think the bug^H^H^Hinteroperability issue
with Solaris 2.6 merits the minimal attention it requires. I suggested

--- net/ipv4/tcp_input.c.orig Wed Mar 17 21:39:13 1999
+++ net/ipv4/tcp_input.c Sat Apr 24 21:36:57 1999
@@ -1621,7 +1621,7 @@
struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp);
u32 ptr = ntohs(th->urg_ptr);

- if (ptr && !sysctl_tcp_stdurg)
+ if (!sysctl_tcp_stdurg)
ptr--;
ptr += ntohl(th->seq);

but received no answers from wiser people, so I don't know whether this
was correct or outrageously stupid. I can't find any faults with it,
and it "works well here".

-
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/