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
--
https://mail.python.org/mailman/listinfo/python-list
