simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  1ce8ec9c lineedit_send_line: batch up output characters.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2024-12-14 12:46:10

commit 1ce8ec9c825dd3432a515c25b7e01b808b2ad004
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=1ce8ec9c825dd3432a515c25b7e01b808b2ad004;hp=edd5e13ffc976025443e0b9d75888249aa3325a9
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Dec 8 22:08:30 2024 +0000

    lineedit_send_line: batch up output characters.
    
    When the user pressed Return at the end of a line, we were calling the
    TermLineEditor's receiver function once for each character in the line
    buffer. A Telnet user reported from looking at packet traces that this
    leads to each character being sent in its own TCP segment, which is
    wasteful and silly, and a regression in 0.82 compared to 0.81.
    
    You can see the SSH version of the phenomenon even more easily in
    PuTTY's own SSH logs, without having to look at the TCP layer at all:
    you get a separate SSH2_MSG_CHANNEL_DATA per character when sending a
    line that you entered via local editing in the GUI terminal.
    
    The fix in this commit makes lineedit_send_line() collect keystrokes
    into a temporary bufchain and pass them on to the backend in chunks
    the size of a bufchain block.
    
    This is better, but still not completely ideal: lineedit_send_line()
    is often followed by a call to lineedit_send_newline(), and there's no
    buffering done between _those_ functions. So you'll still see a
    separate SSH message / Telnet TCP segment for the newline after the
    line.
    
    I haven't fixed that in this commit, for two reasons. First, unlike
    the character-by-character sending of the line content, it's not a
    regression in 0.82: previous versions also sent the newline in a
    separate packet and nobody complained about that. Second, it's much
    more difficult, because newlines are handled specially - in particular
    by the Telnet backend, which sometimes turns them into a wire sequence
    CR LF that can't be generated by passing any literal byte to
    backend_send. So you'd need to violate a load of layers, or else have
    multiple parts of the system buffer up output and then arrange to
    release it on a toplevel callback or some such. Much more code, more
    risk of bugs, and less gain.

 terminal/lineedit.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)