What happens when we say "listen to a port"?

Question

When we start a server application, we always need to speicify the port number it listens to. But how is this "listening mechanism" implemented under the hood?

My current imagination is like this:

The operating system associate the port number with some buffer. The server application's responsibiliy is to monitor this buffer. If there's no data in this buffer, the server application's listen operation will just block the application.

When some data arrives from the wire, the operating system will know that and then check the data and see if it is targeted at this port number. And then it will fill the corresponding buffer. And then OS will notify the blocked server application and the server application will get the data and continue to run.

Question is:

• If the above scenario is correct, how could the opearting system know there's data arriving from wire? It cannot be a busy polling. Is it some kind of interrupt-based mechanism?

• If there's too much data arriving and the buffer is not big enough, will there be data loss?

• Is the "listen to a port" operation really a blocking operation?

Many thanks.

Answer 1

While the other answers seem to explain things correctly, let me give a more direct answer: your imagination is wrong.

There is no buffer that the application monitors. Instead, the application calls listen() at some point, and the OS remembers from then on that this application is interested in new connections to that port number. Only one application can indicate interest in a certain port at any time.

The listen operation does not block. Instead, it returns right away. What may block is accept(). The system has a backlog of incoming connections (buffering the data that have been received), and returns one of the connections every time accept is called. accept doesn't transmit any data; the application must then do recv() calls on the accepted socket.

As to your questions:

• as others have said: hardware interrupts. The NIC takes the datagram completely off the wire, interrupts, and is assigned an address in memory to copy it to.

• for TCP, there will be no data loss, as there will always be sufficient memory during the communication. TCP has flow control, and the sender will stop sending before the receiver has no more memory. For UDP and new TCP connections, there can be data loss; the sender will typically get an error indication (as the system reserves memory to accept just one more datagram).

• see above: listen itself is not blocking; accept is.

Answer 2

1. Your description is basically correct except for the blocking part. OSes normally use interrupts to handle I/O events like arriving network packets, so there is no need to block.
2. Yes, if too many connection attempts happen at the same time, some will get bounced. The number of connections to queue is specified when you call listen or its equivalent.
3. No, it is not. The OS raises an event on your control socket when a connection arrives. You may choose to block while waiting for this event, or you may use some nonblocking (select, poll/epoll) or asynchronous (overlapped I/O, completion ports) mechanism.