Re: linux sockets on centos (slightly off topic)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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@xxxxxxxxxxxxxxxxxxxxx):
> 
> 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@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos

-- 
---- Fred Smith -- fredex@xxxxxxxxxxxxxxxxxxxxxx -----------------------------
                        The Lord is like a strong tower. 
             Those who do what is right can run to him for safety.
--------------------------- Proverbs 18:10 (niv) -----------------------------

Attachment: pgpNmnFOoZ9Am.pgp
Description: PGP signature

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux