socket.recvfrom() & sendto()

[Donn Cave]

Quoth Ron Johnson <ron.l.johnson at home.com>:
...
| Thank you.  Based on the Sockets HOWTO and everything I've read 
| in the newsgroup archives, that, though, is the *conceptually* 
| "easy" part: writing a server that waits for clients to tell the 
| server to do something.
|
| I am trying to design a "peer-to-peer server", as non sequiter as
| that sounds.  The central computer has a peer-to-peer relationship
| with each of the "peer/clients" so that the "peer/server" should 
| be able to send a msg to any of it's  "peer/clients" at any time, 
| or the any "peer/client" without the client asking for anything.
|
| Would threading or forking be the solution to this problem?

Hm, wish I kept track of the famous quotations that appear here -
the one I'm thinking of ends "... now he has two problems."

Usually the laundry list of requirements is a lot longer than
what you mention above.  There are a handful of ways to do what
you describe, but the trick is to get them to work with the rest
of your list.  It's worth thinking about ways to do what you
need without separate threads - a thread or fork can be an elegant
solution to some problems, but it can also be an unneeded liability.

I would take a hard look at a connectionless datagram protocol,
after all.  Keep track of peers, if you care to, with a directory
that carries whatever history you need and the date of last datagram,
so you can periodically purge old clients.  Store enough state that
a new process can start up and keep the game going after the old one
died.

	Donn Cave, donn at u.washington.edu