41 ms·
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-u
by Sean-Der 4y ago
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-used-d67dbfc2ff5d 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-mapping https://webrtcforthecurious.com/docs/03-connecting/#nat-mapp...
[1] https://github.com/pion/stun/tree/master/cmd/stun-nat-behaviour https://github.com/pion/stun/tree/master/cmd/stun-nat-behavi...
- baobabKoodaa 4y ago> 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- 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.)
- Widdershin 4y agoSTUN 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.
- baobabKoodaa 4y agoI 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.
- Widdershin 4y agoAh that makes sense, thanks for clarifying.
- deleted 4y ago[deleted]
- l72 4y agoTailscale has a really excellent explanation of STUN and NAT Traversal: https://tailscale.com/blog/how-nat-traversal-works/ https://tailscale.com/blog/how-nat-traversal-works/
- deleted 4y ago[deleted]
- cle 4y agoAlso libp2p has documented how it implements NAT hole punching: https://docs.libp2p.io/concepts/nat/hole-punching/ https://docs.libp2p.io/concepts/nat/hole-punching/
- deleted 4y ago[deleted]
- turbo_fart 4y agoSearch "keet.io" and hypercore protocol
- combyn8tor 4y agoI wonder if Tailscale have any numbers on how often clients failover to STUN?
- akvadrako 4y agoBut 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.
- combyn8tor 4y agoFailover to TURN servers then?