handling c10k in linux

Question

using linux BSD socket, what happens if the number of active connection overflows the system limit? will accept call return error?

and even if the system can accept indefinite socket connection, can it be more than the size of integer max value?

a socket descriptor is a 4-byte integer value. is it fair to say it is theoratically impossible to maintain more than 4294967295 active TCP connection with single process in 32bit system? (assuming that hardware and OS can support this. and service quality does not matter. we simply want to maintain active TCP connection)

it may be a stupid question but I am curious.

score 1 · Answer 1 · answered Nov 27 '12 at 14:02

From the accept(2) manpage on a Linux system:


       EMFILE The per-process limit of open file descriptors has been reached.

       ENFILE The system limit on the total number of open files has been reached.

       ENOBUFS, ENOMEM
              Not enough free memory.  This often means that the memory allocation is limited by the socket buffer limits, not by the
              system memory.

So yes, in any remotedly sane configuration accept will report EMFILE or ENFILE. If you set the fd limits to some sky-high value, you'll likely get ENOBUFS/ENOMEM instead. You'll likely hit these limits long before the INT_MAX limit on the int datatype.

score 1 · Accepted Answer · answered Nov 27 '12 at 14:36

Since file descriptors are ints then you obviously can't go above 4G file descriptors. This is true even on 64-bit systems because sizeof(int) is still 4. In theory you could open more file descriptors across multiple processes. Even if you increase all the /proc limits you're likely to run out of kernel memory first.

Per-socket allocations in the linux kernel are in the kilobyte range so even on big servers (with many GB of ram) the maximum connection count is measured in millions, not billions.

handling c10k in linux

2 Answers2