Hacker News Reader

Comment by austincheney | Hacker News Reader

This isn't a limitation of PeerJS or event WebRTC. This is a limitation imposed by IPv4 implementations that include NAT and PAT. These services in the middle are there to create tunnels as a mutually available broker for all concerned end points. Even after the connection is established additional third party services are still required for authentication, identity management (trust/certificates/keys), and possibly codec resolution.

https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API#...

If all parties were IPv6 first they would still need the secondary services mentioned above, but they could likely broker a direct peer-to-peer connection without a separate service provider.

View on HN

It very much is a limitation of WebRTC. Real sockets perform better than webrtc since they can attempt NAT traversal or talk to the CPE to perform port forwarding, something that you can't do from a browser. Otherwise p2p filesharing wouldn't work. You may not get perfect connectivity this way since not all NATs can be bypassed but on the other hand webrtc does not work at all without signalling.

Sockets, TCP sockets, are TCP packets in a stream of a given format. TCP is layer 4. IP is layer 3. Other socket protocols are layer 7 or an implementation of UDP.

That being said there is no bypassing of NAT, but you can tunnel through it provided an open connection from within the network. For example HTTP cannot connect to a computer inside a NAT network but it can send a response to a request from inside that network.

Most P2P services make use of a central server to connect users no differently from instant messaging, and thus these services are generally considered a backdoor into a network. BitTorrent is different because it makes use of two protocols doing different things simultaneously.

> That being said there is no bypassing of NAT

There are several.

https://en.wikipedia.org/wiki/NAT_traversal

The approaches don't always work, but often are sufficient for consumer grade routers.

> For example HTTP cannot connect to a computer inside a NAT network but it can send a response to a request from inside that network.

Well yeah, that's HTTP. It's a client-server protocol. There is no coordination in connection setup. And it's TCP. It's not designed to do the necessary gymnastics to establish incoming connections through a NAT. So HTTP being HTTP is not an argument for NAT traversal being impossible. a) it's much easier with UDP where you can multiplex incoming and outgoing traffic over a single socket and it'll work for any remote peer as long as your UDP NAT uses EIMs.

This is also why torrents have trackers - unless you scan 0.0.0.0/0, you'd have no idea what IPs are peers for a torrent without a tracker.

You can use DHT / Kademlia for this purpose

Reply on news.ycombinator.com