Is there any planned improvements on the network package?

[Haikarainen]

The biggest lack in SFML is, if you ask me, the networkpackage. IIRC the UDP-socket-class has no guarantee-functionality whatsoever that the packets will get where they are headed. Also it doesn't really feel complete. Take this for example:

Socket::Status SocketImpl::getErrorStatus()
{
    switch (WSAGetLastError())
    {
        case WSAEWOULDBLOCK :  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;
        default :              return Socket::Error;
    }
}

This is the case for the windows- and linux-implementations, I feel like we are missing out on A LOT of neccessary error messages here.


I would be joyed to see some improvements on the network library and I hope it is highly prioritized!

[Laurent]

IIRC the UDP-socket-class has no guarantee-functionality whatsoever that the packets will get where they are headed.

That's what UDP means. The protocol is explicitely defined like this, and has its own use cases. People who try to make UDP robust just waste their time (or have a very specific use case).
If you want robustness, use TCP.

I feel like we are missing out on A LOT of neccessary error messages here

If you say this just by looking at the code, then I guess you don't really have a need there. If you have a real use case that would require more precise error codes, then I'll be glad to see it.

I would be joyed to see some improvements on the network library and I hope it is highly prioritized!

To me, these two points don't need any improvement. Unless you have stronger arguments.

Anything else?

[Haikarainen]

That's what UDP means. The protocol is explicitely defined like this, and has its own use cases. People who try to make UDP robust just waste their time (or have a very specific use case).
If you want robustness, use TCP.

For a large number of clients and a large number of data, UDP is WAY faster when it is implemented right (and not like in the 90ies). This is a fallback since you'd have to recompile SFML to implement this functionality.

If you say this just by looking at the code, then I guess you don't really have a need there. If you have a real use case that would require more precise error codes, then I'll be glad to see it.

One real usecase is all of those times when you try and debug your code and all you get is disconnected (and  not if it is connected to even begin with, if it timed out, if connection was reset etc). Cmon you cant say you dont get this point!

To me, these two points don't need any improvement. Unless you have stronger arguments.

Anything else?

Shame.

[Laurent]

For a large number of clients and a large number of data, UDP is WAY faster when it is implemented right (and not like in the 90ies). This is a fallback since you'd have to recompile SFML to implement this functionality.

Which "functionality"? What is the "right implementation"?

One real usecase is all of those times when you try and debug your code and all you get is disconnected (and  not if it is connected to even begin with, if it timed out, if connection was reset etc). Cmon you cant say you dont get this point!

I get it but I'm still not sure if it is really needed. My philosophy is to ignore features that might one day be useful. Let's keep the API as simple as possible as long as users are ok with that.

[Hiura]

A word about UDP : yes, one can add functionality on top of this protocol like GBN or SR to ensure packets transmission. But this is very specific to the application. So doing so in SFML would be complicated (e.g. which protocol should SFML implement? how to disabled it? ...) for very few people.

If you need very specific networking tools you should rather use a more experienced library than SFML.

I get it but I'm still not sure if it is really needed.

I also think this could be useful : e.g. you keep scores in a multiplayer game and apply penalty to players who quit the game harshly but not to players who have a bad internet connection (in order to keep their desire to play the game!). No ?

[Laurent]

I also think this could be useful : e.g. you keep scores in a multiplayer game and apply penalty to players who quit the game harshly but not to players who have a bad internet connection (in order to keep their desire to play the game!). No ?

Hum......

[Hiura]

sorry. 

[Hiura]

In fact I was wrong for two reasons :

First, one has to know exactly when these kind of errors happen and what they really mean. This is quite complicated in fact - looking at the RFC and other documentation clearly shows that.

Moreover, designing a protocol for an application, that relies on errors that are not generated by the application itself but by an external entity, is no good design!

There is also an argument against my previous post (the two others are more general) :

And after some thoughts it occurred to me that sending a "quit" packet when the application exists is enough to detect user's voluntary will to exit the app vs an error on the network.

[Haikarainen]

I might've  been wrong about the UDP-extras since I'm not that experienced with such lowlevel networking (even though they are worthy some discussion), but regarding the errorcodes, I really feel it is missing some debugging functionality.

When developing my network classes for a project of mine (linuxserver, win/linux-client), I had a really hard time debugging it since I really didnt have much more than "disconnected" to go from. Also it gives you the ability to expose more information to end-users of your products that utilize SFML when something goes wrong. This is both beneficial for the end-user (faulty NIC/Router hardware and software, bad connection causes timeouts, etc), as well as the developer(me) to fix potential bugs, as well as you, in case my products bugs derive from bugs in the SFML library.

I am sorry if I come across as rude, that is not my intention, SFML is a great library and I'm sure you are very busy, I just want to spark some discussion on the post 2.0RC-development of SFML.

Cheers.

[Laurent]

Socket error codes would probably require some deep tests, because:
1. I've never (had to) use them, although I've done a lot of network programming
2. I suspect that error codes look more precise/helpful than they really are, and that implementations don't use them all

I am sorry if I come across as rude

You don't, we're just discussing potential improvements and confronting points of view