You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment we have a UDP hole punching implementation that covers full-cone NAT as all it's doing is mapping an internal host:port address to an external host:port address. This is a weak implementation as any actual use of polykey is likely to find itself behind either a port-restricted cone NAT or symmetric NAT.
Any hole punching solution probably won't work with symmetric NAT so the relay can be used in that case. The main thing missing from our implementation to support port-restricted cone NAT is to have the intermediary node send a connection request to the NATted node with the other private node's public address. Section 3.2 on this guide is useful for understanding.
The text was updated successfully, but these errors were encountered:
At the moment we have a UDP hole punching implementation that covers full-cone NAT as all it's doing is mapping an internal host:port address to an external host:port address. This is a weak implementation as any actual use of polykey is likely to find itself behind either a port-restricted cone NAT or symmetric NAT.
Any hole punching solution probably won't work with symmetric NAT so the relay can be used in that case. The main thing missing from our implementation to support port-restricted cone NAT is to have the intermediary node send a connection request to the NATted node with the other private node's public address. Section 3.2 on this guide is useful for understanding.
The text was updated successfully, but these errors were encountered: