OTish: using short-term TCP connections to send to multiple slaves
invalid at invalid.invalid
Sun Nov 16 17:53:52 CET 2014
On 2014-11-16, Chris Angelico <rosuav at gmail.com> wrote:
>> OK, no big requirements, but 64K is still way too much to consider UDP.
> I wouldn't say "way too much"; the packet limit for UDP is actually
> 64KB (minus a few bytes of headers). But UDP for anything more than
> your network's MTU is inefficient, plus you'd need to roll your own
> acknowledgement system so you know when the client got the data, at
> which point you're basically recreating TCP.
> That said, though: UDP would be a good option, if and only if you can
> comply with those two restrictions - sender doesn't care if the odd
> packet doesn't get through, and no packet is allowed to exceed 64KB,
> with typical packet sizes wanting to be more like 1KB. (DNS servers
> usually switch you to TCP if you go above 512 bytes of response, but
> that's because DNS responses are usually tiny.) It'd be pretty easy to
> knock together a simple UDP system - you have the clients listen on
> some particular port, and you could even make use of IP broadcast to
> send to everyone all at once, since this is a single LAN.
If, as the OP seemed to state, this is strictly within a single
network segement (no firewalls or routers involved), then UDP
multicast might be worth considering. It's not reliable like TCP, but
it does make everything very simple: just decide how many different
logical data streams you are going to have, and allocate a multicast
address for each one. Have the server multicast new data whenever it
becomes available, and the slaves all register for and and listen to
for whichever data streams they care about. Note that the "register
for" (or join, or whatever it's called) isn't something the server
knows about, that's purely done by the slave app to inform the slave's
network stack and any intervening routers what multicast streams the
slave app wants to see.
In _theory_, if betwixt the server and client the routers and
firewalls are properly configured, multicast should still work. But,
the smart money will be giving long odds that they aren't, and it
One possible advantage of UDP is that is packet oriented, so if your
data isn't message oriented rather than an undifferentiated byte
stream, UDP saves you the effort of having to packetize and
unpacketize the data as you have to via TCP.
More information about the Python-list