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

[jkn]

Hi All
    Thanks for the various and interesting responses so far. A bit of 
fleshing out in a few areas:

The problems of maintaining the long-term TCP connection is something I'd 
like to leave to one side, for now at least. There are some non-technical 
project issues here which is why I am considering some alternatives. It may 
be that this gets revisited at a later date.

It is possible that the final deployment will, like the prototype, be 
written in Python; again, non-technical issues come into play here.

I use the term 'devices' a bit loosely; some of the 'slave' machines are 
fully-fledged and relatively powerful embedded machines running linux; some 
of them are simpler embedded machines running a scheduler-based system and a 
simple TCP/IP stack. The capability of the latter may be a consideration in 
the final design; they won't be running Python, for instance.

When a 'slave' (not necessarily acting in the client role, AFAICT) is 
unavailable, the behaviour should be that the data is lost, but that it 
should sync up to the next 'block' of data as soon as possible after 
(physical) reconnection, power up etc. An analogy might be with a master and 
multiple slave devices sharing a serial RS-485 bus,.

I have control over the format of the data to be send, so there can and 
should be some indication of the beginning and end of a data 'block'. In 
actual fact the data is very likely to be in JSON.

UDP has been mentioned but I am expecting the comms to be TCP-based, I 
think. The 65KB block size is indicative but I am reluctant to say that this 
is a hard limit.

Chris asks why the slave devices can't periodically connect to the master 
and request data. The reason is that it is unknown when data destined for a 
given slave will be available. The devices would need to connect perhaps 
once a second to get sufficient time resolution, and this seems over-
complicated to me at the moment.

(FWIW there will also have to be some (UDP?) transmission from the slaves to 
the master, for purposes of device discovery)

Thanks for the mention of SCTP; I was aware that there were other protocols 
to consider but haven't yet looked hard at them. One likely issue here is 
that our simpler devices won't be able to support such protocols 
straightforwardly.

I hope this gives sufficient background info to progress the discussion...

    Cheers
    Jon N