Python newbie looking into communications...

[jerf at compy.attbi.com]

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.

If your computers are known to be on the same network, you may be able to
Broadcast stuff, too, such as requests from a "client" for a server to
identify itself. I've never done this, and it will only work for stuff on
the same network, so I don't want to go any further into this unless you
say that it's on the same network, because I'd have to go research it
myself.

> 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. 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. The Internet
periodically burps no matter how good your programming is.

Additionally, there is no crime with establishing a TCP connection on each
request, as long as you aren't sending too many, too often. (If you are,
then the overhead starts to swamp the cost of sending the data in the
first place.)

> 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.
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 peer-peer comm seemed a worthy compromise. 

It's this sentence that prompted the bit above about TCP not being
server-client.

> I'm 
> not dealing with large amounts of data--usually small strings, and they 
> aren't pushed around the network very fast....usually a dialog might be 
> something like:
> 
> Controller: MachineA, run this calculation.
> MachineA: Okay, controller, I'm doing that calculation.
> Controller: Displays information on what MachineA is doing.
> MachineA: Okay, controller, I'm done. Here's the result.
> Controller: Okay MachineA. Displays info.
> process repeats.....
> 
> In my perfect world, all I really wanted was a way to say
> SendToMachine(machinename, data)
> and an event to catch data
> DataReceived(MachineName, data)
> 
> 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? ;-)

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.