Server Processes

For a machine to offer a particular network service, such as telnet, a server process must “listen” for incoming connections on the associated well-known port number. A listening server waits for the kernel^[1] to report that it has created a TCP/IP connection to the server's port, then the server reads from the connection and takes whatever action it is supposed to.

The trace-cmd listen sets up a port to listen to waiting for connections from other hosts that run trace-cmd-record with the -N option. When a connection is made, and the remote host sends data, it will create a file called trace.HOST:PORT.dat.
Where HOST is the name of the remote host, and PORT is the port that the remote host used to connect with.

A listening server process uses a certain amount of system resources, even if it is idle. For example, it requires an entry in the kernel's process table. If a system offers 100 different network services, then 100 different listening server processes would need to run on the system, waiting for a connection to any of the corresponding 100 different port numbers. Of course, most of the time, these listening processes would be idle—they would “wake up” only when an incoming connection arrived.

Server sockets may accept multiple client connections. Conceptually, a server socket listens on a known port. When an incoming connection arrives, the listening socket creates a new socket (the child socket), and establishes the connection on the child socket. The listening socket is then free to resume listening on the same port, while the child socket has an established connection with the client that is independent from its parent. One result of this architecture is that the listening socket never actually performs a read or write operation and is only used to create connected sockets. The listening socket usually proceeds through the operations below.

1. Construct. Socket construction is identical for all TCP/IP sockets; see Socket Operations for details.
2. Bind. Binding for listening sockets is usually done only on the port, setting the IP address parameter to IPAddress.Any (MSDN). A Bind failure is usually due to another process already bound to that port (possibly another instance of the server process).
3. Listen. The listening socket actually begins listening at this point. It is not yet accepting connections, but the OS may accept connections on its behalf.

The backlog parameter to Socket.Listen is how many connections the OS may accept on behalf of the application. This is not the total number of active connections; it is only how many connections will be established if the application falls behind. Once connections are accepted, they move out of the backlog queue and no longer count against the backlog limit. The value to pass for the "backlog" parameter. Historically, this has been restricted to a maximum of 5, though modern systems have a cap of 200. Specifying a backlog higher than the maximum is not considered an error; the maximum value is used instead.
int.MaxValue can be used to invoke the dynamic backlog feature (Windows Server systems only), essentially leaving it up to the OS. It is tempting to set this value very high (i.e., always passing int.MaxValue), but this would hurt system performance (on non-server machines) by pre-allocating a large amount of scarce resources. This value should be set to a reasonable amount (usually between 2 and 5), based on how many connections one is realistically expecting and how quickly they can be accepted.

[1]kernel: The kernel is the core of the UNIX operating system. The kernel remains hidden from typical users.