socket.recvfrom() & sendto()

Van Gale cgale1 at _remove_home.com
Tue May 8 01:40:04 EDT 2001


"Ron Johnson" <ron.l.johnson at home.com> wrote in message
news:YCJJ6.40526$2U.17316325 at news2.rdc2.tx.home.com...

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

Yes, it is one solution.  Another is the polling approach of the asyncore
module.

If you chose a forking/threading solution start with the SocketServer
module.  You can easily switch between threading or forking using a mix-in
class designed to work with SocketServer.  To allow for real-world
"impairments" you might also have to download and use timeoutsockets.py, and
maybe even have to develop some kind of thread pooling scheme.

If you choose the poll solution start with the asyncore module.  If your
communication model is a chat style (where client sends a request to the
server and always gets one response back) then you can add in the asynchat
module.

Between these two solutions asyncore scales better into large numbers of
connected clients.

I assume your "peer-to-peer server" is basically doing message routing
between the clients.  If so, and the messages are being sent at irregular
and random intervals, then asyncore is easily the better solution.  If you
are planning on having (oh lets say) more than a thousand clients connected
at once then asyncore is probably the only solution.

If you download Medusa from http://www.nightmare.com/medusa you'll find some
nice information on performance and scalability.  There's also a number of
links on that page to good information and resources.

Van Gale






More information about the Python-list mailing list