Tom Duerbusch <[EMAIL PROTECTED]> wrote:
> From my understanding, when a client connected to the server stack at a
> particular port, that port is tied up and no one else can connect to
> it.
> If I remember correctly, when you FTP to port 21, the FTP server
> responses with another port that you should use for the rest of the FTP
> session. This keeps port 21 from being tied up during long FTP
> sessions. Right?
As far as TCP is concerned, a connection is identified by the
{source address, source port, destination address, destination port}
combination. When a packet comes in, that is what is used to find
the appropriate destination. Since TCP is a stream protocol,
the packets are processed by TCP, retransmissions are requested,
and data is delivered only after it is back in stream format.
Boundaries between requests to TCP don't necessarily generate
separate TCP packets, and packet boundaries aren't seen on
by receiving program.
UDP usually only processes the {destination address, destination port}
combination. Some servers will decode the source address, source
port, but it is the responsibility of the receiving program.
Many stateless servers can handle UDP without a subtask for
each client, just replying to each request. Data is delivered
preserving packet boundaries.
Under unix, programs accepting a TCP connection usually fork()
to create a subtask to handle the connection. It might be that
new requests that come in before the fork() get the busy signal.
Most print servers boxes can only handle one connection at a time,
and will refuse any additional connections. That is not a TCP
limitation, but a higher level protocol limitation. Sendmail,
I believe, also refuses connections when too many are already
open to avoid overloading the machine.
-- glen
