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