<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 27, 2013 at 2:08 PM, Keith Winstein <span dir="ltr"><<a href="mailto:keithw@mit.edu" target="_blank">keithw@mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi George,<div><br></div><div>Thanks for getting in touch. Definitely open to this in principle. Here's a few questions:</div>
<div><br></div><div>(1) Is there a way for mosh-client to tell if the host terminal supports these device control strings? (E.g. a capability in terminfo? An environment variable you set?) Alternately, have you tested / are you pretty sure that nothing bad will happen if we pass these along to the popular terminal emulators that aren't iTerm2 (e.g., iTerm1, Terminal.app, xterm, VTE, Konsole, urxvt, PuTTY, screen, tmux)?</div>
<div><br></div></blockquote><div><br></div><div>Hi Keith,</div><div><br></div><div>No, there's nothing set to indicate support. Although iTerm2 does set "TERM_PROGRAM=iTerm.app", that's not a great choice because other terminal emulators may start supporting this protocol as well. I'm open to ideas along these lines.</div>
<div><br></div><div>The worst offenders are tmux and screen, which hang until they gets an ESC \. Terminal and iTerm 0.x just print P100p to the screen. I'm still checking on vt1, konsole, urxvt, and putty.</div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div></div><div>(2) Mosh works by representing the state of the terminal at the server and at the client, and synchronizing the states by sending "diffs" between the state the server thinks the client has and the state the server wants it to have. We like for the "diffs" between any pair of states (e.g. state #4 and state #3,927) to be bounded in size, so that we can quickly resynchronize the client's terminal if it comes back to the network after a long time away.</div>
<div><br></div><div>Right now I don't think there's anything an application can do to make the diff grow without bound -- we only store a certain number of combining characters per cell on the screen, we compress repeated "rendition" changes down to the minimum diff necessary, etc. (E.g. if the application turns on and off "bold" on a character 50,000 times, we compress that down into just one flip if necessary.)</div>
<div><br></div><div>So my preference would be not to pass these device control strings through literally, because then we'd have to queue them up and have some sort of flow control to make sure we don't end up with 90 megabytes of pending updates from a misbehaving app. (Timo Rinne has done a huge amount of work to support ssh-agent forwarding, which presents the same issues for us, and before we make a protocol change to support flow-controlled octet sequences, I want to make sure it's at the right layer.)</div>
<div><br></div><div>If it's possible for us to parse these updates and represent "the state" that the client is supposed to have as part of our Terminal::Framebuffer object (like everything else), that would be way better. Is the protocol documented somewhere? Is somebody from iTerm2 willing to do this and submit a pull request along these lines?</div>
<div> <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div></div><div>By contrast, if you really do need just a reliable flow-controlled octet-stream, I think you'll have to wait until we decide where in the protocol stack we want that to go and we commit to a protocol change we're willing to live with going forward.</div>
<div><br></div></blockquote><div><br></div><div>The protocol is documented in tmux's man page under the "Control mode" section. In terms of parsing the protocol, it would be an amazing feat of engineering but probably not worth the effort to try to emulate the state on both ends of the connection (you'd have to remember window positions, split pane arrangements, not to mention the state of each virtual terminal within tmux).</div>
<div><br></div><div>When you do get around to implementing a reliable octet stream, please keep this case in mind. Even though we wouldn't get all the benefits that mosh has to offer for a vanilla terminal session, it would still be a better transport than ssh for lots of users.</div>
<div> </div><div>Thanks,</div><div>George</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div></div><div>Best regards,</div><div>Keith</div><div><div class="gmail_quote"><br></div><div class="gmail_quote"><div><div class="h5">On Sat, Jul 27, 2013 at 3:26 PM, George Nachman <span dir="ltr"><<a href="mailto:gnachman@llamas.org" target="_blank">gnachman@llamas.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi mosh-devel,<div>
<br></div><div>I'm the maintainer for iTerm2, a terminal emulator for Mac OS. About a year ago we added a feature to support a deep integration with tmux (details here: <a href="https://code.google.com/p/iterm2/wiki/TmuxIntegration" target="_blank">https://code.google.com/p/iterm2/wiki/TmuxIntegration</a>).</div>
<div><br></div><div>This integration works by passing messages between the terminal emulator and the tmux client using a custom protocol. While it works over ssh, it fails on mosh because mosh doesn't pass through the escape code that signals the terminal emulator to begin speaking the tmux protocol.</div>
<div><br></div><div>The escape code used is DCS 1000p (ESC P1000p), which is based on the ReGIS codes (<a href="http://www.vt100.net/docs/vt3xx-gp/chapter1.html" target="_blank">http://www.vt100.net/docs/vt3xx-gp/chapter1.html</a>). While I don't expect mosh to support ReGIS any time soon, would you consider passing this one escape code through?</div>
<div><br></div><div>Thanks for your consideration,</div><div>George</div></div>
<br></div></div>_______________________________________________<br>
mosh-devel mailing list<br>
<a href="mailto:mosh-devel@mit.edu" target="_blank">mosh-devel@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/mosh-devel" target="_blank">http://mailman.mit.edu/mailman/listinfo/mosh-devel</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div>