[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: 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>
| 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.
Main Index |
Thread Index |