[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: Valery Ushakov <uwe%stderr.spb.ru@localhost>
Cc: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear
Date: Thu, 8 Aug 2019 04:21:46 +0300
On Thu, Aug 08, 2019 at 00:35:01 +0000, Robert Elz wrote:
> | And since we do provide recv(MSG_OOB) we might as well provide
> | non-buggy poll to go with it.
> Again, Michael says that what we have isn't buggy. From the example in
> the tutorial (which remains in rlogin to this day) the method used for
> urgent data using recv(MSG_OOB) is to read (using recv() or read()) until
> SOICATMARK returns true, and then do the recv(MSG_OOB). Have you tried
> that to see if that works? It is not what your test program did.
See my previous reply to the PR. If the sender sends
/* stops sending, keeps connection open */
and the receiver
recv until SIOCATMARK -> "a"
recv(MSG_OOB) -> "B"
and then calls poll with POLLIN|POLLPRI to decide what to do next, it
will end up in an busy-wait loop as poll will immediately return
POLLPRI (only), but recv(MSG_OOB) will fail, then the receiver calls
poll and the loop repeats.
Aside - I wonder if the notion of "at mark" made sense for those other
protocols that had real out of band data (of which I know nothing).
It's also not entirely obvious to me what given POLLIN | POLLRDBAND
the right action is to read/drain the normal (in band) stream first.
This is likely highly application and protocol dependent, but it would
seem natural to want to read real out of band data out of band,
i.e. calling recv(MSG_OOB) as soon as POLLRDBAND is reported. So I'm
somewhat worried that we are imposing the semantic of TCP not-really
OOB urgent data - which happens to be the only user of this interface
- on the way that interface behaves.
> I also asked (earlier) what FreeBSD/MacOS/Solaris do in this area - that
> linux is different would not be all that strange. It often is.
As I noted in the previous reply Solaris seems to behave the same,
with POLLPRI spammed after the urgent data has been read. I'm
travelling, so I don't have a macos system handy. I'll test when I
get back home.
Main Index |
Thread Index |