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

61–70 of 73 posts

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

#61

Post by geofft »

Gaelan wrote: post #36
geofft wrote: post #33

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

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.

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

#62

Post by geofft »

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.

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.

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

#63

Post by falcolas »

noselasd wrote: post #55
falcolas wrote: post #47

Earlier quoted context omitted.

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…

I did some hands-on research, and I now agree that you are correct. The behavior is absolutely acting like a resumption of the TCP session, not extra connectivity magic within SSHD.

Thanks for the persistence!

That said, though, there is something which closes idle, established, TCP connections, though it's not the kernel, it's iptables which does it. The timeout is something along the lines of 5 days by default, however. That's what I get for working from memory.

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

#64

Post by falsedan »

nitrix wrote: post #17
falsedan wrote: post #16

Earlier quoted context omitted.

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

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.

I should have said, session key (not password).

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

#67

Post by OriginalPenguin »

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…

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.

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

#68

Post by visarga »

Digitalghost wrote: post #44
nitrix wrote: post #17

Earlier quoted context omitted.

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.

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.

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

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

#69

Post by metaobject »

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…

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

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

#70

Post by zAy0LfpBZLC8mAC »

falcolas wrote: post #63
noselasd wrote: post #55

Earlier quoted context omitted.

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…

I did some hands-on research, and I now agree that you are correct. The behavior is absolutely acting like a resumption of the TCP session, not extra connectivity magic within SSHD. Thanks for the persistence! That said, though, there is something which closes idle, established, TCP connections, though it's not the kernel, it's iptables which does it. The timeout is something along the lines of 5 days by default, how…

No, there isn't, TCP is end-to-end, and can only be closed by the endpoints.

If you use iptables (or rather netfilter)'s stateful filter, then netfilter will forget the connection tracking state of the connection after a long-ish time without any traffic (may be 5 days, I don't remember). That doesn't close anything, it simply means that netfilter doesn't know about the connection anymore. No packets are being sent when that happens.

That in turn has two effects:

First, if you have a rule that only allows packets through for established connections, that rule will now not match packets from that connection anymore. But if the packet matches another rule that allows it to pass, then it will still make it through the firewall, and as a side effect that would then re-establish the connection tracking state, which in turn would also make the rule for established connections match again for any packets that follow.

So, in most cases, that's not in any way a problem: The next packet your client sends after a long idle time will just re-establish the connection tracking state and the connection will continue to work just fine.

Second, if the connection is NATted, the NAT state is part of the connection tracking state, and as such, the NAT mapping of the connection is also lost when the state is dropped. That means that the next packet (if it comes from the right direction) will once again consult the nat table, just as the very first packet of the connection, to establish a new NAT mapping. Now, in many cases, that will establish a new mapping that's exactly the same as the old mapping, in which case the connection also will continue to work just fine. Only if the new NAT mapping differs, that will cause the connection to fail. Yet another reason why you don't want to have NAT (and by extension, why you want IPv6).

Also, netfilter very much is in the kernel.

Post reply on HN