How to tell if the other end of socket connection is dead without polling?

[Nick Toop]

Hi,

I have a Java application which runs a server socket on a PC. Various
sensors (using microprocessors) can call it up and each gets its own thread
running the socket connection.

The sensors send in data at random times. This all works OK.

Sometimes one of the sensors fails or goes off-line. How can I tell from
the server end? If they fail I would like to close the link down.

Obviously I could poll links on a periodic basis and mark the link as dead
after a specified timeout but this seems rather inelegant. If I chose a
short period the network might be very busy for a short time and cause a
false timeout. If the period is long then I either have to start a new
thread to handle the polling or elselive with my main application blocking.
Anyway, there might be several hundred sensors and I don't want to clutter
the network up with polling packets. Is there a better way?

I would be grateful for any help.

Regards,

Nick

[Robert Larsen]

Nick Toop wrote:

Hi,

I have a Java application which runs a server socket on a PC. Various
sensors (using microprocessors) can call it up and each gets its own thread
running the socket connection.

The sensors send in data at random times. This all works OK.

Sometimes one of the sensors fails or goes off-line. How can I tell from
the server end? If they fail I would like to close the link down.

Obviously I could poll links on a periodic basis and mark the link as dead
after a specified timeout but this seems rather inelegant. If I chose a
short period the network might be very busy for a short time and cause a
false timeout. If the period is long then I either have to start a new
thread to handle the polling or elselive with my main application blocking.
Anyway, there might be several hundred sensors and I don't want to clutter
the network up with polling packets. Is there a better way?

I would be grateful for any help.

Regards,

Nick

If you don't send data on a TCP stream, nothing is sent. There is no
detection of crashes built into the TCP protocol, so you will have to
implement this yourself.

On the client side I usually mark the time of the last packet sent and
use that for determining when a keepalive packet needs to be sent
meaning that if the application itself sends and receives data regularly
no keepalive packets needs to be sent at all. Only when the stream is
idle will I send keepalives.

On the server side I mark the time of the last received packet from each
client and have a timer to check the clients. If the server hasn't heard
from the clients in a configurable amount of time the stream is shut down.

[Dan Stromberg]

On Wed, 27 Aug 2008 13:01:42 +0200, Robert Larsen wrote:

Nick Toop wrote:

>Hi,

I have a Java application which runs a server socket on a PC. Various
sensors (using microprocessors) can call it up and each gets its own
thread running the socket connection.

The sensors send in data at random times. This all works OK.

Sometimes one of the sensors fails or goes off-line. How can I tell
from the server end? If they fail I would like to close the link down.

Obviously I could poll links on a periodic basis and mark the link as
dead after a specified timeout but this seems rather inelegant. If I
chose a short period the network might be very busy for a short time
and cause a false timeout. If the period is long then I either have to
start a new thread to handle the polling or elselive with my main
application blocking. Anyway, there might be several hundred sensors
and I don't want to clutter the network up with polling packets. Is
there a better way?

I would be grateful for any help.

Regards,

Nick

If you don't send data on a TCP stream, nothing is sent. There is no
detection of crashes built into the TCP protocol, so you will have to
implement this yourself.

http://www.developerweb.net/forum/showthread.php?t=2983