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 cur

Answer 1

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

Hardware tells the OS by sending an interrupt, a hardware interrupt causes an event handler to run.

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

Yep, but TCP uses a windowing mechanism. The OS tells the other end how much buffers it has, it can do this dynamically. So it may start with "I have 4k of buffers". After 2k has arrived the other end can send 2k more but we can acknowledge the first 2k. If the other end sends to much to quickly our OS will discard it. It will also tell it to slowdown and re-acknowledge what it has already got. When buffers are free we can tell the other end to continue. It will resend what we have not acknowledged. The OS does all this for us when using TCP, but not for UDP.

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

Yes and No. It will not return until it is done, but there is not much to do: Listen does next to nothing, just a note to the OS. "If someone tries to connect to that port it is me that will handle it". It is accept that waits for the connection. And accept that can block (as well as read/write/...).

The OS need not allocate any buffer this early. Listen wrote some meta data into an OS table. A connection comes in uses the next connection handling buffer. Later data comes in and uses a data buffer, data buffer need not be allocated per connection. Lots of pending data on one connection could cause the available buffers on other connections to be reduced. Your OS may have policies and mechanisms to make things fair.