Seems like an obviously good call. Applications that would be impacted by this can either clear the nodelay flag with setsockopt () or better yet fix it in userspace by calling send() less often.
Yeah I get that; I guess the question is why couldn’t the terminals have buffered keystrokes? I’m guessing the answer is that the terminals of the time weren’t sufficiently sophisticated.
There are multiple layers where the buffering might happen.
Typically not in the terminal: for example the ASR33 was electromechanical, and the ADM3a was “dumb” (as opposed to smart terminals like the IBM 3270).
Then there’s the kernel tty driver, which can do input line buffering with simple editing (^H, ^W, ^U) or raw character-at-a-time mode.
Then there’s the telnet protocol which has similar facilities for switching between line-buffered and raw mode.
But in many cases, the user will be running a screen editor or mail/news reader that puts the terminal into raw mode, leading to tinygrams when it is used across the network.
Related fun thing, openssh buffers keystrokes a little and sends them out at regular intervals (I think 10ms) instead of at the rate you’re actually typing, in order to avoid attacks where you try to guess what the user is typing by looking at the times in between keystrokes, which are affected by the distances between keys and the geometry of the human hand.
Seems like an obviously good call. Applications that would be impacted by this can either clear the nodelay flag with setsockopt () or better yet fix it in userspace by calling send() less often.
It is pleasing how small the patch is, too.
That seems like such an obvious thing to do that I wonder why it wasn’t done in the first place.
… I assume because even back in the day there was a sufficient amount of existing “chatty” software that’d never get patched.
It just goes to show that kicking the can down the road will never make things easier.
It was because of terminals. Typing each character would send a packet.
Yeah I get that; I guess the question is why couldn’t the terminals have buffered keystrokes? I’m guessing the answer is that the terminals of the time weren’t sufficiently sophisticated.
There are multiple layers where the buffering might happen.
Typically not in the terminal: for example the ASR33 was electromechanical, and the ADM3a was “dumb” (as opposed to smart terminals like the IBM 3270).
Then there’s the kernel tty driver, which can do input line buffering with simple editing (^H, ^W, ^U) or raw character-at-a-time mode.
Then there’s the telnet protocol which has similar facilities for switching between line-buffered and raw mode.
But in many cases, the user will be running a screen editor or mail/news reader that puts the terminal into raw mode, leading to tinygrams when it is used across the network.
Related fun thing, openssh buffers keystrokes a little and sends them out at regular intervals (I think 10ms) instead of at the rate you’re actually typing, in order to avoid attacks where you try to guess what the user is typing by looking at the times in between keystrokes, which are affected by the distances between keys and the geometry of the human hand.