How does a server distinguish multiple connections from a single client?_问答_开发者

I am doing some C programming on Client Server socket examples. Lets say the server listens on Port80, the Client on Port 4321. The tuple is used to distinguish between multiple connections. But how does the server distinguish between connections from the same client? I mean there will definitely be multi开发者_Python百科ple apps from the client accessing the same server on the same port.

Can anyone please explain?

Thanks

Two clients cannot use the same port. If one client uses port 4321 the other has to use different port.

The normal answer is that you just don't do it that way in the first place.

A client will normally connect to a server with an unbound socket, which means it has not specified the local port on which replies will be received. A server will use bind to specify the local port, and then it will listen on that port for connections from clients.

When the client connects with an unbound socket, the TCP stack will choose a port number that's not currently in use, and assign it to that connection. When it sends a request to the server, the server will reply on the port number that got assigned. On the client side, the TCP stack will look at the port number in the packet, and route it to whichever process was assigned that port number.

As such, a client won't use port 4321 -- it'll use whatever port the stack assigns to it. When another process on the same machine connects to the same server, it won't use port 4321 either -- it'll use another port that gets assigned to it. The network stack is responsible for ensuring that each gets a unique port number.

For what it's worth, TCP ports are divided into three ranges. From 0 to 1023 are the "well known" ports for servers like FTP, SMTP, HTTP, POP, etc. These are for servers to use, and it's possible the OS will take some special steps to protect these a bit. Just for example, a typical OS will require some sort of admin/root level privileges to be granted to a process before it can use those ports.

From 1024 to 49151 are the registered port numbers. These are generally more loosely controlled than the well known ports. Almost anybody can set up to listen on them, but the IANA maintains a registry of specific purposes for particular ports. According to the registry, port 4321 is for the remote whois protocol.

From 49152 to 65535 are the dynamic ports -- when a client connects to a server, it will normally get a local port number in this range. You can, of course, write a server and have it bind to a port number in this range if you prefer (e.g., for testing). When/if you do, the stack will keep track of that, so it doesn't attempt to use that port for another purpose.

Two clients can't use the same port, so moot.

However, if you're defining your own protocol, why not pass a ClientID back and forth between client and server? The client can make a request with an invalid client_id, and the server can assign one in the ack.

A connection is identified by a tuple (protocol, source IP, source port, dest IP, dest port). That's how you can distinguish connections.

TCP Listener ports differentiate connections based on a socket, which is a combination of IP:port .

For a client to connect multiple times to the same server, from the same machine, it uses multiple ports (usually ephemeral) to the same known (listener) port.

then, the server iterates on the connection sockets, which might include multiple connections from the same machine or even application.

The client side port binding is done automatically by the OS when you use the connect() TCP function so you don't really need to manage this stuff.

The server then sends data to the client(s) on different combinations of IP:ports (which may still be in the same app), so it can't really get mixed up.