
Eternal Terminal: Remote terminal for the busy and impatient - yankcrime
https://mistertea.github.io/EternalTCP/
======
notheguyouthink
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
> ...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.

~~~
geofft
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](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.)

~~~
btym
_> Of course the tradeoff is loss of scrollback._

That could always be buffered on the server side.

~~~
geofft
You won't get native scrollback with server-side buffering. Precisely because
it's scrollback that's off the screen, there's no way to send ANSI escape
sequences to edit it after the fact; it has to actually be written to the
screen and then scrolled off. So you can't really do anything where you
transmit the current screen at higher priority and scrollback at lower
priority. (Unless you want to do something where mosh will write out
scrollback when it receives it and then write the actual current screen below
it, but I bet that will cause a ton of flicker.)

You can probably do some things to heuristically improve scrollback, e.g.,
telling the terminal sync thing to sync 1000 lines of scrollback if the
connection seems good and only the current screen if it seems poor. You won't
get reliable scrollback but maybe it's good enough.

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

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

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

------
geofft
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://news.ycombinator.com/item?id=14228591#14229268)

[https://www.mail-archive.com/mosh-
devel@mit.edu/msg00304.htm...](https://www.mail-archive.com/mosh-
devel@mit.edu/msg00304.html)

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

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

------
falcolas
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?

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

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

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

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

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

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

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

~~~
Digitalghost
Hey, Eternal Terminal developer here :-)

A one-time shared passkey is sent over ssh and then this passkey is used to
encrypt/decrypt the data in both directions. The server and the client have
different initial nonces.

~~~
visarga
I tried and failed to log in with ssh keys. Does 'et' require password login
or can it work with ssh keys as well?

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

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

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

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

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

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

~~~
JosephRedfern
Compilation works for me:
[https://asciinema.org/a/LkPYDdWkGgFybny8ChqOLQA8e](https://asciinema.org/a/LkPYDdWkGgFybny8ChqOLQA8e)

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

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

~~~
JosephRedfern
Agreed, it wasn't terribly clear. I essentially just guessed based on the
mention of "sodium_LIBRARY_RELEASE". What OS are you running?

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

------
bedros
Anyone used this behind corporate firewall

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

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

------
Lazy_Killer
What about tmux/screen?

~~~
Digitalghost
You can run tmux/screen inside a ET session

