socket.recvfrom() & sendto()

[Steve Holden]

"Donn Cave" <donn at u.washington.edu> wrote ...
> Quoth Ron Johnson <ron.l.johnson at home.com>:
>
> | Can these be used by a server process that wants to simultaneous
> | keep sockets open to multiple clients?
> |
> | 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.
>
> Per your later clarification, not really!  A client can connect()
> to a datagram service, but to my knowledge that makes no difference
> on the server end.
>
The term "connect" is misleading in terms of datagram services, since really
there is no such thing as a "connection": datagrams get delivered to the
port addressed in the datagram, and (if nothing goes wrong) the server will
usually issue a reply to to the incoming source port, from the incoming
destination port.

> Now of course recvfrom() returns the address of the sender, so
> it's possible to deal with the incoming data in the context of a
> history of multiple clients.  Or your server can bind another
> address for each new client, and notify the client to use that.
> But for features like "connection closed", you would want a TCP
> stream.
>
[Ron, later:]

> So my fundamental question is: how does select() support multiple
> non-blocking TCP sockets, when you can only bind 1 socket to a port?

A server binds to a port and listend for connections from clients. Many
different clients can connect to the same server port. You may wonder how...

When a client is allocated a port number on its host, the transport layer
guarantees that the port number it gets is unique -- no other process on
that host will be allocated the same port number while the original client
is still using it.

Consider two telnet clients, both running on the same host (let's say
10.0.0.1), and both connected to the same remote host (let's say
123.45.67.89) - obviously this *has* to be possible, otherwise you couldn't
have two telnet windows simultaneously open to the same host, right? Both
clients request an "ephemeral" port - one whose number is not specified, the
transport layer can choose.

The transport layer at the server host sees two incoming connections. From
the server side, the two connections are considered as "full associations":
five pieces of information are held as state data about each connection, to
alllow it to correctly multiplex and demultiplex the information streams
to/from each client:

remote host     10.0.0.1       10.0.0.1
remote port     1234           3456
local host      123.45.67.89   123.45.67.89
local port      23             23
protocol        TCP            TCP

So, when the server receives a TCP segment addressed to port 23 at
123.45.67.89, it checks the host and port number it came from. That tells it
which process to deliver the data to.

It's the uniqueness guarantee on ephemeral ports that ensures each
connection must have a unique association at each end: if the connections
are from the same host, they can't have the same port number. If they have
the same port number, they will be from different hosts.

Does this help or confuse?

regards
 Steve