OTish: using short-term TCP connections to send to multiple slaves
invalid at invalid.invalid
Sun Nov 16 17:42:46 CET 2014
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
> 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.
More information about the Python-list