Re: Socket detecting disconnect?
Re: Socket detecting disconnect?
- Subject: Re: Socket detecting disconnect?
- From: Greg Herlihy <email@hidden>
- Date: Sun, 19 Mar 2006 21:20:55 -0800
- Thread-topic: Socket detecting disconnect?
Generally, read() will indicate that a connection has been closed gracefully
by the other side. Write() is not well suited for this purpose since the
writing end of a connection is generally closed by it holder (since only the
holder knows how much data there is to send) - in this case that would be
the client itself.
Specifically, a read operation that returns zero read bytes means that the
other side has gracefully closed the connection - and therefore the client
should do likewise.
The select() routine is useful in this situation since it can monitor both
the read and write ends of multiple connections simultaneously. So whenever
select() indicates that there is room in a socket's buffer to write data -
and the client has data to write - then client should write its data. And
whenever select() indicates there is data to be read on socket, then the
client should read the incoming data. And should the read operation report
that zero bytes were read successfully - then the other side must have
closed its half of the connection; so in this situation the client should be
just as polite and close its half of the connection as well.
Greg
On 3/19/06 8:10 PM, "Rachel Blackman" <email@hidden> wrote:
> I recognize that BSD sockets are a BSD subsystem thing, but as
> there's no direct Cocoa equivalent and everyone seems to wrap BSD
> sockets (or CFSocket around BSD sockets) into Cocoa, I'm going to ask
> here. :)
>
> Socket stuff works pretty well in my Cocoa app, save for one
> problem. I need to have a continuous TCP connection to a remote
> host, and (as anyone who's dealt with NAT will know), when a
> connection goes quiet for long amounts of time a NAT router will
> sometimes silently drop it. Annoying!
>
> Usually, under any other system I've worked with, you detect this as
> soon as you attempt to send data again and write() errors out; it's
> just part of life behind NAT, sometimes your stream gets disconnected
> unless you have some kind of ping method. People are used to this,
> and so you type something random and see the 'disconnected' and go
> 'Ah, well, there we go.'
>
> But on OS X, it seems that write() never errors out. Your connection
> can be gone entirely, completely dead, and write() happily returns
> that it has sent the entire buffer. This, to put it bluntly, Annoys
> Me. (Or more specifically, it annoys my NAT-using users, who find
> themselves silently disconnected and don't even know when it happened.)
>
> I don't have a NAT router on my network, but for testing purposes
> I've yanked the cable out of my computer and find the write() still
> happily returning that it has written the entire buffer, apparently
> oblivious to the fact that my entire network has gone away. (I
> realize that in this case I could use SCNetwork to detect the cable
> being gone, but that doesn't solve the original NAT problem; in that
> case, the connection has gone away silently, not the network.)
>
> Surely I'm not the only person to run into this problem (in fact, a
> quick Google shows I'm definitely not), but poking and prodding
> around via Google et al has not yet produced any answer as to how to
> solve it. I know there /does/ have to be a solution, since there are
> some things out there which can detect such a disconnect.
>
> I'm just really bewildered why OS X's write() behaves differently
> than, well, every other write() I've ever encountered, and if anyone
> knows how to work around this behavioral difference. It's doubly
> annoying because the man page for write on OS X mentions nothing
> about this.
>
> Help me, Obi-Wan Cocoanobi, you're my only hope! Or something. :)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden