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

[Grant Edwards]

On 2014-11-16, Roy Smith <roy at panix.com> wrote:
> In article <mailman.15887.1416150791.18130.python-list at python.org>,
>  Chris Angelico <rosuav at gmail.com> wrote:
>
>> UDP for anything more than your network's MTU is inefficient
>
> Why do you say it's inefficient?  Sure, the UDP datagram will get 
> fragmented and re-assembled at the other end, but it's not like TCP 
> would do any better.  One way or another, your data is going to be 
> transmitted in packet that fit into the MTU.
>
>> 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 I certainly agree with.  UDP should be used for fire-and-forget, 
> where its not critical that every bit of data gets through.  A classic 
> example is high-volume logging.  Once you start thinking about any kind 
> of acknowledgements, you should just switch to TCP.  The alternative is 
> that you will slowly end up reinventing TCP (and doing a bad job of it).
>
>> NAT is the most common cause of breakage, but any router does have the
>> power to monitor and drop connections on any basis it likes. (I can't
>> imagine any reason a non-NAT router would want to prevent connections
>> from going idle, but it could be done.)
>
> It's common in corporate networks for routers to forcibly close idle 
> connections (i.e. inject RST packets).  Often, the IT security guys 
> think idle connections represent some kind of threat (and good luck 
> trying to argue with them).

According to the OP, the communication is "on a small local subnet,
over Ethernet."  To me that means no router, no firewall: just an
Ethernet switch (or two).

If that is the case, and the master and slaves can't maintain TCP
connectivity, then something is seriously broken in the master or
slaves and needs to get fixed.

What I don't understand is if TCP connections are going away (which
can happen if either end gets restarted, or cables get unplugged, or
switches lose power), why the app doesn't just open a new one and
resume operation?

-- 
Grant