3 ms·

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 vas

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-connect-p2p-even-though-peers-can-send-udp-packets-to-each-other https://stackoverflow.com/questions/70624649/webrtc-fails-to...

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 ago
    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.
    - baobabKoodaa 4y ago
      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.
      - Widdershin 4y ago
        Ah that makes sense, thanks for clarifying.
  - deleted 4y ago
    [deleted]
  - l72 4y ago
    Tailscale 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 ago
      Also 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 ago
- combyn8tor 4y ago
  I wonder if Tailscale have any numbers on how often clients failover to STUN?
  - akvadrako 4y ago
    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.
    - combyn8tor 4y ago
      Failover to TURN servers then?
moffkalast 4y ago
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.
- baobabKoodaa 4y ago
  > 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.
  - moffkalast 4y ago
    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.
    - SahAssar 4y ago
      > 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.

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 ago
  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.
  - baobabKoodaa 4y ago
    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.
    - Widdershin 4y ago
      Ah that makes sense, thanks for clarifying.
- deleted 4y ago
  [deleted]
- l72 4y ago
  Tailscale 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 ago
    Also 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 ago
combyn8tor 4y ago
I wonder if Tailscale have any numbers on how often clients failover to STUN?
- akvadrako 4y ago
  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.
  - combyn8tor 4y ago
    Failover to TURN servers then?

moffkalast 4y ago

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.

baobabKoodaa 4y ago
> 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.
- moffkalast 4y ago
  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.
  - SahAssar 4y ago
    > 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.