[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: mlelstv%serpens.de@localhost (Michael van Elst)
Subject: Re: kern/54435: reading TCP urgent data with MSG_OOB doesn't clear poll(2) status
Date: Sat, 3 Aug 2019 20:20:34 -0000 (UTC)
riastradh%NetBSD.org@localhost (Taylor R Campbell) writes:
> poll on a socket returns POLLPRI|POLLRDBAND as long as so->so_oobmark
> is nonzero or so->so_state has SS_RCVATMARK is set.
> - so_oobmark is the pointer to how many bytes away the urgent data are.
> - SS_RCVATMARK is set when the urgent data are clamouring at the gate.
> These are updated by normal reads, but not by the recv(MSG_OOB) call
> that actually returns the urgent data.
That's how it is supposed to be.
OOB data is not delivered in the stream. Instead you get information
that 'urgent data' lies ahead. recv(MSG_OOB) can be used to peek at
that data, but it doesn't consume the stream or that data. That's
why the poll condition persists. It's even possible that you cannot
peek at the data, because it hasn't been received, then recv(MSG_OOB)
is supposed to return EWOULDBLOCK.
The correct answer to 'urgent data' is to consume the stream to
the point where the OOB data lies ahead. Then, since a normal
recv() won't deliver the urgent data to the application, use
recv(MSG_OOB) to read it. At that point, the poll condition
already has been cleared by reading the stream.
To read ahead you can use the SIOCATMARK ioctl that returns the
state of the RCVATMARK flag. The recv() is automatically truncated
so that you don't read past the urgent data.
An alternative to recv(MSG_OOB) is the SO_OOBINLINE option. Then you
don't need recv(MSG_OOB) to get at the urgent data but read it
directly. There is even an RFC telling that this behaviour was
originally intended, but everyone copied the MSG_OOB interface.
Michael van Elst
"A potential Snark may lurk in every tree."
Main Index |
Thread Index |