Home

This is a fork of RetroArch intended to fix and improve its Netplay. See also my info on which cores are tested.

Done and merged upstream

• Removed the "here there be dragons" sign that prevented anyone else from looking at this code.
• Added a README that lightly documents how RetroArch's Netplay works.
• Netplay ring buffer hardened to prevent overruns, which previously caused insane desyncs.
• Ripped out UDP. Everything is done over TCP now. The previous implementation demanded reliability and in-order guarantees anyway, so UDP was just silly. Note that the protocol has also changed in more fundamental ways, so it's not really possible to make a "UDP or TCP" option except by having two incompatible implementations of Netplay.
• Removed all limits on the size of the replay buffer. You want to allow 10 seconds of drift? 10 seconds of drift it is!
• Made stalling work without blocking the UI thread.
• General bugfixes to make Netplay bulletproof.
• Remote pausing.
• Stalling without rerunning frames. Netplay is now one of the many reasons the frontend may pause.
• Support for loading state over Netplay.
• Frame CRCing as a last resort for sync. Configurable by netplay_check_frames or the --check-frames option.
• Deterministic player flipping.
• Fixed spectator mode. In addition, it's now far more similar to net (normal) mode than it was before.
• Netplay menu and support for launching Netplay on an existing session.
• Savestate "quirks" API. Allows cores to describe the quirkiness of their serialization code so that frontend features can adapt. Particularly useful since many cores have session-specific savestates that cannot be transferred over the network.
• Update all quirky cores to identify their quirkiness.
• Compression of savestates when sent over the network.

Todo

• Infinite testing, of course!
• Future: Auto-expanding replay buffer based on latency. Problems relate to limits, when to contract, how to determine if we don't have enough CPU time to handle it, etc.
• Future: >2 player netplay. Not as difficult as it seems, just need an array of buffers, frames and replay.
• Super-future: Netplay input support for devices other than the simple retropad.
• Maybe: Rewindless mode. This is strictly-wrong Netplay, but with frame CRCing, can work fine. If one disabled both rewinds and frame CRCing, one would be left with ZSNES-style netplay (no attempt at sync)
• Maybe: Support for input grappling (two players controlling the same input device). Useful for e.g. handhelds.
• Probably not: UDP as redundancy for TCP: Still send input over TCP, but send it over UDP as well, and use the UDP data whenever possible. That gets the speed of UDP with the reliability of TCP. Please see the UDP note below.

UDP

I really, really don't want to reintroduce UDP. The problem is thus: Certain events, such as player flipping and savestate loading, cause synchronization points, and those synchronization points absolutely must be received in order.

Now, that doesn't make UDP impossible. One could send synchronization events over TCP and input events over UDP. However, that adds a complication:

Right now, Netplay is basically implemented as a ring buffer of frame states. That ring buffer has one read head, one write head and one read/write head: Other, read and self, respectively. 'Read' points to the next frame into which data will be read from the remote peer. Right now, since that data is always in order, we can know with certainty that all synchronization events before 'read' have been actioned, and so it's safe to overwrite 'read' in the ring buffer.

If synchronization events were not in order with respect to input events, this would need to change, and a fourth head, 'readahead', would need to be added. 'Read' would now be "read and no synchronization events may arrive for this point", while 'readahead' is allowed to, well, read ahead.

The relationship between other, self and read in the current implementation must be carefully maintained: Other ≤ self, other ≤ read, and both read and self may block if they would otherwise be required to overwrite 'other' due to the circular nature of the ring buffer.

The relationship becomes remarkably more complicated with four heads. Other ≤ self, other ≤ readahead, read ≤ readahead, and self, read and readahead must all make sure neither to overstep other nor to oversteap read, since read may now lag behind other.

That's all doable. There's nothing preventing it from being done. However, a big problem with the maintenance of the Netplay code up until this point is that nobody understood how it worked. I've simplified and documented the assumptions, but it's still nontrivial. Making it even more complicated is not worth the disputable performance benefit of UDP.