As I mentioned, with TCP, there is a server who listens on a specific port/IP. The client issues a connect. When the server accepts the connection, a new port is established. The client, only sends on the known port, but it is waiting on a port assigned by the OS.
Here is the sequence: Server Client Client2 on same host. Listen on port 23 Connect on port 23 (wait on port 7899). Connect on port 23 (wait on port 7900). Accept assigned to port 8543) Connect returns 0 (success) At this point, the Server is receiving on port 8543 and sending on port 7899. The client is sending on port 8543 and receiving on port 7899.
Accept assigned to port 8544) Connect returns 0 (success) At this point, the Server is receiving on port 8544 and sending on port 7900. The client is sending on port 8544 and receiving on port 7900.
On the server side, when the server issues accept(2) there is a unique port for both the client and server. Let's say the client computer is an SMP and the connects are issued at the exact same time. The OS will still assign unique port numbers on the client side.
This is not true. The source port is assigned by the kernel, and the destination port is programatically set by the server. They do not change after a connect()/accept(). Take a look at netstat or tcpdump output. There are _applications_ that do work like this, like ftp. But, by some reason, they teach that every tcp connection works this way in the university. []s Davi de Castro Reis