Thread (15 messages) flat view 15 messages, 8 authors, 2016-06-15

Re: support git+mosh for unreliable connections

From: Pirate Praveen <hidden>
Date: 2016-06-15 23:04:29

On Thursday 16 April 2015 01:56 AM, Ilari Liusvaara wrote:
On Wed, Apr 15, 2015 at 08:13:51PM +0530, Pirate Praveen wrote:
quoted
Q: Are the mosh principles relevant to other network applications?

    We think so. The design principles that Mosh stands for are
conservative: warning the user if the state being displayed is out of
date, serializing and checkpointing all transactions so that if there
are no warnings, the user knows every prior transaction has succeeded,
and handling expected events (like roaming from one WiFi network to
another) gracefully.

Can the ideas be used to resume a pull, push or clone operation?
Especially serializing and checkpointing.
Well, it is possible to write a remote helper and serverside program
that internally handles connection unreliability, so Git itself
(upload-archive, upload-pack, receive-pack, archive, fetch-pack
and send-pack) sees a reliable (full-duplex, half-closeable, stream)
channel.

Suitably done, that can "resume" (from Git POV, nothing special
happened) across things like IP address changes.

However, that is quite difficult to do in practice. Not because
interface to Git is complicated, but because the transport problem
itself is complicated (however, it still seems way easier than
making Git internally be able to resume interrupted operations).

Mosh needs to solve at least most of that, it just doesn't provode
the right kind of interface.
I have requested mosh team to fix these issues
https://github.com/keithw/mosh/issues/597

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help