Re: UDP recvmsg blocks after select(), 2.6 bug?

Martijn Sipkema
2004-10-07T10:28:46Z

From: "Adam Heath" <doogie@debian.org>
Sent: Thursday, October 07, 2004 11:07

> On Thu, 7 Oct 2004, Martijn Sipkema wrote:
>
> > > > It does not matter - this behaviour should not be depended upon. There are
> > > > lots of other reasons why a packet might in fact not be available, kernels
> > > > are allowed to drop UDP packets at will.
> > >
> > > I've been lurking and reading this thread with great interest. I had been
> > > leaning towards thinking the kernel was wrong, until I read this email.
> > >
> > > This is a very excellent point.
> >
> > No, it isn't. If the kernel drops a UDP packet, select() should not return
> > indicating available data.
>
> The kernel can drop a packet after select() returns, and before read() is
> called. That's the whole point of *U*DP.

I don't think that is the point of UDP and I don't think the kernel should
do that, but there are two options for handling this:

If recvmsg() blocks until valid data is available then so should select().
If recvmsg() returns an error on invalid data then select() would indicate the
socket() as ready without knowing if the data was valid.

--ms