3 ms·

Mosh is a truly impressive feat of thought and, perhaps more importantly, engineering. The thinking behind Mosh is substantial, the paradigms are fresh. Read

by hf 12y ago

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.

apk17 12y ago
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.
pferde 12y ago
I believe http://multipath-tcp.org/ http://multipath-tcp.org/ is the answer.
bascule 12y ago
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.
crest 12y ago
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.

by hf 12y ago

apk17 12y ago

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.

pferde 12y ago

I believe http://multipath-tcp.org/ http://multipath-tcp.org/ is the answer.

bascule 12y ago

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.

crest 12y ago

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.