socket.recvfrom() & sendto()

[Donn Cave]

Quoth grante at visi.com (Grant Edwards):
| In article <4VEJ6.39240$2U.16140998 at news2.rdc2.tx.home.com>, Ron Johnson wrote:
...
|> 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.

OK, any decent Berkeley socket implementation will support read()
and write() on sockets, but with the Python socket object you must
use recv() and send().  And not recvfrom() and sendto(), as suggested
by the subject line.  That's the source of some confusion in this
thread - recvfrom() suggests the connectionless datagram protocol,
as in socket.SOCK_DGRAM.  With streams, as in socket.SOCK_STREAM,
you can use recv().  recvfrom() may work, at least for the common
implementations, but you won't get a returned address and don't
need one anyway.

	Donn Cave, donn at u.washington.edu