views:

49

answers:

2

I'm dealing with a buggy server that will sometimes fail to accept() connections (but leaves its listening socket open). This is on Linux with unix domain sockets.

Currently the only way to detect this is that after sending a bunch of data, the buffer fills up and blocks, and the server isn't sending any replies. This long-after-the-fact failure mode is hard to distinguish from other bugs - the server could be unresponsive for other reasons.

Especially for unix domain sockets it seems the kernel should know whether accept() has occurred; is there any way to find this out? Can the client block until accept() happens somehow, or at least check whether it has?

This is just for debugging purposes so it can be a little ugly.

+2  A: 

I'd say that the answer was to change the protocol so that the server speaks first (like SMTP, not like HTTP)

The kernel accepts sockets already before the accept() system call is made; if it never arrives, then the sockets sit around in a waiting state. There is no way to distinguish this from the server accepting the connection but not speaking. This is the way BSD sockets has always worked.

MarkR
yeah, unfortunately I can't change the protocol or the server, or there would be no need to do this ;-) it's just something that would be useful to work around the screwy server.I don't anticipate there's a way to do this but the kernel does in theory know if the accept() has happened - on a local unix socket - so just asking if anyone knows a way.pretty clearly it would be impossible in the TCP case
Havoc P