From c2fa251e69fb3ccd6cc91942ae8f50bd7a69d52c Mon Sep 17 00:00:00 2001 From: yflu Date: Sun, 12 Feb 2023 12:10:20 +0800 Subject: [PATCH] Updated documentation. --- ConcerningEdgeCases.md | 16 +++++++++++++++- README.md | 2 +- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/ConcerningEdgeCases.md b/ConcerningEdgeCases.md index 90c5f40..229a0e2 100644 --- a/ConcerningEdgeCases.md +++ b/ConcerningEdgeCases.md @@ -75,4 +75,18 @@ Instead of replacing all use of TCP by UDP, it's more reasonable to keep using T It's not a global consensus, but in practice many UDP communications are platform specific due to their paired asynchronous I/O choices, e.g. epoll in Linux and kqueue in BSD-ish. Of course there're many 3rd party higher level encapsulated tools for cross-platform use but that introduces extra debugging when things go wrong. Therefore, the following plan doesn't assume use of any specific 3rd party encapsulation of UDP communication. -![UDP_secondary_session](./charts/UDPEssentials.jpg) \ No newline at end of file +![UDP_secondary_session](./charts/UDPEssentials.jpg) + +# Would using WebRTC for all frontends be a `UDP for all` solution? +Theoretically yes. + +## Plan to integrate WebRTC +The actual integration of WebRTC to enable `browser v.s. native app w/ WebRTC` requires detailed planning :) + +In my current implementation, there's only 1 backend process and it's responsible for all of the following things. The plan for integrating/migrating each item is written respectively. +- TURN for UDP tunneling/relay + - Some minor modification to [Room.PlayerSecondaryDownsyncSessionDict](https://github.com/genxium/DelayNoMore/blob/365177a3af6033f1cd629a4a4d59beb4557cc311/battle_srv/models/room.go#L126) should be enough to yield a WebRTC API friendly TURN. It's interesting that [though UDP based in transport layer, a WebRTC session is stateful and more similar to WebSocket in terms of API](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API). +- STUN for UDP holepunching + - Some minor modification to [Player.UdpAddr](https://github.com/genxium/DelayNoMore/blob/365177a3af6033f1cd629a4a4d59beb4557cc311/battle_srv/models/player.go#L56) should be enough to yield a WebRTC API friendly STUN. +- reconnection recovery + - Not sure whether or not I should separate this feature from STUN and TURN, but if I were to do so, [both `Room.RenderFrameBuffer` and `Room.InputsBuffer`](https://github.com/genxium/DelayNoMore/blob/365177a3af6033f1cd629a4a4d59beb4557cc311/battle_srv/models/room.go) should be moved to a shared fast I/O storage (e.g. using Redis) to achieve the same level of `High Availability` in design as STUN and TURN. diff --git a/README.md b/README.md index 69dbcf3..fd9954a 100644 --- a/README.md +++ b/README.md @@ -13,7 +13,7 @@ This project is a demo for a websocket-based rollback netcode inspired by [GGPO] As lots of feedbacks ask for a discussion on using UDP instead, I tried to summarize my personal opinion about it in [ConcerningEdgeCases](./ConcerningEdgeCases.md) -- **since v0.9.25, the project is actually equipped with UDP capabilities as follows**. - When using the so called `native apps` on `Android` and `Windows` (I'm working casually hard to support `iOS` next), the frontends will try to use UDP hole-punching w/ the help of backend as a registry. If UDP hole-punching is working, the rollback is often less than `turn-around frames to recover` and thus not noticeable, being much better than using websocket alone. This video shows how the UDP holepunched p2p performs for [Phone-Wifi v.s. PC-Wifi (viewed by PC side)](https://pan.baidu.com/s/1K6704bJKlrSBTVqGcXhajA?pwd=l7ok). - If UDP hole-punching is not working, e.g. for Symmetric NAT like in 4G/5G cellular network, the frontends will use backend as a UDP tunnel (or relay, whatever you like to call it). This video shows how the UDP tunnel performs for [Phone-4G v.s. PC-Wifi (merged view@v0.9.34, excellent synchronization)](https://pan.baidu.com/s/1yeIrN5TSf6_av_8-N3vdVg?pwd=7tzw). -- Browser vs `native app` is possible but in that case only websocket is used. +- Browser vs `native app` is possible but in that case only websocket is used. For WebRTC integration plan please see [ConcerningEdgeCases](./ConcerningEdgeCases.md). You might also be interested in visiting [netplayjs](https://github.com/rameshvarun/netplayjs) to see how others use WebRTC for browser game synchronization as well. # Notable Features