Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear poll(2) status

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/54435; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
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)
     Message-ID:  <20190804044001.73A2A7A1AD%mollari.NetBSD.org@localhost>
 
   |  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.
 
 kre