socket.recvfrom() & sendto()

[Grant Edwards]

On 7 May 2001 23:19:58 GMT, Donn Cave <donn at u.washington.edu> wrote:

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

I didn't phrase things very well: You make read() and write()
syscalls on the sockets, and you're right, that's done with the
recv() and send() methods of the Python socket objects.

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

Good point.  Perhaps the difference between connection-oriented
and connectionless sockets is causing some confusion.

-- 
Grant Edwards                   grante             Yow!  I am KING BOMBA of
                                  at               Sicily!...I will marry
                               visi.com            LUCILLE BALL next Friday!