socket.recvfrom() & sendto()

[Ron Johnson]

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

It seems like the server *and* the client both must use asyncore.
But does asyncore, underneath it all, sit at select.select() waiting
on the next readable socket?  So if the client is also using asyncore,
does it need a thread for network IO and a thread for user interaction,
and the 2 threads talk to each other?

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