Turbine, while you might probably right, don't misunderstand eXpl0it3r's questions: we genuinely need a proper use case as a basis for discussion. Otherwise we cannot properly understand the real need behind a feature request. Also, this is not a
push request: the API/implementation are not yet there (obviously). And this means that a lot of work will be required, hence a realistic approach from us: we cannot work on every feature ourselves because of lack of time so we rather focus on features that are closer to the root idea of SFML.
Now, that being said, this doesn't mean UPnP has no place in SFML. With SFML 3 we intend to change a few things in the network module. And having a proper discussion about this feature request makes sense to me.
ZeroZ30o, a few questions pop up in my mind:
- There probably exist some UPnP standalone libraries out-there (you mentioned at least one). Can they be used easily with SFML at this point? I mean, since I know nothing of the protocol, can a UPnP setup be made independently of SFML sockets? Similarly, would a UPnP API in SFML impact sf::Socket*.
- You said: "I don't want to use "hole-puching" to reach them since I don't have a server." How do you handle the discovery of peers from a given peer? Are there some server-less protocol for discovery of peers across the Internet?
- Are there some serious drawback, beside needing a server, to hole punching? Any other alternative we should know about too?
- UPnP seems to be a relatively big protocol. Don't we want something simpler in SFML, that would be more tailored to configuring NAT traversal and leave out many module of UPnP? Something like the Internet Gateway Device Protocol (which is use by UPnP I think), maybe?