UPnP

[ZeroZ30o]

I need to forward a port in my code, and UPnP seemed the only option to do so in code. After looking around for way too long, I've found no way to use the windows UPnP stuff ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa382303(v=vs.85).aspx ) and was pointed to libraries such as miniupnp ( https://github.com/miniupnp ).

I haven't tested the libraries yet, and I'm sure they'll work, but I thought it would be great if SFML had this feature, so yeah. Hi.

[eXpl0it3r]

And what's the use case for it?
Meaning, why do you think you need this feature? And can you think of other cases where UPnP will be needed?

[ZeroZ30o]

Well I need this feature to bypass my NAT box- the users I'm trying to contact might (really likely) be sitting behind a NAT box, which makes it impossible for me to send anything to their IP unless they sent me something themselves first, which would "allocate" a port on the router that would redirect traffic to them.
Also, I don't want to use "hole-puching" to reach them since I don't have a server.

So forwarding my port so that my router knows to redirect stuff to me would be the solution I need.
As for other use cases:
SFML could be used to create a "router manager" program that allows you to map/unmap/view port mappings.
On top of that, I'm pretty sure UPnP allows you to know router information (name, manufacturer) so it could give a lot of debug information (more specifically, this network information could be used to fine-tailor the netcode of a client's game).

Most importantly, it would encourage players to make multiplayer servers since you wouldn't have to tell them "figure out how to open this port". Risk of rain had this issue where most people didn't know how to do so, and as a result the fantastic multiplayer mode was used less frequently than it should've (IMO).

[Turbine]

I can't help but feel SFML is a bit too conservative in terms of accepting push requests and new functionality outside of the original scope.

There'll be a lot of people who'll opt for a more complete platform.

[Hiura]

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?

[Turbine]

It's not only useful for being decentralised - but for the server to be able to send UDP messages to clients.

[ZeroZ30o]

- 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*.

Yes, a library can be used independently afaik. I'm not really sure if it would interfere with sockets... miniupnp has a forum where you could ask, though.

- 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?

I will give them my router's IP with the forwarded port, which will then give me their IP (even if they're behind a NAT) which I can then use to make a P2P connection (the forwarded port doesn't need to be used anymore and can be deleted).

Well, yeah, normally UDP works for P2P but the problem is that NAT boxes (routers with several devices under 1 IP) make you unreachable unless you contact the person you're trying to be reached by first.

- Are there some serious drawback, beside needing a server, to hole punching? Any other alternative we should know about too?

No, hole punching just consists in having a server that relays the IP to other clients. It has a scary name but is harmless.
Any port mapping/forwarding method works, and there's a few other workarounds I believe, but I don't know enough to talk about.

- 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?

Well, I don't know how big UPnP is, and I'm not sure if you have to integrate ALL of it into SFML to make it work.

All I need is "AddAnyPortMapping()" and maybe "DeletePortMapping()" and I'll be able to relay everyone's real NAT IP so that P2P connections can be made.

[Mario]

Don't forget the fact that UPnP is disabled by default in most modern routers and the usage is discouraged due to security concerns (any malware could open up any port without the trouble to go through hole punching or anything like that.

As for implementation, as far as I know it's really just a set of specific HTTP requests for the most common uses (like adding or removing port forwards). You don't have to implement the full stack (which most is just for the server).

[Hiura]

I'm not really sure if it would interfere with sockets... miniupnp has a forum where you could ask, though.

It would be nice to have clear answer on that point -- I don't have time to look into this too much, so please do help us here. If you want something to be include in SFML you should be ready to put the energy to push forward and make it happen. Convince us that it's really useful and how it should work.

Ideally, if it doesn't impact the socket API it would be better to be implemented in a 3rd party library, possibly on top on SFML, because there's still the issue of the scope of this feature: is it really something for multimedia application or only for p2p softwares?

I will give them my router's IP with the forwarded port, which will then give me their IP (even if they're behind a NAT) which I can then use to make a P2P connection (the forwarded port doesn't need to be used anymore and can be deleted).

The forwarded port can be discarded, but not the IP -- this means a server (or a computer acting as a server like in your case) is still needed for discovery. UPnP doesn't solve all problems then. And if you need a server anyway, it makes the use-case for UPnP less "important", doesn't it?

Well, I don't know how big UPnP is, and I'm not sure if you have to integrate ALL of it into SFML to make it work.

All I need is "AddAnyPortMapping()" and maybe "DeletePortMapping()" and I'll be able to relay everyone's real NAT IP so that P2P connections can be made.

Have a look at least at the wikipedia page on UPnP and IGDP -- the latter being probably closer to what you actually need.

Having a partial implementation of a protocol is something I'd avoid.

Thanks Mario for pointing out these potential security and configuration issues. We should keep this in mind.

[ZeroZ30o]

After a bunch of thinking and looking around -you seem to be right, in that it's not worth to implement this feature: UPnP is disabled on most routers by default due to security issues, which kinda defeats the purpose of "practicality" that I was going for.