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
With #84, js-polykey will have all it needs to do NAT traversal reliably with just TCP hole punching and TURN relay server functionality. In the grand scheme of things, however, this is not completely adequate as it leaves out STUN functionality. With thousands of private nodes connecting to a single public node, TURN sockets will fill up quickly and a the relay traffic will become a burden on infrastructure. STUN will alleviate some of this burden by first trying to connect the private nodes directly (TCP hole punching tries to do this blindly but doesn't work behind symmetric NATs).
With #84, js-polykey will have all it needs to do NAT traversal reliably with just TCP hole punching and TURN relay server functionality. In the grand scheme of things, however, this is not completely adequate as it leaves out STUN functionality. With thousands of private nodes connecting to a single public node, TURN sockets will fill up quickly and a the relay traffic will become a burden on infrastructure. STUN will alleviate some of this burden by first trying to connect the private nodes directly (TCP hole punching tries to do this blindly but doesn't work behind symmetric NATs).
There are some projects that already attempt to do this but I have found none in pure TCP (this is another reason why we should wait, STUN might require js-polykey to employ UDP transports to fully utilise it's potential.):
https://www.npmjs.com/package/stunsrv
https://github.com/summerwind/node-stun
https://github.com/enobufs/stun
Related to #37
The text was updated successfully, but these errors were encountered: