sf::Socket::Status - more flags

[StDH]

i'd really like to see more flags for sf::Socket::Status since i saw

https://github.com/SFML/SFML/blob/master/src/SFML/Network/Win32/SocketImpl.cpp#L72

Socket::Status SocketImpl::getErrorStatus()
{
    switch (WSAGetLastError())
    {
        case WSAEWOULDBLOCK:  return Socket::NotReady;
        case WSAEALREADY:     return Socket::NotReady;
        case WSAECONNABORTED: return Socket::Disconnected;
        case WSAECONNRESET:   return Socket::Disconnected;
        case WSAETIMEDOUT:    return Socket::Disconnected;
        case WSAENETRESET:    return Socket::Disconnected;
        case WSAENOTCONN:     return Socket::Disconnected;
        case WSAEISCONN:      return Socket::Done; // when connecting a non-blocking socket
        default:              return Socket::Error;
    }
}

it would be nice to know if connection was timed-out, reseted or aborted, and it isn't even so much job to do.

Sometimes you want to know what has happened on the socket.

[Laurent]

Sometimes you want to know

When? And to do what?

If you want your feature request to be considered seriously, you'll have to give use cases and stronger arguments. When it's just "we can do it, so why not?", we usually discard the request quickly

[StDH]

i'm requesting this because it would be useful on my game-server or any network-server generally.

Example in game:You're in a team that you cant normally leave, your connection gets timed-out but server show that you've disconnected, you get punished for violating game rules or so because you were not supposed to leave in any way (play until game timer ends).


EDIT2:
WSAECONNABORTED -> If client connection was aborted by unknown software
WSAECONNRESET  -> This happens if peer application on the remote host is suddenly rebooted or stopped

[eXpl0it3r]

That's quite an edge case, plus not really that useful since I can easily just unplug my PC's ethernet cable and make it look like a timeout. I'm sure there are even software solutions for that.

[Laurent]

binary1248 would probably know better, but I'm pretty sure that you shouldn't rely on low-level error codes to make your use cases work right. The only reliable way to know that a client disconnected on purpose is to handle it in high-level logic code, ie. make him exchange a specific message with the server before he disconnects the socket. Any other disconnection must be considered unexpected, and I don't think you can get much more information about what happened anyway.

[binary1248]

Relying on transport layer behaviour to determine what happened "higher up" is never a good idea. Because the OSI layer model was designed with layer independence in mind, there doesn't have to be a causal relationship between something the user did or did not do and what happens at the transport layer. The only scenario that I can think of where one could theoretically (still unreliable) deduce that the user caused the application to end "normally" would be in the case of a full 4-way connection tear down. This really only happens if nothing goes wrong in any of the layers, which implies that they also give some effort to follow the specification (which SFML already fails to do with its sf::TcpSockets ).

In the hypothetical case where you would punish players if you did detect a 4-way tear down, don't you think it would be unfair to punish the only players who did "behave" and closed the game properly? You would be implicitly rewarding players who worked around the system by e.g. unplugging their network cable.

I think it is kind of obvious that this isn't an easy problem to solve, and adding a few more status codes to sf::Socket definitely won't help either. If you take any of the AAA game developers as an example, they don't differentiate between a temporary power outage or someone who purposely cut their network cable in 2 pieces. What a good game should do, is provide players a way to recover from such situations by reconnecting within a given time period. People will have much less to complain about if they get a chance to demonstrate their good will (and bad luck) as opposed to instantly being penalized for something unintentional that they could not prevent.

But at the end of the day there is always the one true way of solving this problem: Design your game in a way that rewards people for staying until the end.