Hi All,

I am writing a redis client in fpc and found that even when the connection is closed by server (via redis CLIENT KILL), send and receive can still be done without error. i.e.:

- fpsend returns the number of bytes sent
- fprecv returns 0 (but NOT -1, which indicate a "detectable" error, as per the document)

I also checked socketerror after send/recv, no error is reported.

How do I tell if a socket is still connected or not?

Thanks

In our previous episode, Xiangrong Fang said:

I am writing a redis client in fpc and found that even when the connection is closed by server (via redis CLIENT KILL),

I don't know the redis protocol is, but "CLIENT KILL" sounds like redis protocol, while you are trying to detect disconnect at socket level. And is your socket layer really connection oriented ?

IOW does the remote server really actively close the socket?

Maybe stracing the application during a disconnect event might yield some more information.

How do I tell if a socket is still connected or not?

Limit the timeout time (some socketoption or ioctl iirc, search the web), send something, and wait the timeout time. Then read something.

Xiangrong Fang wrote

How do I tell if a socket is still connected or not?

The "connected" State of a TCP/IP socket is a rather complex issue.

A TCP IP connection is either on or off. if it gets disconnected it is dead and can't be reactivated but by a new open.

As long as no event happens to one of the sites, the socket is esteemed connected by this site. This does not mean that the other site thinks the same

Possible events after a successful "open" communication events are
- data read (-> stays open)
- write acknowledge (-> stays open)
- write timeout (socked is forced close)
- close request from the other site (-> socket close)
- close request by user (-> socket close)

If there is just no communication, the socket stays open forever.

-Michael

2013/4/22 Marco van de Voort

Yes, it is redis protocol. I can only be sure that it is TCP based.

I will study stracing if necessary. But will simple "netstat" show the status of a socket?

I am using blocking mode, it just return immediately.

2013/4/22 Michael Schnell

As long as no event happens to one of the sites, the socket is esteemed connected by this site. This does not mean that the other site thinks the same

OK, as connection status is a complex issue, I try to put it in another way:

1) fpsend() just pass data to the OS's socket layer without try to determine if the connection is still alive, right?

2) is it normal that in BLOCK mode, recv returns 0? i.e. if I receive a 0 from fprecv(), I can say that the connection is closed by the other end (if there is no detectable socketerror), right?

Thanks.

Xiangrong Fang wrote

1) fpsend() just pass data to the OS's socket layer without try to determine if the connection is still alive, right?

I suppose, but there exists an error code that might come in handy: ENotConn (see http://linux.die.net/man/2/send), which is returned by send().

2) is it normal that in BLOCK mode, recv returns 0? i.e. if I receive a 0 from fprecv(), I can say that the connection is closed by the other end (if there is no detectable socketerror), right?

Yes, if recv() return 0, it mens the client disconnected. If it returns -1, errno will be set. From http://linux.die.net/man/2/recv (see `return value`): "These calls return the number of bytes received, or -1 if an error occurred. The return value will be 0 when the peer has performed an orderly shutdown."

Note that even in non-blocking mode, 0 means the socket is closed. If you received no data yet, you will get -1 as a return value and errno will be set to EAgain of EWouldBlock (see the link above).

Does this help or am I completely talking besides the point?