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: Mon, 05 Aug 2019 21:06:08 +0700

     Date:        Mon,  5 Aug 2019 09:25:02 +0000 (UTC)
     From:        Michael van Elst <mlelstv%serpens.de@localhost>
     Message-ID:  <20190805092502.0D7C67A1AD%mollari.NetBSD.org@localhost>
 
   |  The closest thing to documentation is probably "An Advanced 4.4BSD
   |  Interprocess Communication Tutorial" [Leffler,1986],
 
 Available in: src/share/doc/psd/21.ipc   Section 5.1 is the relevant part.
 
 It is clear that the intent is to support protocols that actually
 have OOB data, unlike TCP which doesn't:
 
 	This is more difficult when the underlying protocol delivers the
 	urgent data in-band with the normal data, and only sends notification
 	of its presence ahead of time (e.g., the TCP protocol used to
 	implement streams in the Internet domain).
 
   |  This is not a good interface,
 
 Certainly not for TCP, where SO_OOBINLINE should always be used really.
 
   |  It doesn't have to "make sense" and
   |  changing just a small aspect of it probably does more harm than
   |  keeping the established behaviour, in particular when there is
   |  almost no user of that interface.
 
 The only user of recv*(MSG_OOB) I can find in the NetBSD src tree is
 rlogin - which uses SIGURG and in its handler, simply reads from the
 stream (discarding it) until SIOCATMARK says the urgent pointer has
 been reached, after which it does one recv(MSG_OOB).   That example is
 also used in the Tutorial.   It is the sole example of how MSG_OOB
 should be used for recv()...
 
 There are several users of send(MSG_OOB) but the receivers for them don't
 use recv(MSG_OOB).   (telnet is one example).
 
 If we still had some reason to support protocols which actually have OOB
 data as part of the protocol, and we had applications that used those
 protocols, there might be more use of recv(MSG_OOB) as for such protocols,
 where OOB data is delivered independantly of the normal data and the
 application needs to say which it wants to read at any point.
 
 kre