[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear poll(2) status
The following reply was made to PR kern/54435; it has been noted by GNATS.
From: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear poll(2) status
Date: Sun, 04 Aug 2019 13:08:17 +0700
Date: Sun, 4 Aug 2019 04:40:01 +0000 (UTC)
From: mlelstv%serpens.de@localhost (Michael van Elst)
| If anyone would actually use urgent data, we would probably
| have a different interface. Then we wouldn't be limited to
| a single byte either. TCP after all doesn't impose such
| a limit.
I am sure that many of you already know this, perhaps all of you,
but TCP has no concepy of OOB data at all, in the (sending side of)
the test program:
send(client, "b", 1, MSG_OOB);
does not send "b" as out of band data, it cannot, as TCP has
no method to do that. What it does is send "b" and also set
the "urgent" pointer to the position in the stream immediately
after the 'b'. If anything can be said to be sent OOB it is
that urgent pointer position - that arrives at the receiver with
the very next packet sent (or even resent), regardless of how
far back in the transmit queue "b" happens to be.
The model is that the receiving application is being informed
that there is something important, something that it will want
to notice soon, coming in the data stream, and so it should
read the data as fast as possible until it has processed that
urgent data, and then, if appropriate, go back to really process
all of the data that was skipped while looking for the urgent
part, The only assistance TCP provides for finding that urgent
data is that it stops telling the receiving data that there is
some coming after the receiver has read past the location of the
urgent pointer - beyond that it is all up to the applcation protocol
to define a method to determine just what the data that is supposed
to be urgent was.
The sockets API attempted to provide a mechanism to make this
possible, and relatively easy to handle in code, while also allowing
the same interface to handle the "out of band data" mechanism in
transport protocols that actually have a concept of that (like
everything ultimately derived from HDLC: X.25, OSI TP, ...)
For TCP, the OOBINLINE method is clearly the right one, all TCP
data is simply sequential TCP data, all that matters is that the
receiver is told when some urgent date is coming in the future
and when the read pointer has read past that urgent pointer, so
whatever data was urgent has now been received.
So, there is really no concept of "only 1 byte of urgent data" vs
more than one, there cannot be, in TCP it is (depending upon how
you view it) either "all the data from when the urgent pointer was
first set, until that the receiver has read to that place in the
stream" or "no data at all, just a marker between bytes".
The !OOBINLINE model is really only appropriate for transport protocols
which have a true OOB mechanism, where out of band data is delivered
early, out of the normal flow control and seqencing rules ... in such
a model, with the test programs, particularly with that delay added in
the receiver, "b" would be read before "a".
None of this has any particular bearing on what the !OOBINLINE
interface should look like for TCP applications - or whether NetBSD
provides the same one as other systems (but I would test FreeBSD,
MacOS. and/or Solaris, rather than linux to determine that) but it
really should not matter too much, since no application that is
using TCP should really be using that interface anyway.
Main Index |
Thread Index |