Can you outline briefly what the benefit of this is compared to mosh?
The website doesn't make any claim about interactive prediction with is Mosh's killer feature.
Eternal Terminal: Remote terminal for the busy and impatient
31–40 of 73 posts
Re: Eternal Terminal: Remote terminal for the busy and impatient
#32Earlier quoted context omitted.
That was my concern too. So ssh is used for the initial handshake? BFHD. A lot of the interesting stuff happens afterward. The "how it works" page explicitly says this: > ET does not implement any of the SSH protocol That implies they rolled their own wire protocol. Maybe they did a good job (like mosh appears to have done). More likely not. I'd be OK using this on an internal network or over a VPN, but relying on it…
I think that sentence implies they're using OpenSSH not that they're rolling their own? --Edit-- A quick glance at the repo suggests they're using NaCl to handle the encryption + the SSH server for auth
Well, NaCl is certainly an improvement over a completely NIH approach, but doesn't necessarily provide features like forward secrecy. It would certainly be nice if the ET authors would explain in their "how it works" page how they've solved problems like these. Forward secrecy over resumable channels is not a trivial problem for which the quality of solutions should be assumed.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#33I feel like 99% of what I get from mosh is good performance over mobile networks, not IP roaming per se. In particular, TCP's congestion control algorithm is intended for networks that get congested, i.e., low-bandwidth shared-media physical networks where a dropped packet is a sign that you should lower your transmission rate. That's approximately zero of the networks I use; when my packets get dropped, it's usually because I'm in a train and tethered to my phone which went briefly out of range of cell service, or because someone turned on the microwave, or because I'm being handed off between wifi or cell towers, or whatever. So constantly reconnecting over TCP (especially if there's a significant application-layer handshake for the reconnection) doesn't seem like it solves the problems I have. mosh uses a custom, non-TCP reliable transport layer that is actually built for mobile networks.
Both scrollback and tmux -CC support are feasible in theory with mosh, though difficult to get right:
https://news.ycombinator.com/item?id=14228591#14229268
https://www.mail-archive.com/mosh-devel@mit.edu/msg00304.htm...
There's a fork of mosh linked in the first comment that switches the terminal-to-user end from a synchronized terminal screen to a bytestream (same as the user-to-terminal direction, i.e., keyboard input). It's not going to be robust to, say, catting a huge file and needing to Ctrl-C, but it should maintain mosh's robustness to radio (wifi/cell) network blips. It was designed for scrollback, but I'd sort of expect it to make tmux -CC work too.
Anyway, it is super cool to see more efforts in this space, and I bet for people who work primarily at desks with reliable internet connections, this is a huge improvement over, say, autossh. But for my own use case for mosh, this doesn't seem like it's got feature-parity yet. Maybe there are clever things you can do with aggressively restarting TCP connections that get you the same experience as mosh's UDP approach.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#34It's in a different category but there's also Apache Guacamole... typically you'd host your web proxy+container where ever your servers are, so the buffering and scrolling happens on the remote side and is rendered to your browser. No idea what happens if you try to ^C out of a 100MB cat halfway through.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#35After skimming the "How it Works" page, I'd be curious to know how they get around laggy interrupts, e.g. cat'ing a massive file and trying to Ctrl-C out of it. With Mosh, there's no giant delay because they don't care about history, they're just sending snapshots of the latest data. Hence why they use UDP as well. ET however uses TCP, and some type of BackedReader and BackedWriter for TCP data - which _implies_ to m…
> ...I'd be curious to know how they get around laggy interrupts, e.g. cat'ing a massive file and trying to Ctrl-C out of it. Presumably with the TCP URG flag. That said, I only read years ago that's how it's done, without ever checking myself. I've found references to in in telnet, but not ssh, so perhaps the latter uses some other mechanism.
TCP urgent data only indicates that the application should try really hard to read up to a certain point. It doesn't provide a way to abandon transmission of data that's already been sent with write(). It also generally does not convince routers on the way to prioritize the urgent packet before packets already in their buffers.
The way you'd want to use it is not to transmit the Ctrl-C urgently (that direction is clear), but to transmit the interruption of the reply urgently back to the client. And I think there's nothing that will save the server from having to actually send all the bytes that you managed to attempt to send before you received the Ctrl-C.
Also, it's completely broken: https://tools.ietf.org/html/rfc6093
mosh works around this by rendering the terminal window server-side and sending diffs of the terminal window (think VNC or streaming video) to the client. So the in-flight data from server to client is at most a screenful. If the data isn't sent in the first place, you don't have to worry about unsending it. (Of course the tradeoff is loss of scrollback.)
Re: Eternal Terminal: Remote terminal for the busy and impatient
#36I feel like 99% of what I get from mosh is good performance over mobile networks, not IP roaming per se. In particular, TCP's congestion control algorithm is intended for networks that get congested , i.e., low-bandwidth shared-media physical networks where a dropped packet is a sign that you should lower your transmission rate. That's approximately zero of the networks I use; when my packets get dropped, it's usuall…
IIRC, Terminal.app sends a key code when the user scrolls in mosh (or any program that takes over the screen). Maybe it would be possible to handle that and display the scroll back buffer?
Re: Eternal Terminal: Remote terminal for the busy and impatient
#37Can you outline briefly what the benefit of this is compared to mosh?
> benefit of this is compared to mosh? I use byobu (screen) for all the things this is supposed to address. I think. Byobu doesn't keep your ssh connection from dropping but the session is still there once you reconnect with no loss of history. Plus you can connect from multiple clients (using the same user account).
The advantage over a terminal emulator like screen or tmux seems to be automatic resumption.
That is, losing the ssh connection and needing to manually resume the session.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#38So it is mosh, but much better? I'll try it.
To me this seems like Mosh, but worse. I think that each project's approach has different strengths. For me, the best part of Mosh is the intelligent, asynchronous handling of type-ahead. Mosh feels really snappy, even over poor connections. I'm not bothered by needing to run Tmux on the remote for scrollback; I do that anyways, and I have no need for this fancy "control center" mode.
My big frustration with both Mosh and ET is that neither expose a data communication channel along side the PTY. I use SSH for port forwarding, Tmux paste buffer sync, file transfer, and SSH agent forwarding. Without those features, I'll always need to use SSH/Autossh along side these tools for my other SSH use cases.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#39FWIW, I've had a lot of personal success with just plain SSH managing the resumption of sessions. The trick is to not send keepalives from the client, and to not time out idle sessions on the server. When you can control both of these, you don't need extra tooling to resume sessions. That said, it's not as friendly to IP changes, nor does it provide predictive typing, so there's definitely something to be said for th…
I'm curious. What's the ssh options for managing the resumption of sessions?
It occurs automatically, so long as the client and server haven't timed the other out.
The client will time out the server by sending a packet with no response (such as via the 'ServerAliveInterval'), the server via unsetting 'ClientAliveInterval', 'ClientAliveCountMax', and 'TCPKeepAlive'.
Re: Eternal Terminal: Remote terminal for the busy and impatient
#40Earlier quoted context omitted.
Compilation works for me: https://asciinema.org/a/LkPYDdWkGgFybny8ChqOLQA8e What problems are you encountering? It might be worth opening a GitHub issue.
It is not clear from the error that you were missing libsodium. I don't remember what was my error anyway, I'll try again later. But I can't even find libsodium on my apt.
Agreed, it wasn't terribly clear. I essentially just guessed based on the mention of "sodium_LIBRARY_RELEASE". What OS are you running?