socket.recvfrom() & sendto()

Ron Johnson ron.l.johnson at
Tue May 8 05:21:28 CEST 2001

Grant Edwards wrote:

> In article <4VEJ6.39240$2U.16140998 at>, Ron Johnson
> wrote:
>>> Quoth Ron Johnson <ron.l.johnson at>:
>>> | The reason that I ask this is because, unlike with command/response
>>> | client/server systems, the server must be able to send data to any
>>> | client at any moment.  AIM/ICQ would be similar model, even though
>>> | I am not writing a chat program.
>>So my fundamental question is: how does select() support multiple
>>non-blocking TCP sockets, when you can only bind 1 socket to a port?
> The socket you bind to the port is the one that listens for
> connections.  You call accept() on that one socket you bound to
> the port. When a connection request arrives, the accept() call
> returns a _new_ socket that's connect to the IP/port address
> that sent the request.  If you call accept() again *on the same
> socket you did the first time* it will wait for another request
> to arrive and return another new socket connect to the new
> requestor.
> Now you've got three open sockets: the first on that's doing
> the listening for new conection requests and the two others
> that are connected to something out on the 'net.  You do read()
> and write() calls on the latter two, and accept() calls on the
> former.

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?

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

More information about the Python-list mailing list