NAT Traversal: Difference between revisions
Jump to navigation
Jump to search
Adamcolton (talk | contribs) No edit summary |
Adamcolton (talk | contribs) |
||
| Line 12: | Line 12: | ||
== Theory == | == Theory == | ||
The techniques break down into two groups. Most solutions give the user a public facing IP and Port. Hole-punching (potentially) does not. It can assign a different port for each connection. | The techniques break down into two groups. Most solutions give the user a public facing IP and Port. Hole-punching (potentially) does not. It can assign a different port for each connection. | ||
So we need these pieces of information: | |||
* Node ID | |||
* IP:Port | |||
* Direct Connect | |||
* STUN server | |||
* Router Type | |||
STUN server and Router type are only important if Direct Connect is false. If both our router and their router is symmetric and we both don't have Direct Connect, no connection is possible. | |||
[[Category:Waxnet]] | [[Category:Waxnet]] | ||
Latest revision as of 16:37, 2 March 2016
Go Code https://golanglibs.com/dig_in/upnp
- https://godoc.org/github.com/ccding/go-stun/stun
- https://github.com/huin/goupnp
- https://github.com/prestonTao/upnp
Theory
The techniques break down into two groups. Most solutions give the user a public facing IP and Port. Hole-punching (potentially) does not. It can assign a different port for each connection.
So we need these pieces of information:
- Node ID
- IP:Port
- Direct Connect
- STUN server
- Router Type
STUN server and Router type are only important if Direct Connect is false. If both our router and their router is symmetric and we both don't have Direct Connect, no connection is possible.