On Fri, Dec 08, 2006 at 11:07:46AM -0500, Jerry Geis wrote: > Hi all, > > I have a snippit from the linux sockets (below) talking about detecting > when > a socket is closed on the other end. It says the doing a read() will > eventually inform > you the socket is ECONNRESET. I am not seeing this > > I open a socket to the peer. I UNPLUG the peer. I plug back in the peer. > all the time I am doing read()'s on linux and I get returns of -1 and > errno is EINTR > from the alarm() around my read() function. I never get ECONNRESET. > > Am I missing something in detecting the peer no longer having the socket > connection? Jerry: My understanding is that when a program has a socket open and is waiting for data to arrive, there is no way for it to detect that the connection has been interrupted (assuming the connection was not shut down cleanly, which it of course can detect). A return of -1 from read() or recv() is normal for when there is no data to receive. If your program is waiting to read/recv data, and the connection has been broken, it cannot tell that there is any problem. however, if you are WRITING to that socket and the connection has failed you'll get an immediate error. What I had to do in a program I maintan (that never transmits until it has received something requiring a response) is implement an idle timeout that drops the connection after a period of time if it has received nothing for that length of time. The protocol being used in this situation is that the sender will attempt to re-connect automatically if the connection is dropped, so it works out nicely. Fred > > Thanks, > > Jerry > ---------------------------- > > This text has been taken from the original FAQ. > > 2.1 - How can I tell when a socket is closed on the other end? > From Andrew Gierth ( andrew at erlenstar.demon.co.uk): > > AFAIK: > > If the peer calls close() or exits, without having messed with > SO_LINGER, then our calls to read() should return 0. It is less clear > what happens to write() calls in this case; I would expect EPIPE, not on > the next call, but the one after. > > If the peer reboots, or sets l_onoff = 1, l_linger = 0 and then closes, > then we should get ECONNRESET (eventually) from read(), or EPIPE from > write(). > > I should also point out that when write() returns EPIPE, it also raises > the SIGPIPE signal - you never see the EPIPE error unless you handle or > ignore the signal. > > If the peer remains unreachable, we should get some other error. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The Lord is like a strong tower. Those who do what is right can run to him for safety. --------------------------- Proverbs 18:10 (niv) ----------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20061208/f726d900/attachment-0005.sig>