Mosh is a truly impressive feat of thought and, perhaps more
importantly, engineering. The thinking behind Mosh is substantial, the
paradigms are fresh. Reading about mosh on its excellent website,
I always leave with a profound feeling of enthusiasm. Mosh belongs a
school of software development ethics that I'm sorely missing in the
world.
However, I do concur that, perhaps, Mosh solves a deep problem on the
wrong level or, even, in the wrong domain. The feeling, already
expressed here, that "tmux oughta do it" never leaves me. Why is that?
Because I know that ssh, by itsself, can handle connection loss quite
well[0]. Rather, I suspect, ssh can't deal with IP changes or the
destruction of the underlying interface.
So, here's the rub: Why is a stable, somehow-abstract, network interface
with a local IP, sitting on top of the actual network interfaces, be
they wired or wireless, not the answer? Over the years, on and off,
I tried to get the Linux ethernet bonding stack (ifenslave) to provide
me with just that solution, but was never able to.
Hence, I keep revisiting mosh, then revisiting ifenslave...
[0] On a machine that doesn't dynamically switch network interfaces on
demand, just unplug an ethernet cable, wait a while and plug it back
in: your ssh session will resume.
You missed the point of Mosh. SSH transfers a bidirectional stream of bytes between server and client. It uses TCP as transport. You can combine SSH with tmux to preserve your sessions as tmux sessions. If you use SSH to access your tmux session you fixed a part of the problem. Your client can now roam by reattaching the tmux session from a new SSH connection.
The other half of the problem remains: SSH transfers unmodified byte streams between client and server over TCP. On networks with high latency or high packet loss this design doesn't work. Mosh fixes this part of the problem by redefining the problem. Instead of transferring every byte in both directions it runs a terminal emulator on both sides and the problem turn into: keep the terminal emulator states in sync. The server sends patches from the last confirmed client state to the current server state to the last known client address:port pair via UDP. The client sends the user input (and pings) to the server via UDP. This design allows Mosh to skip over lost messages.
Mosh implements a delta algorithm between the server's buffer and the client's buffer. This means if packet loss is occurring, to sync back up, the server only needs to send the delta of its state to the client.
SSH, on the other hand, is stream-oriented, and will replay everything that has occurred, even if the resulting changes to the display in the end are minimal.
It's similar to how something like VNC functions compared to the X11 protocol. The VNC protocol is more efficient and tolerant of lossy or low-latency connections.
Mobile IP etc. solve the problem of changing IP addresses, but they don't address the flakiness of mobile connections (esp. when actually mobile). TCP takes some time to come back; having a faster mechanisms is much appreciated when your link loses a few packets twice every minute.
However, I do concur that, perhaps, Mosh solves a deep problem on the wrong level or, even, in the wrong domain. The feeling, already expressed here, that "tmux oughta do it" never leaves me. Why is that?
Because I know that ssh, by itsself, can handle connection loss quite well[0]. Rather, I suspect, ssh can't deal with IP changes or the destruction of the underlying interface.
So, here's the rub: Why is a stable, somehow-abstract, network interface with a local IP, sitting on top of the actual network interfaces, be they wired or wireless, not the answer? Over the years, on and off, I tried to get the Linux ethernet bonding stack (ifenslave) to provide me with just that solution, but was never able to.
Hence, I keep revisiting mosh, then revisiting ifenslave...
[0] On a machine that doesn't dynamically switch network interfaces on demand, just unplug an ethernet cable, wait a while and plug it back in: your ssh session will resume.