OSDev.org

My OS has a developing TCP/IP stack, but currently only support raw sockets (SOCK_RAW). I am now trying to add support for TCP. I understand the idea of the three-way handshake: client sends SYN, server responds with SYN+ACK, and the client responds with ACK.

I assume the first SYN (sent by the client) must be directed at the server's listening port (e.g. port 80 for HTTP), and the server responds with its SYN+ACK from port 80? In this case, how does the client know the port number allocated to the communicating socket (the socket returned to the server by accept() function)?

A socket consists of a tuple of numbers:

source ip address; source port; destination ip address; destination port.

In the scenario that you mention the destination port of the socket returned by accept() is port 80. The source IP address and port will be those determined by the client when it initiated the connection. These four numbers form a unique identifier.

The initial connection packet contains the source IP address and port number in the TCP header. The server simply uses those values as the destination IP address and port of the response packet.

In your scenario, the client uses a random port number for the entire connection, and the server always uses port 80 for all connections.

I think my question may have been misunderstood. If 3 different clients connect to port 80, the server uses 3 different sockets to talk to the 3 different clients - each socket must be bound to a different port. How does the server tell the clients which port is to be used for communication, as opposed to the listening socket?

Alternative wording: when I call accept(), I get back a file descriptor for a socket. When I look at the address that the socket is bound to, sin_port is not 80 (otherwise the server could only handle one connection at a time). It is some different port number that was allocated for this particular connection. How does the client, which calls connect(), know which port the server has chose for that communicating socket?

That is incorrect. The client continues to communicate on port 80. What makes you think that only one connection to port 80 can be handled at a time?

It's like post boxes in a post office. The IP address corresponds to the address of the post office, the port number corresponds to the box number. But more than one person can send letters to that box, and get replies from it. Their letters contain the address they were sent from so the recipient can separate the messages. He knows to send replies to letters from the bank to the bank and letters from the electricity company to the electricity company. TCP/IP does the same.

Oh I see. Guess I had a misconception.

So if accept() is called twice and 2 different connections are opened, each of the 2 sockets is bounds to port 80 but just has a different peer address?

The two sockets will both be bound to port 80 and the IP address of the server; but they will have different values for the IP address and port of the client (actually, it is conceivable that they have the same client IP address with different port numbers or different client IP addresses with the same port number, but the combination of the 4 items will be unique for each socket).

OK, I get it now. I'll start implementing TCP but I'll probably go for UDP first as it's easier to implement.

Ain't that the truth!

I'm actually in the middle of trying to implement a TCP/IP stack too, but it is very complicated with all the error checking and retransmittal of lost packets.