Python newbie looking into communications...

[James Ashley]

In article 
<pan.2003.01.27.00.12.15.881159 at compy.attbi.com>, 
jerf at compy.attbi.com wrote:
> On Sun, 26 Jan 2003 20:39:57 +0000, Sam Marrocco wrote:
>> If the Controller was a TCP Server and the nodes were TCP Clients, the 
>> Controller/server had to be running first, then the Nodes/Clients. If 
>> the Controller/Server was restarted (which happens often)then things 
>> went awry. 
> 
> Since you said you were new to networking, I would point out that there
> isn't really a such thing as "TCP Server" or "TCP Client". The
> communication protocol itself is "peer-to-peer", long before that became a
> meaningless buzz word. You are using the terms correctly and I know what
> you mean, but it's importent that your concept of "TCP" itself does not
> include "server" or "client", that's a function of how you use the
> protocol. Only "initiator" and "receiver" really matter.

The point remains, though.  When one member of a TCP pair goes away, it
tends to be uglier than over UDP.  (If nothing else, as I recall, win 32
--I'm just guessing that's involved--doesn't give you a whole lot of 
control over the sockets, so the timeout can be a lot uglier than just
waiting on a "heartbeat."
> 
>> Also, the Nodes/clients do not necessarily know *who* the 
>> Controller/Server is, so they receive that information within their data 
>> from the Controller/Server--then send info back to that machine. Nodes 
>> and Controller can be rebooted at any time, and the apps restarted.
> 
> TCP connections will notify you when they have been terminated for any
> reason. Exactly when that happens depends on the exact parameters of the
> connection and the underlying network API. 

It's that "depends" part that, in some cases, does make UDP a better
engineering choice.

> You can easily re-try the
> previous server address every so often, or have the server try to
> reconnect to its clients after a reboot.
> 
> In fact, for the sake of robustness, you need to have this stuff anyhow,
> unless they are all sitting on the same well-maintained LAN. 

Or even then...depends on the app, of course <G>.

> The Internet
> periodically burps no matter how good your programming is.
> 
>> When I started playing with UDP, I realized that, yes, the "lack of 
>> guarantee" that the data would get there was an issue--which I could 
>> correct for by including acknowledgments and a little handshaking 
>> between machines. But it seemed well worth it for the ability to have a 
>> "server-less" communications arrangement that didn't gag when the server 
>> machine disappeared.
> 
> When the server machine disappears, the connection gags no matter what.

The severity of the gagging differs, though.  I was only a junior member
on this team, and I never got into these details.  But I once worked on
a project where, randomly, one client would lose its connection to
the server.  Somehow or other, this wound up locking up every other
client involved.  To fix this problem, everything was ported to UDP.

> TCP lets you detect that without writing the detection routine. UDP
> requires you to write it. And don't forget the hairy problem of when the
> ack is sent but the original sender doesn't receive the ack!

UDP is definitely more complicated <G>.
> 
<snip>
>> 
>> But the most important thing was that any machine on the network could 
>> be restarted at any time, *without* having to have a server app always 
>> running.
> 
> TCP still seems a better choice. Establishing a TCP connection and pumping
> out a few packets vs. establishing a UDP connection and pumping out a few
> packets (which is how it will look at the API level) is so similar in
> programmer cost you're still probably going to come out ahead with TCP.
> Either way, you still need to write the SendToMachine function, so who
> cares? ;-)

I think this might work better if it's re-phrased just a shade:  it's
probably more productive/simpler design/better/etc. to at least start
with TCP.  After you have a system up and running, if you have weird
networking problems (mainly related to dropped connections, though you
can probably handle re-boots gracefully enough), then it might be worth
porting to UDP.
> 
> The only scenario where UDP wins is if the network connection is REALLY
> intermittent and it truly doesn't matter if a large number of messages are
> dropped. You can then eke out an advantage with simply sending lots of UDP
> packets and forgetting acks entirely, but that's a rare application. Net
> telephony and video streaming and little else.

I'll add mobile clients using ethernet-over-radio'ly yrs,
James