Without early saves we couldn't properly detect savestateless cores. We
still can't, really, but we can at least EVENTUALLY detect this
condition. netplay_net has been fixed to do so.
A couple fixes are still necessary for the client, in particular to
recover a "lost" hostname, but now it is possible to start server or
client mid-stream, and to disconnect intentionally.
Some cores can only determine the true size of sram after fully loading
the content, and so will report different values when the sram size is
queried. As a result, netplay cannot count on sram size as a reliable
verification technique. sram is still sent for the savestateless core
case.
This fixes a bug whereby reconnections would be out of sync due to the
flip state of the server and client being different. The server now
resets its flip state on disconnect.
This changes netplay host mode's behavior in net (normal) mode from
immediately blocking to waiting for a connection while allowing the game
to run, like spectator mode.
Spectate mode is now far more similar to net (normal) mode, and, more
importantly, it works. In addition, spectate mode will not fast-forward
to catch up with the server if it lags too far behind.
The receiving side of a player-flip request now does a forced rewind to
assure that any already-computed frames are computed with the players on
the right side.
Every frame (soon to be configurable), the server does a CRC-32 hash and
sends it to the client. If the client finds that its own hash is
different from the server's, it requests a fresh savestate.
This is a last-ditch effort to sync if all else fails, and it's a
best-effort situation. The size of the buffer should assure that we
always still have the frame around to CRC, but I imagine there are edge
cases where we don't. If you're in an edge case, the CRC is ignored.
Assuming the core supports saving/loading states, and (crucially)
assuming the states are portable across the architectures on both sides
of the connection, Netplay now supports the transmission of savestates.
Right now the frontend doesn't actually send any such requests, as it's
not clear exactly where the code for that should be.
This works in either direction, although I'll admit I have no idea what
happens if they both load at the same time.
