From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <167d149dc5dbd7b482a86a140cb42fff@akira.nop.cx>
To: 9fans@9fans.net
From: Tim Wiess <tim@nop.cx>
Date: Thu, 17 Apr 2008 15:43:55 -0700
In-Reply-To: <229795f1942c0e1a9fdf0d5cf32f3853@terzarima.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] telnet vs. godaddy whois
Topicbox-Message-UUID: 93ec2236-ead3-11e9-9d60-3106f5b1d025

>> what's the definition of `wrong' here?
>>     Meaning that the patch Eric proposed is probably the better way to
>>     deal with ACKs.  It wasn't meant to be taken too literally though,
>>     hence the "I think".
>
> what's the definition of `better' here?
>
> well, i won't persist in pedantry. i was just curious about the rationale for the
> adjectives. i'd say it isn't really to do with ACKs: the protocol definition rightly
> has ACK and PSH interpreted by different sides at the destination: input for ACK and output for PSH.
> in fact, the Plan 9 behaviour is rational for a sluggish or zero window: the receiving side might
> delay delivering data to the application until a PSH, but won't open the window if that queue is full.
> (thus rfc1122 mutters about deadlock in the absence of PSH, in 4.2.2.2.)

    My rationale was the section of the rfc that Eric quoted with his
    patch, which seemed to address my earlier suspicions.  But I just
    went back over that section and realize that I misinterperted that
    quote a little.  So I don't believe that P9's behavior is "wrong"
    in the sense that's it's violating any assumptions in the rfc.  It
    is (I think) the first time I've seen PSH being set on a plain ACK,
    but I do understand your argument.