1
Network / Problem with FD_SETSIZE on Windows
« on: July 15, 2014, 10:34:01 pm »
This commit (June 9) appears to break SocketSelector on Windows:
https://github.com/SFML/SFML/commit/228038fa8a9cf0c90e1067dcc12c177bb77c8bab
Related issues:
https://github.com/SFML/SFML/issues/153
https://github.com/SFML/SFML/pull/628
The check that this code performs:
Here's some simple code demonstrating the problem:
I was able to fix the issue locally by reverting the noted commit. Any insight? Should this go on the GitHub tracker?
https://github.com/SFML/SFML/commit/228038fa8a9cf0c90e1067dcc12c177bb77c8bab
Related issues:
https://github.com/SFML/SFML/issues/153
https://github.com/SFML/SFML/pull/628
The check that this code performs:
if (handle < FD_SETSIZE)
{
FD_SET(handle, &m_impl->AllSockets);
int size = static_cast<int>(handle);
if (size > m_impl->MaxSocket)
m_impl->MaxSocket = size;
}
else
{
err() << "The socket can't be added to the selector because its "
<< "ID is too high. This is a limitation of your operating "
<< "system's FD_SETSIZE setting.";
}
isn't applicable to Windows. Under Windows, FD_SETSIZE describes the maximum number of sockets which an fd_set can contain, rather than the maximum file descriptor, and is also very low (64 on my system). This means sockets with a descriptor of 64 or above (which seems to be most of them) can't be added due to this check, even though without this check it works fine.{
FD_SET(handle, &m_impl->AllSockets);
int size = static_cast<int>(handle);
if (size > m_impl->MaxSocket)
m_impl->MaxSocket = size;
}
else
{
err() << "The socket can't be added to the selector because its "
<< "ID is too high. This is a limitation of your operating "
<< "system's FD_SETSIZE setting.";
}
Here's some simple code demonstrating the problem:
#include <SFML/Network.hpp>
int main() {
sf::TcpListener listener;
sf::SocketSelector selector;
listener.listen(15000);
selector.add(listener);
}
int main() {
sf::TcpListener listener;
sf::SocketSelector selector;
listener.listen(15000);
selector.add(listener);
}
I was able to fix the issue locally by reverting the noted commit. Any insight? Should this go on the GitHub tracker?