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

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

The typical TCP server sequence of calls is

socket() -> bind()-> listen() -> accept() -> read()/write() -> close()

A socket created by socket function is assumed to be an active socket (that will issue a connect()). listen() function converts unconnected socket to passive socket. This means that kernel should start accepting incoming connection requests. The second argument to listen() function specifies the total queue length for a given listening socket of 2 queues - (1) complete connection queue - 3 way handshake completed for connection (2) incomplete connection queue - SYN received from client waiting for completion of 3 way TCP handshake

Finally accept() is called by TCP server to return the next completed connection from the front of completed connection queue. If accept() is successful it returns a new socket descriptor that refers to the TCP connection between client and server.

Now to answer your question * The networking stack in the operating system kernel, reads each incoming IP packet, classifies the packet according to it's TCP/IP header fields. The arrival of IP packet on wire is serviced as an interrupt by an Ethernet driver and from there onwards kernel mode TCP/IP stack takes over

• With respect to data if you mean the SYN packet, Posix.1g has an option to either ignore the new incoming SYN or send a RST to the client when the connection queue is full. Data that arrives after 3 way handshake completes, but before server calls accept should be queued by server TCP up to the size of connected socket's receive buffer.

• listen() operation is a blocking call and returns after the connection state is said to passive to allow incoming TCP client connections.

Refer to Wikipedia for more details on TCP protocol -handshake, sequencing and acknowledgments for reliable transmission.

This book gives a very good details on TCP/IP Unix network programming and can provide more insight on this topic.

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.

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.