3 ms·

> The client sends l and then immediately receives an l sent back. I guess the idea here is that the client is really dumb – it doesn’t know that when I type an

by lqet 4y ago

> The client sends l and then immediately receives an l sent back. I guess the idea here is that the client is really dumb – it doesn’t know that when I type an l, I want an l to be echoed back to the screen. It has to be told explicitly by the server process to display it. Of course the client may be really dumb! Here is a 1930s teletype used as a Linux terminal: https://youtu.be/2XLZ4Z8LpEE?t=656 https://youtu.be/2XLZ4Z8LpEE?t=656 If you would not do it that way, you would run into all kinds of synchronicity problems. How could you be sure that, after rapidly making 50 keystrokes, every keystroke was received by the other end, in that order?

freedomben 4y ago
> How could you be sure that, after rapidly making 50 keystrokes, every keystroke was received by the other end, in that order? Exactly. I implemented a client that emulated a VT100 early in my career, and this is a real problem. There are various strategies you can use but by far the simplest and safest seemed to just be the echo and for the client to always display exactly what it receives[1]. There's nothing worse than typing out a command that you realize is wrong and potentially destructive, only to Ctrl+U it and have the client kill the line but the server didn't get the instruction, so when you press enter it runs the evil command. If the command doesn't echo anything you may not even know! I once accidented a space in the path I was deleting when (recklessly with -rf) trying to remove my ~/bin directory, like this: rm -rf ~ /bin Good Lord that was a bad day. Thankfully I still had the installation disc to restore /bin, and a relatively recent backup of my home directory to restore that. I lost a few days of uncommitted code, but that felt like a trifle compared to what it could have been :-) [1]: I love how mosh[2] handles this to get the best of both worlds. It will smartly show you what you typed, but sill underline it until it actually receives the echo from the server, so you can type and feel like there's no delay between bytes, but still be confident that client state matches the server state. [2]: https://mosh.org/ https://mosh.org/
icedchai 4y ago
This was definitely a problem in the dialup modem days before error correction, where line noise might add extra characters, or modify what you were sending.
gnubison 4y ago
More importantly, how do you know whether the keystrokes should be displayed at all? For example, take vi. When it starts up, it sets cc.c_lflag &= ~ECHO (basically like “stty -echo”) so that normal mode commands aren’t printed onscreen. The kernel knows whether ECHO is set, which is why it handles echoing.

by lqet 4y ago

freedomben 4y ago

> How could you be sure that, after rapidly making 50 keystrokes, every keystroke was received by the other end, in that order? Exactly. I implemented a client that emulated a VT100 early in my career, and this is a real problem. There are various strategies you can use but by far the simplest and safest seemed to just be the echo and for the client to always display exactly what it receives[1]. There's nothing worse than typing out a command that you realize is wrong and potentially destructive, only to Ctrl+U it and have the client kill the line but the server didn't get the instruction, so when you press enter it runs the evil command. If the command doesn't echo anything you may not even know! I once accidented a space in the path I was deleting when (recklessly with -rf) trying to remove my ~/bin directory, like this: rm -rf ~ /bin Good Lord that was a bad day. Thankfully I still had the installation disc to restore /bin, and a relatively recent backup of my home directory to restore that. I lost a few days of uncommitted code, but that felt like a trifle compared to what it could have been :-) [1]: I love how mosh[2] handles this to get the best of both worlds. It will smartly show you what you typed, but sill underline it until it actually receives the echo from the server, so you can type and feel like there's no delay between bytes, but still be confident that client state matches the server state. [2]: https://mosh.org/ https://mosh.org/

icedchai 4y ago

This was definitely a problem in the dialup modem days before error correction, where line noise might add extra characters, or modify what you were sending.

gnubison 4y ago

More importantly, how do you know whether the keystrokes should be displayed at all? For example, take vi. When it starts up, it sets cc.c_lflag &= ~ECHO (basically like “stty -echo”) so that normal mode commands aren’t printed onscreen. The kernel knows whether ECHO is set, which is why it handles echoing.