Max number of TCP sockets

[netrick]

What is maximum number of concurrent TCP sockets using SFML networking on Linux system?

I'm not asking about bandwith/performance thingy, I'm just interested in SFML limitation. Because for example, ENet has hard-coded limit of 4096 concurrent connections. I'm wondering if there is such a limit in SFML.

And the second question, is there a hard-coded limit of maximum sockets that can be put in sf::SocketSelector?

Thanks

[Laurent]

1. There's no limit in SFML, you'll have to search for limits at the OS level, if any. All I can think of, is the maximum number of open descriptors per process (4096?).

2. No, but it's trickier: the limit is on the highest descriptor value (FD_SIZE?). So, let's say you open a big number of files, then even a single socket may not be able to be added to a selector, because its descriptor would be too high.

[Jesper Juhl]

On Linux, at least, if SFML used epoll() these limitations could be removed.

[binary1248]

The default ulimit -n value on debian is 1024. You can change this if you want (and more importantly, if you know what you are doing).

Like Laurent already said, the number of sockets that you will be able to stick into a selector is based a bit on luck. The kernel will normally create file descriptors in increasing order, so if you create your sockets before you open other files, you will be able to add more of them to the SocketSelector. The hard limit of FD_SETSIZE (1024) still holds however. SFML wasn't designed to be used in massively scalable network applications, but this might change in the future .

If you want to use a library with a similar API to SFML without these limits, you can try out SFNUL. I wrote it when I hit SFML's limit during stress testing. SFNUL should be able to handle at least 10000 concurrent connections. At that point, my test environment just couldn't keep up anymore .

[netrick]

Thank you for your answer

I will certainly have a look into SFNUL. And epoll() is interesting, however I'd rather use something which is higher level.

So far it looks like that on Linux the number of concurrent TCP sockets is only limited by number of ports. Of course the selector amount is limited and it seems like it's good idea not to use selector on big server.

So I want to ask if it is a good idea to handle many (about 10k) TCP sockets this way:

- I create 10k sockets, set each of them to non-blocking mode and store them in vector
- my server has infinite main loop, and inside it I do:

foreach(&socket : socketContainer)
{
         if(socket.receive (...) == sf::SocketDone)
          {
               //handle received data here
          }
}
 

As for CPU and bandwith performance, it should be no problem on my server so I don't ask about it. I want to know if it is proper to handle TCP sockets in such way, without using selector.

[Laurent]

This would work, but be aware that it will eat 100% of your CPU since you'll constantly loop & check even if there's nothing to do. Only blocking sockets can save CPU when nothing happens.

[netrick]

Yes I know, but my server is real time app so it always takes 100% CPU. Thank you for help.