David Steuber <email@example.com> wrote:
| Peter Seibel <firstname.lastname@example.org> writes:
| > That doesn't matter to the server. Every connection to a server is to
| > the same port anyway (typically). It's the client IP-address/port that
| > makes the connection unique. So while it's true that I can only have
| > (expt 2 16) connections from a single client IP address, I can have
| > many, many connections from many, many clients.
| Another poster also corrected my misconceptions about sockets. The
| reason I thought there was a limit on server connections was the way I
| thought accept worked. I don't recall how I got this idea...
Did you even play with the Xerox XNS protocol stack (or the Novell
Netware stack, which used a lightly-hacked version of XNS)? XNS's
Sequenced Packet Protocol worked the way you thought IP/TCP did:
"Well-known sockets" were only used to receive connection requests,
which contained a connection-request ID. The actual response was
from a different, random server socket, which replied with the given
connection-request ID (so the client knew which connection request
the reply was for). And, yes, socket numbers were only 16 bits, so
the ~65K connection limit applied [since the whole point of the reply
protocol was to make it possible to demultiplex received packets
based on destination socket number *only*!].
As Peter says, though, IP/TCP doesn't work that way...
Rob Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607