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:

> An analogy might be with a master and multiple slave devices sharing
> a serial RS-485 bus.

If that's the model you _want_, then UDP multicast matches it almost
exactly.  ;)

> 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.

Using TCP with human-readable ASCII data sure makes testing,
prototyping, and troubleshooting a lot easier: you'd be surprised what
you can do with some dummy data files, a shell script, and nc.

> 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.

When the TCP connections are failing, does the master know they have
failed?

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

UDP broadcast works pretty well for discoverying nodes (I'm assuming
IPV4 at this point).  One hint for Linux platforms: you have to
disable reverse path filtering <http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html>
in order to receive a UDP packet whose source address doesn't match
the subnets of the interface on which it was received.  This can come
into play when you need to discover and configure a newly installed
device which hasn't yet been configured to match the subnet.

UDP discovery and configuration is actually much simpler to implement
under IPv6.  If you're doing IPv6, then UDP link-local all-nodes
multicast is trivial, since all nodes _have_ a valid link-local
address, you don't have to worrry about reverse-path filtering.

> 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.

If simple helps, then UDP again fits the bill nicely.

-- 
Grant Edwards               grant.b.edwards        Yow! I love ROCK 'N ROLL!
                                  at               I memorized the all WORDS
                              gmail.com            to "WIPE-OUT" in 1965!!