Hacker News Reader

Comment by Sean-Der | Hacker News Reader

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...

View on HN

> 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?

Reply on news.ycombinator.com