sf::SocketSelector limited to 64 connections on Windows?

[Minikloon]

Hi.

I'm currently working on a 2D Online RPG engine. After announcing the current development on a forum, I received much comments about SFML that disappointed me. Here are the two posts :

I've got to admit that I pretty much skimmed through the code since C++ in combination with libstdcpp, STL and OOP is quite horrible to go through, but here are some quick notes I took.

The choice of SFML_Net was a poor one, since it is a low-level socket wrapper (enet or RakNet are clearly superior if you don't want to implement the networking part yourself). The use of TCP, and more so select() frightens me: your server only supports up to 63 connections on Windows, and 1023 on Linux/Mac OS X. When using TCP you should at least use IOCP, epoll and/or kqueue in combination with a thread pool. What you are using is an approach that I wouldn't even use for UDP.

Using libstdcpp is a very bad choice. When designing the STL, they should only have supported certain trees like AVL-trees and red-black trees, not lists, vectors and whatever else you have. It isn't hard to implement the data types yourself, and you would usually benefit from the performance gain. Even worse is the use of std::string (there are many alternative classes that are faster, and dealing with string management yourself like done in C is going to be faster than any of those classes when done properly).

(...)

I actually prefer SDL over SFML for various reasons. SFML is merely a simple wrapper, SDL goes a few steps farther at most things. As for networking however, they are both equally horrible.

Related to a maximum of 64 connections when using select() in sf::SocketSelect::Wait().

The maximum amount of connections has nothing to do with TCP or UDP specifically. The selector makes use of the select() call which uses FD_SET. FD_SET has different definitions for different platforms. On Microsoft Windows it is a linear array that has a predefined amount of entries (always 64 if nobody resets it). Even worse, if you actually do reset it, then you are just wasting time: its insertion and deletion time is O(n), and the select itself might be O(n). With any other platform select() is somewhat better, supporting 1024 sockets with better access times (I forgot them though, but you can probably find them on the web), but still, select() is something you should not use.

Here's the original topic : http://www.touchofdeathforums.com/smf/index.php/topic,72558.0.html

Sorry for the big lecture.
Shortly, is it true that using SFML's selector would eventually limit connections?

Thanks,
Minikloon.

[Laurent]

Yes it's true. But it's not SFML, it's the underlying OS-specific implementation which has a limit.

I won't comment the rest of the message since it only reflects a particular point of view on a particular program that has particular needs. Unless of course if you want to discuss further about one of the mentioned points.

[sknnywhiteman]

Yes it's true. But it's not SFML, it's the underlying OS-specific implementation which has a limit.

Do you know if there is a limit in Ubuntu? Because, I plan on making a multiplayer game, and it'll MOST likely be ran in ubuntu. Is there a limit for that, because there will definitely be more than 64 connections..

[Laurent]

I think most Linuxes have a limit of 1024.

[Shimajda]

I had the same problem about year ago.
Windows event system is designed to handle max. 64 items, if you need more you should use threads - thats what i found on microsoft side.
I havent found any limits for linux (also ubuntu in my case) but its possible that i havent tested selectors for more than 1024 sockets.