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

Chris Friesen
2004-10-20T22:18:37Z

H. Peter Anvin wrote:

> Doing work twice can hardly be considered The Right Thing.

If the alternative is to have apps that can be DOS'd with a single corrupt
packet, I think that yes, it is.

Going forward, all apps should use nonblocking sockets, correct? (With the
current design, because it's the only way to get correctness, with my proposal
because it's the only way to get full speed.)

Given that, we then have to worry about the installed base of binaries out there
that will use blocking sockets. And it's going to take some time before they
all convert. For all those binaries, (which include basic things like syslog,
inetd, portmap, and statd) the existing kernel behaviour does not match what the
app is expecting. With a minor change, we can give the behaviour that the app
expects, though at a performance penalty. Once the app switches over to
nonblocking sockets (which it has to do *anyway* under the current model) then
it gets full performance.

To summarize:
1) apps have to switch to nonblocking sockets (for correctness)
2) my proposal makes them work as expected in the meantime, with a performance cost

Chris