socket.recvfrom() & sendto()

[Ron Johnson]

Thanks, Van.

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

<rueful grin> Nothing so grand as 1000 clients!  Even though the 
server is not routing between clients, the messages will be sent
at irregular and random intervals.

If u must know, I'm just writing a multi-user turn-based game:
When user1 takes a turn, then he sends a msg to the server speci-
fying his action.  If he does something to affect user[2..N] then 
user[2..N] must be sent a message saying what user1 did to him.  
Next, everyone must be told that it is user2's turn, and the cycle 
begins again.

Ron

Van Gale wrote:

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


-- 
 Ron Johnson, Jr.        Home: ron.l.johnson at home.com
 Jefferson, LA  USA      http://ronandheather.dhs.org
 "Is Python better or worse than Perl?"
  "Perl is worse than Python because people wanted it 
   worse." -Larry Wall, 10/14/1998