Mosh: non interactive use of mosh (for GIT_SSH)
It would be great tot be able to use mosh as SSH substitute for git. This is particularly useful when working with large repositories. There was a discussion about it on git mailing list and they suggested mosh needs some changes before it can be used.
see http://www.mail-archive.com/[email protected]/msg68545.html for the discussion
pravi
All 5 comments
As a quick summary, it was pointed out on the Git mailing list that the non-interactive mosh <host> <command-line> would need to be supported better: Git relies on mosh <host> "git upload-pack" to open a bidirectional pipe to hand shake and then transfer the necessary objects.
dscho
on 20 Apr 2015
this may be related to #232
anarcat
on 29 Apr 2015
@anarcat I do not think so. #232 is about falling back to the SSH session, while this here ticket is about using the MOSH transport. You see, the difference is that SSH sessions cannot be resumed, once you are disconnected, you are disconnected, and that's it, while MOSH sessions are interruptible, you can continue even after your battery died and you rebooted. The hope was to leverage that interruptible nature of MOSH to support Git clones via flakey connections.
But now that I mentioned the example with the battery, I realize that there is a crucial problem I was missing: when starting a connection that is _meant_ to terminate after all the data was transported, how can we be sure that we were just interrupted because of a flakey network, and not because of a dying laptop? For the latter case, we have to have some way to time out, of course, which would mean that there would also have to be a new negotiation state "timed out, try again". So it seems that this ticket would indeed require quite a bit of work on MOSH.
dscho
on 30 Apr 2015
It's unlikely that this will happen anytime soon. Mosh does not provide the reliable byte streams provided by rsh or ssh, it's really a solution for a different problem. Implementing reliable byte streams good enough for this essentially means implementing TCP inside Mosh.
@dscho's comment hits an important point, which is that Mosh trades away session liveness for session reliability. A Mosh session "lives" forever, but may never make forward progress again if the network or other endpoint no longer exists.
41, #120 are closely related.
cgull
on 30 May 2015
+1 for this idea.
Just now I was trying to replicate a large ZFS filesystem, a task which is proving difficult because ssh always ends up cutting the connection before the initial sync can finish. The other side has a dynamic IP address, so simply changing the timeouts won't help; I need an ssh equivalent that transparently reconnects, even after half an hour.
Thinking about what tool might do that is what brought me here.
Baughn
on 19 Jan 2016
Related issues
earlchew
路
5Comments
franzf
路
5Comments
jscinoz
路
7Comments
andschwa
路
4Comments
jamorales-bsft
路
3Comments
Most helpful comment
@anarcat I do not think so. #232 is about falling back to the SSH session, while this here ticket is about using the MOSH transport. You see, the difference is that SSH sessions cannot be resumed, once you are disconnected, you are disconnected, and that's it, while MOSH sessions are interruptible, you can continue even after your battery died and you rebooted. The hope was to leverage that interruptible nature of MOSH to support Git clones via flakey connections.
But now that I mentioned the example with the battery, I realize that there is a crucial problem I was missing: when starting a connection that is _meant_ to terminate after all the data was transported, how can we be sure that we were just interrupted because of a flakey network, and not because of a dying laptop? For the latter case, we have to have some way to time out, of course, which would mean that there would also have to be a new negotiation state "timed out, try again". So it seems that this ticket would indeed require quite a bit of work on MOSH.