Determining of a Socket has been closed by the other side.

[Dave Rudolf]

Hi all,

Suppose that I have a system where one master process is monitoring a bunch
of slaves. Periodically, the master would like to check if its slaves are
still alive. What I was planning to do was to simply keep a TCP socket open
between the master and each slave and just check to see that the socket is
still "open". The Socket.isClosed() method only tells me if some local part
of the code has called close() on the socket, and the isConnected() method
only tells me if the connect(...) method was called locally.

One way to tell of the connection has gone sour is to actually try to
receive through the socket. But if other party has not sent anything, then
the thread on the local process will hang and wait for input from the other
side. I could anso try to write to the socket, with the same problems if the
other side is not reading from it.

So is there some other way to merely test if a socket is alive on both the
local and remove processes? If I am not mistaken, TCP sends keep-alive
messages and should be able to detect if the other side has disappeared.

Thanks,

Dave

 

[Matt Humphrey]

Hi all,

Suppose that I have a system where one master process is monitoring a bunch
of slaves. Periodically, the master would like to check if its slaves are
still alive. What I was planning to do was to simply keep a TCP socket open
between the master and each slave and just check to see that the socket is
still "open". The Socket.isClosed() method only tells me if some local part
of the code has called close() on the socket, and the isConnected() method
only tells me if the connect(...) method was called locally.

One way to tell of the connection has gone sour is to actually try to
receive through the socket. But if other party has not sent anything, then
the thread on the local process will hang and wait for input from the other
side. I could anso try to write to the socket, with the same problems if the
other side is not reading from it.

So is there some other way to merely test if a socket is alive on both the
local and remove processes? If I am not mistaken, TCP sends keep-alive
messages and should be able to detect if the other side has disappeared.

TCP will not notice that one side has closed or failed unless it is actually
trying to send or receive data. It cannot detect that the other side has
disappeared. Rather, it can only determine that this side has not yet
received acknowledgement for a prior sent message. You can have a blocking
thread that waits on a socket timeout (setSOTimeout). By default it is
something like 4 hours, but you can shorten it. You may also want to look
at the NIO classes for non-blocking IO. Keep in mind that the only way to be
sure that the other end is actually doing anything is for it to send a
message.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[nos]

Hi all,

Suppose that I have a system where one master process is monitoring a bunch
of slaves. Periodically, the master would like to check if its slaves are
still alive. What I was planning to do was to simply keep a TCP socket open
between the master and each slave and just check to see that the socket is
still "open". The Socket.isClosed() method only tells me if some local part
of the code has called close() on the socket, and the isConnected() method
only tells me if the connect(...) method was called locally.

One way to tell of the connection has gone sour is to actually try to
receive through the socket. But if other party has not sent anything, then
the thread on the local process will hang and wait for input from the other
side. I could anso try to write to the socket, with the same problems if the
other side is not reading from it.

So is there some other way to merely test if a socket is alive on both the
local and remove processes? If I am not mistaken, TCP sends keep-alive
messages and should be able to detect if the other side has disappeared.

Thanks,

Dave

sorry, master slave is not pc, use controlling/controlled
or some such

 

[Esmond Pitt]

You can have a blocking
thread that waits on a socket timeout (setSOTimeout). By default it is
something like 4 hours, but you can shorten it.

By default it is infinite, RTFM.