OTish: using short-term TCP connections to send to multiple slaves

[Grant Edwards]

On 2014-11-16, jkn <jkn_gg at nicorp.f9.co.uk> wrote:

> I have a use case of a single 'master' machine which will need to
> periodically 'push' data to a variety of 'slave' devices on a small
> local subnet, over Ethernet. We are talking perhaps a dozen devices
> in all with comms occurring perhaps once very few seconds, to much
> less often - once per half an hour, or less. There is probably an
> upper bound of 64KB or so of data that is likely to be sent on each
> occasion.
>
> Previous similar systems have attempted to do this by maintaining
> multiple long-term TCP connections from the master to all the slave
> devices. The Master is the server and the slaves periodically check
> the master to see what has changed.

Why "check the master"?  Why not just have the master send updates to
the slaves whenever something changes?

> Although this ... works ..., we have had trouble maintaining the
> connection, for reasons ... I am not yet fully aware of.

You need to find out what's wrong and fix it.

> We are now considering an alternative approach where the master
> maintains a list of slave devices and acts as a client. Each device
> is a server from the point of view of data transfer. We would then
> use a short-lived TCP connection when data is available; the Master
> would connect to each slave which needed the data, send it, and
> close the connection.

Why close the connection?  Just leave it open and re-use it the next
time an update needs to be sent.  If the connection has "gone away"
you can simply open a new one.

But, mostly you need to figure out why you can't maintain a TCP
connection between master and slave and fix that problem.

I think the best approach is for the "master" to act as the server.
Clients connect to the server and then wait for updates to be sent
from the server.  If a connection is dropped (e.g. server restarts),
the client should re-establish a new connection.

If there is very little TCP traffic, it can be difficult to detect an
unplugged cable.  The solution for that is either
  
 1) Enable TCP keepalive.  In a no-traffic situation, that will detect
    an unplugged cable within an hour or two.

 2) If detecting an unplugged cable needs to happen faster, then add a
    heartbeat message to your protocol that gets sent often enough
    that you can detect an unplugged cable in within the required
    amount of time.

-- 
Grant