4 ms·

The 3 problems described here (latency, jitter, and packet loss) are the same exact problems that any real-time UDP application will face. The WebRTC spec for v

by j1elo 4y ago

The 3 problems described here (latency, jitter, and packet loss) are the same exact problems that any real-time UDP application will face. The WebRTC spec for video streaming uses and extends the RTP protocol [0] to deal with all those. Presented solutions include jitterbuffers to account for packets that arrive late or out of order; synchronized clocks; stream timelines... all those also exist in any typical WebRTC application, plus others such as packet retransmission requests, or even detecting available bandwidth on each client (to adjust video bitrate accordingly). Of course, RTP is originally meant for video transmisison, but I wonder how much of the typical RTP stack (like that from GStreamer or FFmpeg libraries) might be reusable and useful as a baseline for implementing the online part of a videogame. [0]: https://www.rfc-editor.org/rfc/rfc3550.html https://www.rfc-editor.org/rfc/rfc3550.html

fao_ 4y ago
Further notes here: https://www.reddit.com/r/gamedev/comments/cgvqr5/anyone_use_webrtc_for_a_multiplayer_browser_game/ https://www.reddit.com/r/gamedev/comments/cgvqr5/anyone_use_... https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-great-multiplayer/ https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-g... http://blog.brkho.com/2017/03/15/dive-into-client-server-web-games-webrtc/ http://blog.brkho.com/2017/03/15/dive-into-client-server-web...
- j1elo 4y ago
  Note that while still quite complex and difficult to grasp for newcomers, WebRTC is now much more stable and well implemented by web browsers. However bugs and interoperability issues have been rampant still in latest years, so I don't want to think about how the scene was in 2013... Regardless, in my above comment I was thinking of a lower level. Not WebRTC per-se, but the plain RTP protocol. Every RTP (UDP) packet has NTP timestamps included in the header. RTP endpoints (both client and server) have a well defined set of calculations user to synchronize packets based on their timestamps, and also infer network latency, jitter, even clock skew, that kind of things. RTP packet headers also have a sequence number. This is used to detect out of order, or missing packets. Then the packets can be reordered, or (if it makes sense) a retransmission request be sent back to the sender. I.e. a lot of the problems that were being described in the original article, seem to be already handled by RTP. So I was thinking of how realistic it would be to use multiplayer game data, instead of video frames as the RTP payload, to leverage all these network-related mechanisms of the protocol.

by j1elo 4y ago

fao_ 4y ago

Further notes here: https://www.reddit.com/r/gamedev/comments/cgvqr5/anyone_use_webrtc_for_a_multiplayer_browser_game/ https://www.reddit.com/r/gamedev/comments/cgvqr5/anyone_use_... https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-great-multiplayer/ https://hacks.mozilla.org/2013/03/webrtc-data-channels-for-g... http://blog.brkho.com/2017/03/15/dive-into-client-server-web-games-webrtc/ http://blog.brkho.com/2017/03/15/dive-into-client-server-web...

j1elo 4y ago
Note that while still quite complex and difficult to grasp for newcomers, WebRTC is now much more stable and well implemented by web browsers. However bugs and interoperability issues have been rampant still in latest years, so I don't want to think about how the scene was in 2013... Regardless, in my above comment I was thinking of a lower level. Not WebRTC per-se, but the plain RTP protocol. Every RTP (UDP) packet has NTP timestamps included in the header. RTP endpoints (both client and server) have a well defined set of calculations user to synchronize packets based on their timestamps, and also infer network latency, jitter, even clock skew, that kind of things. RTP packet headers also have a sequence number. This is used to detect out of order, or missing packets. Then the packets can be reordered, or (if it makes sense) a retransmission request be sent back to the sender. I.e. a lot of the problems that were being described in the original article, seem to be already handled by RTP. So I was thinking of how realistic it would be to use multiplayer game data, instead of video frames as the RTP payload, to leverage all these network-related mechanisms of the protocol.