Hacker News Reader

Comment by baobabKoodaa | Hacker News Reader

P2P connections over the web are usually not possible due to typical consumer router configurations and bad decisions in the design of WebRTC protocol.

The vast majority of these P2P web projects, including WebTorrent, is actually using proxy servers to fake the illusion of P2P connectivity (to be specific, they are using TURN servers to proxy traffic).

Here's a stackoverflow question I asked about this and burned a 100 bounty on it with no answers: https://stackoverflow.com/questions/70624649/webrtc-fails-to...

View on HN

This isn't true.

In 2017 appear.in published some numbers. They saw ~15% were not able to do P2P. https://medium.com/@fippo/what-kind-of-turn-server-is-being-...

Reading your stackoverflow link my guess is that you aren't using STUN. A P2P connection can't be established without a NAT hole punch.

Also if possible I would avoid the terms `Full-cone NAT` and `Symmetric NAT` they don't do a good job of describing what is actually happening. NAT Mapping/NAT Filtering is the best way to describe it. I wrote a little bit about it here [0]. To see what type of NAT you have try stun-nat-behaviour[1]

[0] https://webrtcforthecurious.com/docs/03-connecting/#nat-mapp...

[1] https://github.com/pion/stun/tree/master/cmd/stun-nat-behavi...

> In 2017 appear.in published some numbers. They saw ~15% were not able to do P2P. https://medium.com/@fippo/what-kind-of-turn-server-is-being-...

Thank you for this. I guess P2P connectivity is more often possible than I thought! For the record, I have tried to form P2P connections with multiple different devices and multiple different network conditions, and although I have been able to achieve connectivity with Python, I have not been able to achieve connectivity with WebRTC. So I have reason to be suspicious about claims regarding web P2P connectivity.

> Reading your stackoverflow link my guess is that you aren't using STUN. A P2P connection can't be established without a NAT hole punch.

I described NAT hole punching in my stackoverflow question, where I asked why isn't WebRTC doing this? I was using a STUN server (edit: I mixed up TURN and STUN servers and edited this post to fix that. My stackoverflow question has clear references to how I was trying to achieve connectivity - it has been a while so not everything is in clear memory for me.)

STUN servers are only required for NAT punching, they don’t relay traffic. Only TURN servers are used as relays in the event that a direction connection can’t be established.

I had a mistake in my post where I confused TURN and STUN. It's been a while since I actually tried to do this stuff. The stackoverflow post has details on how I tried to achieve connectivity, if you check that you will see that yes I used STUN.

Ah that makes sense, thanks for clarifying.

Tailscale has a really excellent explanation of STUN and NAT Traversal:

https://tailscale.com/blog/how-nat-traversal-works/

Also libp2p has documented how it implements NAT hole punching: https://docs.libp2p.io/concepts/nat/hole-punching/

Search "keet.io" and hypercore protocol

I wonder if Tailscale have any numbers on how often clients failover to STUN?

But it doesn't matter since STUN is just used for setting up the connection; it doesn't relay traffic. WebRTC always needs a coordination server to exchange tokens, so STUN doesn't make it less P2P.

Failover to TURN servers then?

Well you usually only need a STUN server that does the NAT hole punching, but transfers no data which can go directly P2P. The problem is that it doesn't work for two people on mobile data where a full TURN is needed. I've never completely understood why exactly it's broken in only that case, but it may have something to do with devices not being directly visible to each other for security reasons.

Or mobile operators being dicks because they can, that's frankly more likely.

> The problem is that it doesn't work for two people on mobile data where a full TURN is needed. I've never completely understood why exactly it's broken in only that case

This is not the only case where it doesn't work. One of the experiments I tried was desktop computer on fixed broadband connecting to another desktop computer on fixed broadband.

Hmm I suppose there may be edge cases where it doesn't work for home networks, but I doubt it's more than a few percent of users. For mobile data it's broken for 100% of devices.

> For mobile data it's broken for 100% of devices.

No, it's not. I've run my own webrtc signaling and STUN servers, and trying between multiple different mobile operators and devices I can establish a connection without TURN in most cases. Not 100% but in most cases.

Reply on news.ycombinator.com