Re: More on detecting dropped connections
Re: More on detecting dropped connections
- Subject: Re: More on detecting dropped connections
- From: Quinn <email@hidden>
- Date: Mon, 15 Apr 2002 11:32:25 +0100
At 6:56 +0100 13/4/02, Tom Bayley wrote:
I've noticed something strange. Our architecture involves a single
process polling connections to a bunch of other processes, using
select() (with zero time-out) and non-blocking recv(). Most of the
'other processes' are running on the same machine as the polling
one. If one of the 'other processes' crashes, select() says there is
data to be read on that socket, though nothing has actually been
sent. That's the strange part. Then, when we try to read the socket
there is nothing there. This strikes me as rather daft - why doesn't
BSD just error the select() or the recv() rather than manufacture
this inconsistency?
Welcome to BSD sockets. I don't know what the solution to your
specific problem is (still learning this stuff myself), but the fact
that select returns "read" or "write" in cases where it should return
"error" is a known weirdness (non-blocking connects have the same
problem, see "UNIX Network Programming" section 15.3-15.5), and the
fact that Windows 'fixes' this is a known porting issue.
One possible solution to your core problem is to call getpeername on
the socket in the case where select says that data is available but
recv says that it isn't. If getpeername returns anomalous results,
the socket is probably dead. This, btw, is just a guess, based on
other workarounds that I've seen to other related problems. YMMV.
Let me know whether it works out.
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.