0
  1. Every connection - Server ( unique IP address + host number) + client. This is a unique combination of a connection.

  2. Such combinations can be established based on the number of file descriptors supported by the OS. For instance, my machine has the following limit -

    cat /proc/sys/fs/file-max 380594

  3. When we say listen(sock_fd, 5); Here 5 means the number of connections who will not be denied connections. In fact, they will be put into a pending state. Here, let's assume all the fd's are for the socket connection. Then the 389595th till 389599th connection will be put into a pending state. This will be handled once the fd are available. Am I correct on it?

dexterous
  • 6,422
  • 12
  • 51
  • 99

1 Answers1

1

Not quite.

Re (1), I don't know what you mean by 'host number'. A client can have two connections to a given server differing only by source port. So to uniquely identify a connection, you need the client IP and port number 2-tuple (pair), and the server IP and port-number 2-tuple.

Re (2), there are several limits at play here. Each open connection requires a file descriptor, but life is not that simple. Connections in TIME_WAIT for instance may have had their file descriptor closed, but are still a 'connection' from the OS point of view in that they are their precisely to associate stray connection packets with. Further, there may well be an overall limit to the number of files, but there will be other limits. For instance, there is a limit to the number of open fds per process (see getrlimit). This question has been asked several times before - see What is the theoretical maximum number of open TCP connections that a modern Linux box can have and Increasing the maximum number of tcp/ip connections in linux

Re (3), no, the backlog does not work like that as it is per socket in a listen state. The backlog number indicates the maximum number of TCP connection that the listening socket will acknowledge that have not yet been accepted. When a new TCP connection attempts to connect on a given listening socket, the OS has to queue the existence of that pending connection until it is transferred to a new socket (to handle the particular connection) using accept. The backlog number is simply the maximum depth of that queue. This has nothing to do with file-max unless every FD on the system was used by a single process listening on a single socket (a rather unlikely scenario).

Community
  • 1
  • 1
abligh
  • 24,573
  • 4
  • 47
  • 84
  • Regarding point 3, I have heard that the limit is around 10 or 15. If that is the case then how come billions of connections are established in the webserver. how is it possible? Please throw somelight on it. I won't mind, if you can append in your answer. – dexterous Feb 09 '14 at 14:44
  • 1
    The backlog is the max number of **simultaneous** clients that can be in a **pending state waiting for acceptance** at any given moment. As long as the server has a decent sized backlog and is calling `accept()` often enough to keep the pending queue from filling up, the server can easily handle hundreds/thousands of clients. Most servers use a worker thread to keep calling `accept()` and then use separate threads/processes to handle clients that have been accepted. – Remy Lebeau Feb 09 '14 at 15:55
  • The backlog limit is the maximum depth of the queue of connections that have been opened *but have not been accepted*. Webservers achieve many simultaneous sessions by accepting connections as soon as possible (and possibly farming them off, e.g. into separate processes or threads). Under some circumstances it is possible for multiple `listen` to run simultaneously as well. – abligh Feb 09 '14 at 16:11
  • 1
    The size of the default backlog queue can be found at /proc/sys/net/ipv4/tcp_max_syn_backlog which on my system is 128 - considerably more than 15. This is documented in `man (2) listen`. – Duck Feb 09 '14 at 16:48