Eternal Terminal: Remote terminal for the busy and impatient

https://mistertea.github.io/EternalTCP/

by yankcrime • 9 years ago

220 69 9 years ago

mistertea.github.io

knz42• 9 years ago

Can you outline briefly what the benefit of this is compared to mosh?

wwarren• 9 years ago

Not OP, but the page says

Mosh is a popular alternative to ET. While mosh provides the same core funtionality as ET, it does not support native scrolling nor tmux control mode (tmux -CC).

Matt3o12_• 9 years ago

According to their website (the third bullet point):

mosh: Mosh is a popular alternative to ET. While mosh provides the same core funtionality as ET, it does not support native scrolling nor tmux control mode (tmux -CC).

ovi256• 9 years ago

While mosh provides the same core functionality as ET, it does not support native scrolling nor tmux control mode (tmux -CC).

nopcode• 9 years ago

Its also Apache 2.0 licensed, compared to the GPL3 that strangles Mosh.

Pity its not a freer license though.

lathiat• 9 years ago

How does GPLv3 strangle mosh?

falcolas6• 9 years ago

How does a GPL license "strangle" a network connection tool? Are you really bothered that you can't incorporate it into your own BSD/closed source project, or is it a purely ideological "it's not BSD, so it doesn't respect me as a developer" stance?

jefurii• 9 years ago

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).

rocqua• 9 years ago

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.

Digitalghost6• 9 years ago

You can continue to use screen with ET and not have to worry about disconnecting/reconnecting.

eeZah7Ux• 9 years ago

The website doesn't make any claim about interactive prediction with is Mosh's killer feature.

nitrix2• 9 years ago

How robust is this to man-in-the-middle attacks?

falsedan2• 9 years ago

Since it uses SSH to transport the initial session password, as robustly as SSH is.

nitrix2• 9 years ago

The initial password is only used for authentication, isn't it? Someone could (unless more details are provided) snoop on the connection or even inject packets.

fiatjaf3• 9 years ago

So it is mosh, but much better? I'll try it.

fiatjaf3• 9 years ago

The PPA doesn't work. The compilation instructions fail.

JosephRedfern2• 9 years ago

Compilation works for me: https://asciinema.org/a/LkPYDdWkGgFybny8ChqOLQA8e

What problems are you encountering? It might be worth opening a GitHub issue.

Digitalghost6• 9 years ago

Hey, please file an issue on github: https://github.com/MisterTea/EternalTCP/issues

You may be running a distro that doesn't have libsodium (such as ubuntu 14). In this case you have to grab libsodium manually and build et from source.

jitl• 9 years ago

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.

floatboth• 9 years ago

I've been using tmux for years and I have no idea what "control center mode" even means :D

notheguyouthink• 9 years ago

After 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 me that everything is being sent/received in a massive queue. Also, it supports scrolling, which would be difficult _(but not impossible)_ if they only cared about recent frames like Mosh.

Finally, I'm curious how well it handles mobile connections. That's another selling point of Mosh. Admittedly I never use mobile internet, so that's not a concern of mine, personally.

I love Mosh and I'm always happy to see competing apps, hope they complement each other well :)

RJIb8RBYxzAMX9u• 9 years ago

...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.

geofft5• 9 years ago

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.)

tptacek• 9 years ago

Virtually nothing uses TCP URG anymore; it is for all intents and purposes obsolete.

falcolas6• 9 years ago

FWIW, 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 the value of tools such as these.

I do have one question, given the tmux and scrolling support, how much mosh-like lag compensation can ET provide?

xianwen• 9 years ago

I'm curious. What's the ssh options for managing the resumption of sessions?

falcolas6• 9 years ago

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'.

cmurf• 9 years ago

Resumption? None that I can find in sshd_config but there are several related to increasing tolerances to prevent it from terminating in the first place.

ClientAliveCountMax default is 3 ClientAliveInterval default is 0

Ergo by default ClientAlive messaging isn't used. If Interval were set to 60, the connection would be terminated after 3 minutes.

From man sshd_config: TCPKeepAlive "Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying. On the other hand, if TCP keepalives are not sent, sessions may hang indefinitely on the server, leaving "ghost" users and consuming server resources.

The default is yes (to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. This avoids infinitely hanging sessions."

That's probably not that interesting because it's considered spoofable. Maybe more interesting are the client side ssh_config options which allow for opportunistic multiplexing:

ControlMaster ControlPath ControlPersist

Digitalghost6• 9 years ago

ET dev here.

ET is primarily made for IP changes and also because the kernel/router will sometimes kill stale connections, and it's not possible to send keep-alives if your laptop is asleep.

There is no lag compensation because ET is not a terminal emulator, it's only a remote shell. I cannot create predictive letters and undo them reliably (passing backspace commands to the terminal sometimes does not undo the last letter). Lag compensation would need to be implemented by a terminal emulator such as hyper.js.

falcolas6• 9 years ago

As per the other response thread, SSH already compensates for closed TCP connections, so long as it's configured appropriately.

WRT the lag compensation - this is something mosh does, so if ET does not, it's worth pointing out.

So, as it stands, persistence of the session across IP changes seems to be the primary differentiating feature. Good to know.

metaobject• 9 years ago

Will ET resume a session where I'm remotely running "emacs -nw"? This runs emacs in a non-GUI, curses-like mode.

OriginalPenguin• 9 years ago

Sure, if you have a reliable internet connection, and a desktop computer and a server that you both control, you probably don't need this or mosh.

But mosh (and presumably this program as well) really, really shine with a laptop that you might hibernate for days, and then boot back up, and it's just as you left it.

_khhm• 9 years ago

Why does it need it's own port if it rides over SSH? Couldn't SSH just forward a port?

zie• 9 years ago

It could, but then it would have to deal with the SSH line protocol which is complicated, because it allows for a LOT of stuff. ET is basically pretty dumb, it basically just dumps a PTY onto the network, and is way simpler.

geofft5• 9 years ago

I 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.

Gaelan• 9 years ago

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?

geofft5• 9 years ago

Oh, yes, if there's a way to signal a scroll attempt to the application then it's totally doable.

Is this the "Scroll alternate screen" checkbox? I believe that just controls the scroll wheel, and makes it not do native scrolling and instead just send a page-up or something. If so, then non-native scrolling is definitely possible ... but it's already possible if you run screen or tmux instead of mosh. (Which is what I do, and it works fine for me, in part because I learned how to use screen's scrollback even before mosh existed.) I can see the argument for exposing this with better keyboard shortcuts than screen's inscrutable ones, but my impression is that people mostly want native scrolling so they can, e.g., drag in the terminal UI to copy and paste a large amount of text. You can't do that with non-native scrollback, since the text isn't all contiguous in the terminal window.

technofiend• 9 years ago

It'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.

h1rschnas3• 9 years ago

Does it support ssh agent forwarding? The most important missing feature in mosh imho.

Lazy_Killer• 9 years ago

What about tmux/screen?

Digitalghost6• 9 years ago

You can run tmux/screen inside a ET session

mbonzo2• 9 years ago

Hi, I made a quick video showing ET in action and what it is: https://www.youtube.com/watch?v=_tzQhL-usbc

amingilani• 9 years ago

Looked for a video on the site, couldn't find it. Found this in the comments. Thank you!

mbonzo2• 9 years ago

Did the link work for you? I just updated the link because it was somewhat broken! It works now though :) NP!

bedros• 9 years ago

Anyone used this behind corporate firewall

Digitalghost6• 9 years ago

Yep, it's just like ssh so as long as you can make a TCP connection to the server you can use it from behind a firewall.

pmarreck• 9 years ago

Can anyone who's tried both this and mosh, comment on them both?

majkinetor• 9 years ago

kitty (fork of putty) does the reconnect thing on Windows, among many other things: cinst kitty

Eternal Terminal: Remote terminal for the busy and impatient

Related Stories