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).
I feel like we are missing out on A LOT of neccessary error messages hereIf 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.
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.
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.
To me, these two points don't need any improvement. Unless you have stronger arguments.
Anything else? :P
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.
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 ?
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...... ;D
I am sorry if I come across as rudeYou don't, we're just discussing potential improvements and confronting points of view :)