Prediction requires ordered epochal designation of prediction writes and upstream reads
Mosh (roughly) works by transmitting remote framebuffer state from the server to the client, and the client consumes a that state atomically once it is fully received. The client is free to make conditional predictions on top of its last complete view of the remote state, and can (in a principled way) reconcile the "old" state, the "new" state, and any conditional predictions when consuming a newly completely received new state.
The current prediction-experiments
branch implementation is ad-hoc without considering these ordering requirements, where any upstream read increments the prediction epoch. This results in pretty severe terminal state glitches when upstream reads are received (and the epoch incremented) without those reads reflecting writes that occurred in the supposed epoch.
Since Nosshtradamus does not (and cannot) include an equivalent to the mosh-server
component in the target host, the alignment of upstream reads into epochs that do reflect particular writes must be achieved through a different mechanism. The SSH protocol supports channel level requests that can expect a reply from the server. Since both in-band traffic and these requests are carried over the same transport (i.e. with same delay characteristics), replies to requests co-generated with in-band writes should allow controlling the epoch advancement respecting the ordering requirements.
Two main questions:
- What is the typical behavior of SSH servers (e.g. OpenSSH, compared/contrasted to my Chroniton SSH server) with respect to unknown channel requests that request a reply? Is it typical to generate an error reply to unknown requests?
- What requirements does Mosh have with regards to adjacency/proximity of prediction epochs versus last fully received server epoch? Restated, can the reconciliation process accept presence of multiple unacknowledged client prediction epochs relative to what was just received from the server (i.e. can it reconcile predictions for epochs N, N+1, N+2... for received server epoch N)?
If the answers are (1) at least an error is generated for unknown messages and (2) reconciliation can handle multiple unacknowledged client prediction epochs, this becomes quite easy to solve.