Actually, I am confused.
In the Connect function, regardless of whether or not the socket is in blocking mode (block until something happens), or non-blocking mode (return as soon as possible), you have a timeout value.
Surely, if a timeout value is specified, the socket, by default, is non-blocking (it doesn't wait for something to happen)? Because it will quit out after a given time?
If select() is passed a NULL pointer for it's time-value, then it's treated as blocking. So surely, you'd want to re-write the Connect function, so that the time-out value only applies to non-blocking sockets?
This would solve both issues.
I took a further look at the code and after trying it, I found the key reason that the non-blocking socket won't connect is because when the socket is already connected, it returns an error. You could easily solve this by including:
if(Status == Socket::Error)
{
if(WSAGetLastError() == WSAEISCONN)
{
return (Status = Socket::Done);
}
}
Because if the purpose of the function is to connect, then it should return true if there is already a connection. I found on the first pass, select didn't catch it (default timeout value), on the second pass a 10037 (operation already in progress), and finally an 10056 (connection already established), which SFML should return not as an error, but a success (as the functions role is to connect - if it's already connected, it's succeeded).
The above function should be placed between:
Socket::Status Status = SocketHelper::GetErrorStatus();
//Here
// If we were in non-blocking mode, return immediatly
if (!IsBlocking)
