4 ms·

Used moshed a lot when I was travelling in the Philippines and done some devops on US servers. It works great and better than ssh (compressed), even with flakky

Used moshed a lot when I was travelling in the Philippines and done some devops on US servers. It works great and better than ssh (compressed), even with flakky bad connection, high ping to US and 500Kb/s on an island. Tip for getting scrolling back also working: mosh yourserver -- screen Ctrl+a Esc let's you scroll through your screen (with iTerm also with your mouse scroll).

yebyen 10y ago
I would rather have the terminal's native scrolling... is that really impossible with mosh? I know I can use screen but I don't like screen's scrolling behavior.
- geofft 10y ago
  It's "impossible" as defined because the advantage of Mosh is it synchronizes your current screen (the visible, 80x25 or whatever part) as if it were frames in a variable-bandwidth video stream. So, if you're behind a very bad connection and you cat a large file, the scrolling all happens server-side, the intermediate frames get dropped, and only the final frame actually gets sent to the client. Meanwhile, in ssh, if you're behind a very bad connection and you cat a large file, your TCP bandwidth gets throttled down, but it still has to send the entire file over the connection, driving performance way down. There is a fork of mosh (https://github.com/4ast/mosh/commits/master https://github.com/4ast/mosh/commits/master , primarily the "use UserStream instead of Terminal" commit) which disables the frame-sync behavior and just uses the byte-stream-sync code (which is used for keyboard data) to sync the raw bytes / ANSI escape codes back to the client. I haven't tried this, but my guess is that you'd be very sad once you accidentally catted a large file, but if you manage to never do that, you'll get mosh-like behavior but also scrollback. I think you could also change the mosh model to involve maintaining scrollback server-side and syncing it (so you'd render and sync a (80+10000)x25 array, not just the last 80 lines), possibly at lower priority than the non-scrollback portion of the screen. I don't know if anyone's tried implementing this. (Personally I just use screen anyway, so this isn't a major pain point for me)
  - nojvek 10y ago
    I think mosh could be improved with a single trick. Native scrolling for last 10000 lines is super useful. however 99% of time user only looks at say 150x80 chr screen. Mosh syncing that 150x80 screen is a superb idea. Udp is great for mobile hotspot connections. However mosh server should save a buffer of 150x10000 on server side. Only sync 150x80 but If user uses native scroll then it should ask server for last X lines depending on scroll position.
    - geofft 10y ago
      But native scroll is native. There's no way for mosh, a program running inside the terminal, to know when a user is trying to scroll, and fetch data then. If you want non-native scroll, just nest mosh inside screen/tmux. (That may actually be why my theory doesn't work: once a line has scrolled off the screen, there's no way to update it, I think. So even if mosh wanted to do background, low-priority sync of scrollback, it couldn't. The only way to update the scrollback is to write the scrollback before writing the current screen.)
      - yebyen 10y ago
        How many kilobytes are in 10000 lines of text? Less than about a megabyte, right... There could be a happy medium mode or setting that enables scrolling as you described by emulating the keyboard behavior, but mosh would recognize through some buffer capacity if you catted more than about 1MB and skip to printing the last 0.75MB of it. (Makes me want to go on and read that patch you sent to see if I can get it to work like that...) You probably didn't mean to read more than about 1000 lines of text into your terminal so you could mouse cursor select it by hand into your paste-buffer. You answered very informatively, thank you.
        geofft 10y ago
        That's probably doable. I think you don't want to start with the patch I linked, since that disables all terminal sync and all use of the Terminal classes. Instead, try editing Terminal::Framebuffer to have a concept of both normal rows and scrollback rows, and adjust Terminal::Display's new_frame function to sync the scrollback rows in some different way. Note that there's already some code in that function to do scrollback, if the diff between two frames consists of scrolling. (I haven't really contributed to mosh and haven't looked at the codebase in years, so asking on the mailing list or IRC is probably a better place to start)
- joshka 10y ago
  Try tmux perhaps? http://www.davidverhasselt.com/better-mouse-scrolling-in-tmux/ http://www.davidverhasselt.com/better-mouse-scrolling-in-tmu...
  - yebyen 10y ago
    This link might actually be close enough to native scrolling for me, thanks!
- therealmarv 10y ago
  It's impossible by the design of mosh. Mosh transmitts the current state only... it does not care about the past, so you know what currently happens. Imagine your connection is lost for 2 seconds (or many hours/days) and you reconnect... then you will get the current state right back but not everything from the past will be transmitted. So screen or tmux saves you there.
- deleted 10y ago
  [deleted]

yebyen 10y ago

I would rather have the terminal's native scrolling... is that really impossible with mosh? I know I can use screen but I don't like screen's scrolling behavior.

geofft 10y ago
It's "impossible" as defined because the advantage of Mosh is it synchronizes your current screen (the visible, 80x25 or whatever part) as if it were frames in a variable-bandwidth video stream. So, if you're behind a very bad connection and you cat a large file, the scrolling all happens server-side, the intermediate frames get dropped, and only the final frame actually gets sent to the client. Meanwhile, in ssh, if you're behind a very bad connection and you cat a large file, your TCP bandwidth gets throttled down, but it still has to send the entire file over the connection, driving performance way down. There is a fork of mosh (https://github.com/4ast/mosh/commits/master https://github.com/4ast/mosh/commits/master , primarily the "use UserStream instead of Terminal" commit) which disables the frame-sync behavior and just uses the byte-stream-sync code (which is used for keyboard data) to sync the raw bytes / ANSI escape codes back to the client. I haven't tried this, but my guess is that you'd be very sad once you accidentally catted a large file, but if you manage to never do that, you'll get mosh-like behavior but also scrollback. I think you could also change the mosh model to involve maintaining scrollback server-side and syncing it (so you'd render and sync a (80+10000)x25 array, not just the last 80 lines), possibly at lower priority than the non-scrollback portion of the screen. I don't know if anyone's tried implementing this. (Personally I just use screen anyway, so this isn't a major pain point for me)
- nojvek 10y ago
  I think mosh could be improved with a single trick. Native scrolling for last 10000 lines is super useful. however 99% of time user only looks at say 150x80 chr screen. Mosh syncing that 150x80 screen is a superb idea. Udp is great for mobile hotspot connections. However mosh server should save a buffer of 150x10000 on server side. Only sync 150x80 but If user uses native scroll then it should ask server for last X lines depending on scroll position.
  - geofft 10y ago
    But native scroll is native. There's no way for mosh, a program running inside the terminal, to know when a user is trying to scroll, and fetch data then. If you want non-native scroll, just nest mosh inside screen/tmux. (That may actually be why my theory doesn't work: once a line has scrolled off the screen, there's no way to update it, I think. So even if mosh wanted to do background, low-priority sync of scrollback, it couldn't. The only way to update the scrollback is to write the scrollback before writing the current screen.)
    - yebyen 10y ago
      How many kilobytes are in 10000 lines of text? Less than about a megabyte, right... There could be a happy medium mode or setting that enables scrolling as you described by emulating the keyboard behavior, but mosh would recognize through some buffer capacity if you catted more than about 1MB and skip to printing the last 0.75MB of it. (Makes me want to go on and read that patch you sent to see if I can get it to work like that...) You probably didn't mean to read more than about 1000 lines of text into your terminal so you could mouse cursor select it by hand into your paste-buffer. You answered very informatively, thank you.
      - geofft 10y ago
        That's probably doable. I think you don't want to start with the patch I linked, since that disables all terminal sync and all use of the Terminal classes. Instead, try editing Terminal::Framebuffer to have a concept of both normal rows and scrollback rows, and adjust Terminal::Display's new_frame function to sync the scrollback rows in some different way. Note that there's already some code in that function to do scrollback, if the diff between two frames consists of scrolling. (I haven't really contributed to mosh and haven't looked at the codebase in years, so asking on the mailing list or IRC is probably a better place to start)
joshka 10y ago
Try tmux perhaps? http://www.davidverhasselt.com/better-mouse-scrolling-in-tmux/ http://www.davidverhasselt.com/better-mouse-scrolling-in-tmu...
- yebyen 10y ago
  This link might actually be close enough to native scrolling for me, thanks!
therealmarv 10y ago
It's impossible by the design of mosh. Mosh transmitts the current state only... it does not care about the past, so you know what currently happens. Imagine your connection is lost for 2 seconds (or many hours/days) and you reconnect... then you will get the current state right back but not everything from the past will be transmitted. So screen or tmux saves you there.
deleted 10y ago
[deleted]