Re: GOAWAY and proxies (#458)

I skimmed this PR, but haven't read everyone's comments :) So here's my
uninformed response.

The way our code works right now is, on receipt of a GOAWAY, we put
ourselves in a lame duck mode and kill all streams above the last accepted
stream id with an error code to retry them. If we're already in the lame
duck mode, great. We don't track anything about previous accepted stream
ids. This is a key property that I'd like to see preserved. Another way of
framing that is that I'd like not to introduce new connection state
variables to handle multiple GOAWAYs. Secondarily, I kinda feel like
DRAINING is more explicit than GOAWAY, so I'd paint it that color if
anything.

I'm not completely sold on needing any solution here, but if that's the
direction the working group wants to go, I wouldn't object too strongly.


On Fri, May 2, 2014 at 3:07 PM, Roberto Peon <grmocg@gmail.com> wrote:

> Agreed, but the current text doesn't allow for that to be determined with
> any certainty, since there may be a subsequent GOAWAY frame which may alter
> the last-potentially-processed-stream in *either* direction (as written).
>
> The solution to that part is simple-- GOAWAY can only give a number that
> is less than that which was sent before, thus indicating that a larger
> portion of the stream-space was *not* processed.
>
> Separately, I'd be shocked if many U-As actually did anything with
> subsequent GOAWAYs, however-- the logic for cancelling the retries, etc.
> would get very hairy very quickly if the assumption at time T was different
> than T+1 and one had already acted upon the information at time T.
>
> I still like DRAINING better for the purpose of getting clients to
> reconnect, regardless of what happens with GOAWAY.
> -=R
>
>
> On Fri, May 2, 2014 at 2:50 PM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> On 2 May 2014 14:22, Roberto Peon <grmocg@gmail.com> wrote:
>> > As written now, the receiver of GOAWAY has zero certainty about which
>> > streams were successfully processed as the server gets to change its
>> mind
>> > and isn't limited to simply changing the number in one direction.
>>
>> The purpose isn't to indicate what is successfully processed.  It's to
>> indicate what _might have been_ processed.
>>
>
>