"heartbeat" approach

[bob smith]

What is the best way to handle a situation where you want a socket to send a "heartbeat" every ten minutes? I was thinking it would be simple to have a single thread do all the "heartbeat" sending.

However, that means there could be multiple threads writing to one socket. Do I need to do anything special to have multiple threads writing to one socket? Is there a better way?

Thanks.

 

[Knute Johnson]

What is the best way to handle a situation where you want a socket to
send a "heartbeat" every ten minutes? I was thinking it would be
simple to have a single thread do all the "heartbeat" sending.

However, that means there could be multiple threads writing to one
socket. Do I need to do anything special to have multiple threads
writing to one socket? Is there a better way?

Thanks.

Just synchronize on the Socket or the OutputStream. The cost of
synchronizing in that case would be very low.

 

[Arne Vajhøj]

What is the best way to handle a situation where you want a socket to
send a "heartbeat" every ten minutes? I was thinking it would be
simple to have a single thread do all the "heartbeat" sending.

However, that means there could be multiple threads writing to one
socket. Do I need to do anything special to have multiple threads
writing to one socket? Is there a better way?

You can certainly let the two writing thread synchronize on
Socket or OutputStream objects to make it thread safe.

You could also funnel all writes through the same
thread (a writer thread) via some in memory data structure
(which you would then need to synchronize on).

The last option would end up as much more complex
code from start, but I believe that the design may
end up being preferable as the solution itself evolves.
Consider how many places you nee to change if you want to
switch from TCP to UDP.

Arne

 

[Robert Klemme]

http://docs.oracle.com/javase/6/docs/api/java/util/Timer.html


You can certainly let the two writing thread synchronize on
Socket or OutputStream objects to make it thread safe.

Yes, _some_ form of synchronization is needed.

You could also funnel all writes through the same
thread (a writer thread) via some in memory data structure
(which you would then need to synchronize on).

The details of course depend on the nature of the heartbeat (e.g. can it
be omitted if there was regular traffic in the meantime? How much delay
for the heartbeat is allowed etc.).

The last option would end up as much more complex
code from start, but I believe that the design may
end up being preferable as the solution itself evolves.
Consider how many places you nee to change if you want to
switch from TCP to UDP.

We could certainly come up with better solutions if we had more
information about the scenario.

Kind regards

robert

 

[Roedy Green]

However, that means there could be multiple threads

writing to one socket. Do I need to do anything special to have
multiple threads writing to one socket? Is there a better way?

I wrote some proprietary code for a large scale security camera
monitoring system perhaps 5 years ago that did just that. IIRC
sockets are happy to have multiple writers. The alternative would be
to use a queue fed by multiple writers with a single reader. I don't
recall writing any queue stuff until a year or so ago.

TCP/IP is completely silent unless you are actively transmitting data,
unlike many other protocols. So if you can to detect a broken link,
you need some artificial traffic. That is why he needs a "heartbeat".
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

 

[Arne Vajhøj]

http://docs.oracle.com/javase/6/docs/api/java/util/Timer.html

That could be a very convenient API to get the thread running.

Arne

 

[Arved Sandstrom]

Yes, _some_ form of synchronization is needed.


The details of course depend on the nature of the heartbeat (e.g. can it
be omitted if there was regular traffic in the meantime? How much delay
for the heartbeat is allowed etc.).


We could certainly come up with better solutions if we had more
information about the scenario.

Kind regards

robert

Agree with the last. It may be that dealing at the level of sockets is
not the best way at all. It may also be that there is some discussion
required about *what* we are calling a heartbeat, whether it is actually
a "heartbeat" that we are wanting here, or whether external status
polling is better.

I myself think of a heartbeat as being a periodic signal initiated by
the server or application that is being monitored, and generally a push
to a central monitor.

I consider that for servers ("server" being loosely defined here as
*any* standalone app that is taking requests) that the best type of
status checking in many circumstances is pull by a client. And the best
type of status check is a request that looks more or less like any other
kind of request that the server accepts. So, if I was testing a web
server, I'd send an HTTP request; if email, an SMTP; if messaging I'd
try to put or get a JMS message.

AHS