Updated README.

README.md

@@ -3,8 +3,8 @@
 This project is a demo for a websocket-based rollback netcode inspired by [GGPO](https://github.com/pond3r/ggpo/blob/master/doc/README.md). 
 
 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.
-- 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 a [Phone-4G v.s. PC-Wifi (viewed by PC side)](https://pan.baidu.com/s/1IZVa5wVgAdeH6D-xsZYFUw?pwd=dgkj). 
+- 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 (viewed by PC side)](https://pan.baidu.com/s/1IZVa5wVgAdeH6D-xsZYFUw?pwd=dgkj). 
 - Browser vs `native app` is possible but in that case only websocket is used.
 
 The following video is recorded over INTERNET using an input delay of 4 frames and it feels SMOOTH when playing! Please also checkout these demo videos

frontend/assets/scripts/Map.js

@@ -394,6 +394,8 @@ cc.Class({
     self.networkDoctor = new NetworkDoctor(20);
     self.skipRenderFrameFlag = false;
 
+    self.allowRollbackOnPeerUpsync = true;
+
     self.countdownNanos = null;
     if (self.countdownLabel) {
       self.countdownLabel.string = "";
@@ -950,18 +952,8 @@ fromUDP=${fromUDP}`);
       const inputFrame = batch[k]; // could be either "pb.InputFrameDownsync" or "pb.InputFrameUpsync", depending on "fromUDP"
       const inputFrameId = inputFrame.inputFrameId;
       const peerEncodedInput = (true == fromUDP ? inputFrame.encoded : inputFrame.inputList[peerJoinIndex - 1]);
-      if (inputFrameId <= renderedInputFrameIdUpper) {
+      if (false == self.allowRollbackOnPeerUpsync && inputFrameId <= renderedInputFrameIdUpper) {
         // [WARNING] Avoid obfuscating already rendered history, even at "inputFrameId == renderedInputFrameIdUpper", due to the use of "INPUT_SCALE_FRAMES" some previous render frames might already be rendered with "inputFrameId"!   
-        // TODO: Shall we update the "chaserRenderFrameId" if the rendered history was wrong? It doesn't seem to impact eventual correctness if we allow the update of "chaserRenderFrameId" upon "inputFrameId <= renderedInputFrameIdUpper" here, however UDP upsync doesn't reserve order from a same sender and there might be multiple other senders, hence it might result in unnecessarily frequent chasing.
-        const localInputFrame = self.recentInputCache.GetByFrameId(inputFrameId);
-        if (null != localInputFrame
-          &&
-          null == firstPredictedYetIncorrectInputFrameId
-          &&
-          localInputFrame.InputList[peerJoinIndex - 1] != peerEncodedInput
-        ) {
-          firstPredictedYetIncorrectInputFrameId = inputFrameId;
-        }
         continue;
       }
       if (inputFrameId <= self.lastAllConfirmedInputFrameId) {
@@ -986,12 +978,26 @@ fromUDP=${fromUDP}`);
       const newInputFrameDownsyncLocal = gopkgs.NewInputFrameDownsync(inputFrameId, newInputList, newConfirmedList);
       //console.log(`Updated encoded input of peerJoinIndex=${peerJoinIndex} to ${peerEncodedInput} for inputFrameId=${inputFrameId}/renderedInputFrameIdUpper=${renderedInputFrameIdUpper} from ${JSON.stringify(inputFrame)}; newInputFrameDownsyncLocal=${self.gopkgsInputFrameDownsyncStr(newInputFrameDownsyncLocal)}; existingInputFrame=${self.gopkgsInputFrameDownsyncStr(existingInputFrame)}`);
       self.recentInputCache.SetByFrameId(newInputFrameDownsyncLocal, inputFrameId);
+
+      if (self.allowRollbackOnPeerUpsync) {
+        // Reaching here implies that "true == self.allowRollbackOnPeerUpsync".
+        // Shall we update the "chaserRenderFrameId" if the rendered history was wrong? It doesn't seem to impact eventual correctness if we allow the update of "chaserRenderFrameId" upon "inputFrameId <= renderedInputFrameIdUpper" here, however UDP upsync doesn't reserve order from a same sender and there might be multiple other senders, hence it might result in unnecessarily frequent chasing.
+        if (
+          null == firstPredictedYetIncorrectInputFrameId
+          &&
+          existingInputFrame.InputList[peerJoinIndex - 1] != peerEncodedInput
+        ) {
+          firstPredictedYetIncorrectInputFrameId = inputFrameId;
+        }
+      }
     }
     if (0 < effCnt) {
       //self._markConfirmationIfApplicable();
       self.networkDoctor.logPeerInputFrameUpsync(batch[0].inputFrameId, batch[batch.length - 1].inputFrameId);
     }
-    self._handleIncorrectlyRenderedPrediction(firstPredictedYetIncorrectInputFrameId, batch, fromUDP);
+    if (true == self.allowRollbackOnPeerUpsync) {
+      self._handleIncorrectlyRenderedPrediction(firstPredictedYetIncorrectInputFrameId, batch, fromUDP);
+    }
   },
 
   onPlayerAdded(rdf /* pb.RoomDownsyncFrame */ ) {

frontend/build-templates/jsb-link/frameworks/runtime-src/Classes/udp_session.cpp

@@ -6,7 +6,7 @@
 
 int const punchServerCnt = 3;
 int const punchPeerCnt = 3;
-int const broadcastUpsyncCnt = 1;
+int const broadcastUpsyncCnt = 2;
 
 uv_udp_t *udpRecvSocket = NULL, *udpSendSocket = NULL;
 uv_thread_t recvTid, sendTid;