C++ - How should i go about "dodging" port forwarding?

[Jim70 128]

I'm working on a game that relies on users creating their own servers. Howerver, i don't want to make the player port forward.

I understand that minecraft gets away without hole-punching and such, but that's not what im going for. It will be max 6 players per server.

Iv'e found some options...

• Switch to steamworks for networking (has built in nat hole punching)
• Use RakNet's hole punching solution (Not sure if the free nat server is still up)
• Use upnp to programatically port forward(Black magic to me)

Have i missed anything? Should i just switch to steamworks?

[Shannon Barber 1682]

Minecraft requires port-forwarding unless they added something fancier in the latest version.

  

I would suggest having a backup relay server in case hole-punching or IGD/UPnP fail.
The next generation of routers may finally get to the point that hole-punching stops working. It is technically an exploit and connection hijacking.

Some customers will already have more sophisticated stateful firewalls that will prevent hole-punching.

 

IGD is the designed solution to this problem but I haven't personally programmed code to use it so I cannot attest to it's reliability.
It seems to work well.

IGD will only work at home with consumer NAT/cable/dsl routers and will not function if they are using a commercial (or vanilla) NAT solution.

(e.g. In college I routed our fraternity house Internet through Netware BorderManager for NAT.)

 

Is Steamworks fully functional if you are not greenlit?

It provides hole-punching and relay if that fails but I don't know if the relay will work for anyone.

If the relay does *not work for everyone and/or if you never intend to go for greenlight then consider using libijngle directly.

Edited September 8, 2016 by Shannon Barber

[Jim70 128]

Steamworks is fully functional even if you dont get a game to steam. And after all, its working for alot of games.

[hplus0603 11444]

IGDP is much more of a security problem than proper "automatic" NAT with STUN.
The nice thing with NAT/STUN is that a router just needs to be IP protocol conformant for it to work.
Routers that allocate a different random external port for different destination hosts for traffic that comes from the same source host:port are, arguably, not actually IP protocol conformant, and users who want the "it breaks everything" behavior of this behavior will also not turn on IGD.

My bet would be that, long term, NAT-STUN and the growth of IPv6 will be the majority use case (like it is today,) and those who want to go from 80% compatibility to 90% compatibility have to do both IGD and NAT-PMP.
And the easiest thing to do is to trust some library provider (such as Steamworks) and use their SDK.

[frob 45278]

IGDP is much more of a security problem than proper "automatic" NAT with STUN. ... {assorted good stuff}

 

@hplus; I love how you don't even pause for the acronyms and jargon, especially after he wrote that upnp was "black magic to me". Those short paragraphs in your post post made me reflect on some history. Nostalgia is fun, good times were enjoyed by many.

 

Have i missed anything? Should i just switch to steamworks?

 

Yes, you missed some things, but based on how you worded your question they probably don't matter to you.

Hplus is a great resource for this, but it is understandable if the post above is acronym-heavy. He became a small part of internet history on the topic.  One of his blog entries (they weren't called blogs back then) on finding a way around NAT grew to become a resource and guide for people on later standardization committees. I think he coined the term "NAT punch-through", which evolved into "punching a hole through NAT" which evolved into the term "hole-punching" you used.  Modern NAT systems (that first came out in the late 1990s) were still fairly rare when he published some of his early experimental methods on punching through them with what was sometimes considered a flaw in cheap consumer devices. While he wasn't the only one to discover it, the short experiment and tutorial pages he wrote helped many people solve their problem. Now those methods are considered the standard way to go for IPv4 if you're looking for an easy solution.

 

 

It is certainly easier to use an existing library and existing server, like the ones Steam provides.  If you just want to get it done and call it a day, use an existing library.

 

 

There are new options becoming available, and even commonly-used libraries cannot get through all networking environments.  But learning all about them will require some serious effort.  If you want to understand how it works well enough that you can build your own solutions on modern equipment, you've got a lot of documentation to read and about 20 years worth of history to learn.  You can look up how NAT works, why it is a problem, how Internet routing works, and the solutions that have been implemented along the way to reach through them.  All the acronyms used above 

[hplus0603 11444]

Check's in the mail, frob :-)

Seriously, though, we use acronyms because there's just too much stuff to keep track of!
The good news is that all of these acronyms are very easy to Google, and the Wikipedia articles on them are generally fairly good starts to get going.
And because it's built by engineers, any engineer who wants to work through it, can work through it. Start at any one word, and read about it. Make note of the concepts that you need explanation for. Read about THOSE. Repeat! Eventually, you will have it.
The amount off effort required to get into it from scratch is kind-of high, though, because as you say, there are decades of history leading up to our current history.