Support X forwarding

[keithw]

In theory, we could easily support X forwarding (with roaming!) by just conveying a verbatim octet stream in both directions over the underlying network layer -- the same kind of statesync object that we use for user input.

We wouldn't get predictive local UI, but we would get the other benefits of Mosh (support for sleep/wakeup and IP roaming).

[dt]

being able to setup arbitrary octet streams could be useful for port forwarding and agent forwarding too.

[peterjeremy]

There are techniques for optimising X11 over WANs that can significantly reduce bandwidth requirements - eg Xpra (http://www.xpra.org). That said, X11 over a 3G link is going to be painful at best because it's not possible to remove the RTT between input & display. Note that most Xclients need lots of RTTs to start up.

I support the idea that SSP be enhanced to allow multiple datastreams over a single "connection".

[staticfloat]

I'm very interested in this, @keithw, can you give a short outline of what work needs to be done to support this? Tunneling and X11 forwarding are high on my "want" lists from mosh (roaming tunneling over ssh is a dream come true) so I'd contribute what I can.

[keithw]

The biggest blocker at this point is probably coming up with a channel for arbitrary congestion-controlled octet streams that roam and handle intermittent connectivity gracefully. Then we can send anything (including reliable X protocol messages or other arbitrary stream) over that.

[coderarity]

+1

[novia713]

+1

[alexbw]

+1

[tzz]

Add my +1. This would enable Emacs' built-in Tramp package to edit files and run commands remotely over a mosh connection, which currently is impossible because the data stream is screen-oriented.

[tomvdsom]

+1

[TheSkorm]

+1
If you allow IP across mosh, then TCP would handle data loss, and UDP applications should already know how to deal with data loss. Great for easy VPN setup.
SOCKs proxy would be pretty nice too.

[EmDee]

+1