Python newbie looking into communications...

[Jp Calderone]

On Mon, Jan 27, 2003 at 04:47:43AM -0500, James Ashley wrote:
> 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."

  "Ugly" is subjective of course, so I can't say you're wrong :)
Personally, I find it better to have a bit of extra code that handles lost
connections than to have a bit of extra code to ensure messages get
delivered.  Both of these can be abstracted out into a library, though, so
if you're writing your code well, neither should be an issue.

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

  I don't see how.  You can always handle lost TCP connections at least as
well as UDP can handle its peer being lost (silently, with no rhyme or
reason).  Maybe you have a case that I've never encountered before, but it
doesn't sound like it so far.  Can you be more specific about why you feel
this point favors UDP over TCP?

> [snip]
> > 
> > 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.
> 

  This sounds like a lack in the design team or the architecture used. 
There is no reason a problem like this needs to exist with TCP networking. 
Rewriting the entire system to use UDP instead is gross overkill.

> [snip]

  Jp

-- 
 up 42 days, 23:49, 3 users, load average: 0.02, 0.14, 0.16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20030127/9f126b94/attachment.sig>