3 ms·

Hah, this is so true. Am building a little hobby project to try out WebRTC for game development. On my ISP provided router a Mac and Windows computer can’t see

Hah, this is so true. Am building a little hobby project to try out WebRTC for game development. On my ISP provided router a Mac and Windows computer can’t see each other over WiFi due to some mDNS issue likely the router support for multicast. Using Chrome flags to turn off mDNS and they can connect fine but obviously expose internal IPs. Wire one of the machines and mDNS works. TURN is essentially a necessity but then why not use a server (particularly for a chat app).

SahAssar 6y ago
Sounds like you mean STUN, not TURN.
- meheleventyone 6y ago
  No, I’m using a STUN server. This issue is unrelated and due to the local IPs being masked by mDNS addresses so that local network topology isn’t leaked to the world at large and my routers handling of mDNS. Which is why everything works over the local network if I disable mDNS use in Chrome. TURN is the ultimate fallback to being unable to NAT punch. Ironically getting machines connected across the internet with WebRTC has so far been relatively smooth sailing.
  - mypalmike 6y ago
    TURN should never be necessary if one of your endpoints has a public IP address.
mypalmike 6y ago
If your topology is essentially client server, you don't need a TURN or even a STUN server for webrtc connectivity. The client can send dummy candidate IPs in the offer, but receives valid server IPs in the answer. The client starts initiating transport to the server and reaches it. Peer reflexive candidate processing by the server allows it to communicate back to the client even if transport is UDP. It's definitely more complex than websockets, but removing STUN servers from the equation does simplify connection initiation a bit.
- meheleventyone 6y ago
  I'm aiming for peer to peer. :)
  - mypalmike 6y ago
    Interesting! There aren't a lot of peer to peer multiplayer game architectures nowadays. Good luck!
    - meheleventyone 6y ago
      Thanks, it's actually more common than you'd think particularly in certain genres. For big examples with a large player bases you have GTA Online and the Destiny games. Fighting games also tend to run peer to peer both because there is (usually) only two people in a fight and because they are quite latency sensitive. My own interest comes from many years of building multiplayer games professionally and wanting to make smaller scale multiplayer games for fun without needing to invest too much in infrastructure.
littlestymaar 6y ago
If you're using the DataChannel only (which is common when using WebRTC for games) you don't need a TURN (that adds complexity and you don't need it useless you're dealing with media streams) instead all you need is to re-use your signaling server as a fallback to get your messages from two peer who cannot establish a connection to one another.
- meheleventyone 6y ago
  That's merely equivalent though. Ultimately TURN is just a common specification for a relay. You also run head first into latency issues where you can run one signaling server globally but need regional relays to keep latency down. Could you expand a bit on why MediaChannels need TURN specifically? Is there some complication that prevents just dumb relaying of the packets ala what you're suggesting?

SahAssar 6y ago

Sounds like you mean STUN, not TURN.

meheleventyone 6y ago
No, I’m using a STUN server. This issue is unrelated and due to the local IPs being masked by mDNS addresses so that local network topology isn’t leaked to the world at large and my routers handling of mDNS. Which is why everything works over the local network if I disable mDNS use in Chrome. TURN is the ultimate fallback to being unable to NAT punch. Ironically getting machines connected across the internet with WebRTC has so far been relatively smooth sailing.
- mypalmike 6y ago
  TURN should never be necessary if one of your endpoints has a public IP address.

mypalmike 6y ago

If your topology is essentially client server, you don't need a TURN or even a STUN server for webrtc connectivity. The client can send dummy candidate IPs in the offer, but receives valid server IPs in the answer. The client starts initiating transport to the server and reaches it. Peer reflexive candidate processing by the server allows it to communicate back to the client even if transport is UDP. It's definitely more complex than websockets, but removing STUN servers from the equation does simplify connection initiation a bit.

meheleventyone 6y ago
I'm aiming for peer to peer. :)
- mypalmike 6y ago
  Interesting! There aren't a lot of peer to peer multiplayer game architectures nowadays. Good luck!
  - meheleventyone 6y ago
    Thanks, it's actually more common than you'd think particularly in certain genres. For big examples with a large player bases you have GTA Online and the Destiny games. Fighting games also tend to run peer to peer both because there is (usually) only two people in a fight and because they are quite latency sensitive. My own interest comes from many years of building multiplayer games professionally and wanting to make smaller scale multiplayer games for fun without needing to invest too much in infrastructure.

littlestymaar 6y ago

If you're using the DataChannel only (which is common when using WebRTC for games) you don't need a TURN (that adds complexity and you don't need it useless you're dealing with media streams) instead all you need is to re-use your signaling server as a fallback to get your messages from two peer who cannot establish a connection to one another.

meheleventyone 6y ago
That's merely equivalent though. Ultimately TURN is just a common specification for a relay. You also run head first into latency issues where you can run one signaling server globally but need regional relays to keep latency down. Could you expand a bit on why MediaChannels need TURN specifically? Is there some complication that prevents just dumb relaying of the packets ala what you're suggesting?