Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eternal Terminal: Remote terminal for the busy and impatient

mistertea.github.io

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Eternal Terminal: Remote terminal for the busy and impatient

#51

Post by Zaheer »

floatboth wrote: post #48
jitl wrote: post #38

Earlier quoted context omitted.

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 Mos…

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

It gives you native scrolling / tabs in iTerm2 which for me was a huge plus. I hated using the keyboard for copy and paste in TMux. That's just a personal preference though.

Re: Eternal Terminal: Remote terminal for the busy and impatient

#52

Post by tptacek »

RJIb8RBYxzAMX9u wrote: post #29
notheguyouthink wrote: post #12

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

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

Re: Eternal Terminal: Remote terminal for the busy and impatient

#53

Post by joosters »

falcolas wrote: post #47
dalore wrote: post #43

Earlier quoted context omitted.

All your saying is that the tcp connection doesn't break if you don't send anything whilst either host is not unreachable. You can break the connection in between and resume as long as your ip hasn't changed. So it's not really resuming ssh or anything, just a function of tcp sockets. Generally disabled on public since something could open up a bunch of listening sockets and then leave them and never close. With your…

No, not quite. The Linux kernel will close the TCP connection if it's idle after about 5 minutes (configurable), regardless of the application settings (with one exception noted in a bit). That's why you can even get "connection closed by peer" errors in the first place. TCP keepalive messages are used to circumvent the kernel (and every router between the two endpoints) from closing that TCP connection due to it bei…

I think you're referring to the OS sending its own TCP keepalive probes - as configured by sysctls like net.ipv4.tcp_keepalive_(intvl|probes|time)

TCP keepalive messages are what the kernel uses, and not what circumvents the kernel's own probes.

Applications can also implementation their own layers of 'are you alive?'/'yes I am' type messages on top. SSH has its own messages (see the ServerAliveInterval/ServerAliveCountMax config keys)

Re: Eternal Terminal: Remote terminal for the busy and impatient

#54

Post by joombaga »

btym wrote: post #45
geofft wrote: post #35

Earlier quoted context omitted.

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 cle…

>Of course the tradeoff is loss of scrollback. That could always be buffered on the server side.

If you use a terminal multiplexer (screen or tmux) it effectively is.

Re: Eternal Terminal: Remote terminal for the busy and impatient

#55

Post by noselasd »

falcolas wrote: post #47
dalore wrote: post #43

Earlier quoted context omitted.

All your saying is that the tcp connection doesn't break if you don't send anything whilst either host is not unreachable. You can break the connection in between and resume as long as your ip hasn't changed. So it's not really resuming ssh or anything, just a function of tcp sockets. Generally disabled on public since something could open up a bunch of listening sockets and then leave them and never close. With your…

No, not quite. The Linux kernel will close the TCP connection if it's idle after about 5 minutes (configurable), regardless of the application settings (with one exception noted in a bit). That's why you can even get "connection closed by peer" errors in the first place. TCP keepalive messages are used to circumvent the kernel (and every router between the two endpoints) from closing that TCP connection due to it bei…

The linux kernel does not automatically close a TCP connection if it's idle, it can stay idle for years on end (unless you globally enable TCP keepalives, or some NAT/stateful firewall devices inbetween times it out).

What's happening is not that your client is creating a new TCP connection and resumes an SSH session, you are just and continuing on your existing SSH session over an existing TCP connection - which you can do as long as neither the client ssh process or server sshd process have been restarted, and neither end has attempted and failed to send any data or otherwise timed/errored out the TCP connection.

(e.g. if you did a (sleep 60 ; echo test)& , then went hibernate on your client side, the server side would attempt to send some output in 60 seconds, and eventually time out the connection after a few minutes unless you wake up in the mean time)

Re: Eternal Terminal: Remote terminal for the busy and impatient

#59

Post by mbonzo »

amingilani wrote: post #58
mbonzo wrote: post #57

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

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

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

Re: Eternal Terminal: Remote terminal for the busy and impatient

#60

Post by falcolas »

Digitalghost wrote: post #49
falcolas wrote: post #15

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 th…

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…

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.

Post reply on HN