simon-git: putty (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  34df9990 Try to decouple directions of delayed compression.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2018-10-07 13:01:33

commit 34df99907a4ce8ad6dbd3d4c4426e77484156a12
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=34df99907a4ce8ad6dbd3d4c4426e77484156a12;hp=4c8c41b7a0e62c45e9a9b10c9a9fb849d65603a1
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Oct 7 12:56:57 2018 +0100

    Try to decouple directions of delayed compression.
    
    I ran 'git push' too soon on the last commit; after a bit more thought
    I realise that I didn't get the logic quite right in the case where
    one direction of the connection negotiates delayed compression and the
    other negotiates ordinary or no compression.
    
    For a start, we only need to worry about temporarily delaying outgoing
    packets to avoid the race condition if delayed compression applies to
    _outgoing_ packets - that can be disabled in the case where delayed
    compression is inbound only (though that is admittedly unlikely).
    
    Secondly, that means that detecting USERAUTH_SUCCESS to enable
    compression has to happen even if the output blockage wasn't in place.
    
    Thirdly, if we're independently enabling delayed compression in the
    two directions, we should only print an Event Log entry for the one we
    actually did!
    
    This revised version is probably more robust, although for the moment
    all of this is theoretical - I haven't tested against a server
    implementing unidirectional delayed compression.

 ssh2bpp.c | 79 +++++++++++++++++++++++++--------------------------------------
 1 file changed, 31 insertions(+), 48 deletions(-)