Subject: Re: A simple TCP/socket/port question
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: current-users
Date: 07/03/1996 09:31:21
> 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.

Either your memory or the place you read that is defective.  There are
a couple of protocols that do such things, but it is not generally true
and certainly does not happen automatically.

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

Because a connection is named by the <host,port> pairs of _both_ ends.
A connection from 10.11.12.13 port 456 to your machine port 540 is
entirely distinct from that other connection from 15.16.17.18 port 9012
to your machine port 540.  Every packet in a connection carries all
four of these pieces of information (ie, host/port for each end).

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

Perhaps.  If you can stomach a densely written reference work, you
might want to read RFC 793, which describes how TCP works.  The few
changes that have been made to TCP since then are not such as to
invalidate it for the purposes of clearing up questions this basic.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D