> 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.)
