5 ms·

My understanding was that WebRTC wasn't specifically designed for video and voice applications exclusively, but rather as a generic real time, peer to peer comm

My understanding was that WebRTC wasn't specifically designed for video and voice applications exclusively, but rather as a generic real time, peer to peer communication framework that included capabilities for voice and video. Not trying to take away from your comment or anything, but maybe I misunderstand WebRTC.

monocasa 6y ago
Yeah. It's specifically designed for both AV, and for generic datagrams. You have to choose one or the other during initialization of a stream (but can have multiple streams between clients).
lewispollard 6y ago
I recently implemented a WebRTC multiplayer game in Godot, and yeah, it has very little to do with chat, and isn't really "off the shelf", it took a hell of a lot of configuration, plus running and maintaining a STUN/TURN server and backend lobby/matchmaking system. It's no more a chat protocol than HTTP really when you're doing that kind of programming with it, just has some nifty tricks for getting around routers and making a direct connection where it can. That said, it was better than NAT punch-through and/or UPNP which are not very reliable these days.
- 0df8dkdf 6y ago
  Correct me if I'm wrong. STUN/TURN is the one that is doing the UDP punching. And in the event that fails, all the data are being passed through the STUN/TURN server, which makes it just like client/server setup where the server became the bottle neck again.
  - ensiferum 6y ago
    Stun is a protocol to query the network about the topology. Turn is a protocol to route through a third party when p2p fails. Both of these are part of the ICE methodologies.
  - Orphis 6y ago
    STUN is basically a way to know your external IP address to share to others and have both peers try to connect to one another through them. It's lightweight. If that fails, then there's TURN which acts like a proxy between the peers.
aroman 6y ago
tl;dr using WebRTC just for realtime client<->server data sucks, but WebTransport[1] is coming soon to serve that exact usecase with an easy API WebRTC has data channels, which are currently the only way to achieve unreliable and unordered real-time communication (UDP-style) between the browser and other browsers or a server. This is pretty essential for any networked application where latency is critical, like voice and video and fast-paced multiplayer games. As other commenters have noted, it's a royal pain in the ass to set up WebRTC if all you want is UDP-style communication between a server and browser, since you need to wrangle half a dozen other protocols in the process. However! A new API, WebTransport[1], is actively being developed that will offer a WebSockets-like (read: super simple to set up) API for UDP-style communication. I am extremely excited about it and its potential for real-time browser-based multiplayer games (which I'm working on). https://github.com/w3c/webtransport https://github.com/w3c/webtransport
- Sean-Der 6y ago
  What do you find hard about setting up a WebRTC server? I hear from users they are able to spin up a Pion DataChannel server in 5 mins (including installing Go) WebTransport isn’t going to be here soon though, I would be cautious in investing. Stuff like Congestion Control is still a big unknown [0] and we don’t have Datagrams everywhere. [0] https://github.com/w3c/webtransport/issues/168 https://github.com/w3c/webtransport/issues/168 [1] https://github.com/quicwg/datagram https://github.com/quicwg/datagram
  - aroman 6y ago
    https://github.com/pion/datachannel https://github.com/pion/datachannel looks great! Thank you for sharing your project with the open source community. I just starred it, it does seem like it'd alleviate a some of the pain. Another similar (more end to end) project I had come across is: geckos.io. This previous HN thread[1] discusses some of the (at least perceived) difficulty with using WebRTC as a "WebSockets but UDP" solution. I'm not sure I follow the concern about congestion control. UDP doesn't have it either, presumably since if you're building an application that requires such latency sensitivity, you don't mind rolling your own congestion control algorithm that makes most sense given your application's specific needs, right? Pretty much all FPS games do this, as far as I understand. [0] https://github.com/geckosio/geckos.io https://github.com/geckosio/geckos.io [1] https://news.ycombinator.com/item?id=23666679 https://news.ycombinator.com/item?id=23666679

monocasa 6y ago

Yeah. It's specifically designed for both AV, and for generic datagrams. You have to choose one or the other during initialization of a stream (but can have multiple streams between clients).

lewispollard 6y ago

I recently implemented a WebRTC multiplayer game in Godot, and yeah, it has very little to do with chat, and isn't really "off the shelf", it took a hell of a lot of configuration, plus running and maintaining a STUN/TURN server and backend lobby/matchmaking system. It's no more a chat protocol than HTTP really when you're doing that kind of programming with it, just has some nifty tricks for getting around routers and making a direct connection where it can. That said, it was better than NAT punch-through and/or UPNP which are not very reliable these days.

0df8dkdf 6y ago
Correct me if I'm wrong. STUN/TURN is the one that is doing the UDP punching. And in the event that fails, all the data are being passed through the STUN/TURN server, which makes it just like client/server setup where the server became the bottle neck again.
- ensiferum 6y ago
  Stun is a protocol to query the network about the topology. Turn is a protocol to route through a third party when p2p fails. Both of these are part of the ICE methodologies.
- Orphis 6y ago
  STUN is basically a way to know your external IP address to share to others and have both peers try to connect to one another through them. It's lightweight. If that fails, then there's TURN which acts like a proxy between the peers.

aroman 6y ago

tl;dr using WebRTC just for realtime client<->server data sucks, but WebTransport[1] is coming soon to serve that exact usecase with an easy API WebRTC has data channels, which are currently the only way to achieve unreliable and unordered real-time communication (UDP-style) between the browser and other browsers or a server. This is pretty essential for any networked application where latency is critical, like voice and video and fast-paced multiplayer games. As other commenters have noted, it's a royal pain in the ass to set up WebRTC if all you want is UDP-style communication between a server and browser, since you need to wrangle half a dozen other protocols in the process. However! A new API, WebTransport[1], is actively being developed that will offer a WebSockets-like (read: super simple to set up) API for UDP-style communication. I am extremely excited about it and its potential for real-time browser-based multiplayer games (which I'm working on). https://github.com/w3c/webtransport https://github.com/w3c/webtransport

Sean-Der 6y ago
What do you find hard about setting up a WebRTC server? I hear from users they are able to spin up a Pion DataChannel server in 5 mins (including installing Go) WebTransport isn’t going to be here soon though, I would be cautious in investing. Stuff like Congestion Control is still a big unknown [0] and we don’t have Datagrams everywhere. [0] https://github.com/w3c/webtransport/issues/168 https://github.com/w3c/webtransport/issues/168 [1] https://github.com/quicwg/datagram https://github.com/quicwg/datagram
- aroman 6y ago
  https://github.com/pion/datachannel https://github.com/pion/datachannel looks great! Thank you for sharing your project with the open source community. I just starred it, it does seem like it'd alleviate a some of the pain. Another similar (more end to end) project I had come across is: geckos.io. This previous HN thread[1] discusses some of the (at least perceived) difficulty with using WebRTC as a "WebSockets but UDP" solution. I'm not sure I follow the concern about congestion control. UDP doesn't have it either, presumably since if you're building an application that requires such latency sensitivity, you don't mind rolling your own congestion control algorithm that makes most sense given your application's specific needs, right? Pretty much all FPS games do this, as far as I understand. [0] https://github.com/geckosio/geckos.io https://github.com/geckosio/geckos.io [1] https://news.ycombinator.com/item?id=23666679 https://news.ycombinator.com/item?id=23666679