Hi,

> When a server or inetd forks off an individual process (say, uucpd) to
> deal with a particular client, I vaguely recall reading somewhere that
> although listening for requests is done on a well-known port, when the
> process accepts on the socket, it gets a different, higher-numbered port
> to work on.

man accept:
[...]
     The argument s is a socket that has been created with socket(2),  bound
     to an address with bind(2),  and is listening for connections after a
     listen(2).  The accept() argument extracts the first connection request
     on the queue of pending connections, creates a new socket with the same
     properties of s and allocates a new file descriptor for the socket.  If

It looks to me that it just creates a new file descriptor for the socket,
not a new socket.

[...]
     The accepted socket may not be used to accept more connections.  The
     original socket s remains open.

> Why I question this is that the Firewalls book by Chapman *never* mentions
> this, even when going into detail on how to set up packet screeners for
> simple services like UUCP on page 237, or when discussing TCP/IP
> fundamentals.

Maybe because the stuff you think is happening doesn't happen :-)

> If this is not the case, how does the kernel distinguish messages going to
> different uucpd's (or, if uucp is a bad example, ftpd command channels)
> running simultaneously?

Hmm, I would assume that the kernel distinguishes the clients by their
different src address (including the src port).:

client                      server 
telnet from port 2047       telnetd port 21
telnet from port 2048       telnetd port 21

The client's IP-address, together with the client's src-port make up
the client socket. If you have two client sockets and one server
socket, you can still distinguish between the two connections.
The client and the server socket are part of every IP-packet.

> If it *is* the case, how does the client know how to start sending messages
> to the new port?

Hmm, to verify that this is not the case, just run tcpdump on the server
machine (or anywhere between server an client) and look at the src and
destination port numbers. telnetd is a good example, because it always
uses the same port. ftpd might not be such a great example, as the
ftpd gets commands to port 21 and sends the data concerning the commands
(the the file you've just ordered with 'get file') from port 20.
Dunno about uucpd, though.

> I feel like I'm missing something *really* basic here.

Hmm, dunno, I'm no expert at this, but I've read a fair amount of stuff
about this and the man page seems to back up my "assumptions" :-)

  Guenther