Re: GOAWAY and proxies (#458)

On 05/02/2014 03:30 PM, William Chan (陈智昌) wrote:
> 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.

Yeah, this is how I am hoping most clients are implemented.

> I'm not completely sold on needing any solution here

Is it because you perceive the problem to be small and not worth the 
text or that there is no problem? I'd argue strongly against both from 
experience. I am pretty sure all 1.1 to 2.0 intermediary implementations 
will run into this issue to varying degrees. It'd be better to have a 
standard way to deal with it and avoid the surprise factor and 
reinventing the wheel for new deployments.

On 05/02/2014 03:30 PM, William Chan (陈智昌) wrote:
> 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 
> <mailto: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 <mailto:martin.thomson@gmail.com>> wrote:
>
>         On 2 May 2014 14:22, Roberto Peon <grmocg@gmail.com
>         <mailto: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.
>
>
>