Does ServerSocket support reverse socket on a random port?

Question

I saw a lot of answers like this with respect to servers in java: "Let's say you have a server with a server on port 5000. Client A and Client B will connect to our server.

Client A sends a request to the server on port 5000. The port on client A is selected by the operating system. Typically, the OS selects the next available port. The starting point for this search is the previously used port number + 1 (for example, if the OS happened to us at port 45546, then the OS will try to execute 45547).

Assuming there are no connection problems, the server receives a client A request for connection on port 5000. Then the server opens its own next available port and sends it to the client. Here Client A connects to the new port, and now the server now has port 5000.

I saw answers like this in several questions about stackoverflow about how a different port is used in the accept () socket returned than the port that ServerSocket is listening on. It always seemed to me that TCP is identified by a quartet of information:

Client IP: Client port and server IP: Server port → protocol too (to distinguish TCP from UDP)

So why should accept () return the socket associated with another port? Does a quartet of information sent in each header not distinguish between multiple connections to the same server port from different computers, where it does not need to use different ports on the server machine for communication?

Answer 1

You have correctly entered the header information of the TCP packet. It contains:

Client IP | Client Port | Server IP | Server Port | Protocol 

Or, more correctly (since the client / server gets confused when you think about bidirectional migration):

 Source IP | Source Port | Destination IP | Destination Port | Protocol 

Multiple connections to the same server port will come from different ports on the client. An example would be:

 0.0.0.0:45000 -> 1.1.1.1:80 0.0.0.0:45001 -> 1.1.1.1:80 

The difference in client ports is sufficient to eliminate the ambiguity of the two sockets and, therefore, has two separate connections. The server does not need to open another socket on another port. It receives the socket from the accept method, but it is assigned to the same port and is now the route to the newly accepted client.

FTP, on the other hand, has a model where the server will open a new unprivileged port (> 1023) and send it back to the client to connect the client (this is called "Passive FTP",). This is a solution to problems when the client is behind the firewall and cannot accept incoming data connections from the server. However, this does not apply to a typical HTTP server (or to any other standard socket implementation). This is a feature that overlays FTP.

Answer 2

The server then opens its own next available port and sends it to the client.

No. It creates a new socket with the same local port number. The second port number is not assigned or sent to the client. The SYN / ACK segment, which is the server’s response to the connection request, does not contain a second port number.

Here client A connects to the new port,

No. The client confirms the SYN / ACK packet and the client connects to the source port, followed by the confirmation of the SYN / ACK. There is no second connection.

and now the server now has access to port 5000.

It has always been done.

I saw answers like this in several questions about stackoverflow about how a different port is used in the accept () socket returned than the port that ServerSocket is listening on.

Any such answer is incorrect and should be “suppressed” with extreme prejudice and commented negatively. The TCP handshake is defined in RFC 793 and does not indicate the distribution and exchange of the second port and the second connection message. There are only three posts that are not enough for this.

So why should accept () return the socket associated with another port?

This is not true.

Doesn't the quartet of information sent in each header distinguish between multiple connections to the same server port from different computers, where it does not need to use different ports on the server machine for communication?

Yes.