- From: Daniel Sommermann <dcsommer@fb.com>
- Date: Tue, 22 Apr 2014 09:37:19 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "William Chan (ιζΊζ)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 04/21/2014 09:08 PM, Martin Thomson wrote: > As long the server waits >1RTT after sending the first GOAWAY before > identifying the *real* last request, isn't that enough? So the first GOAWAY acknowledges the last stream seen + 2*MAX_CONCURRENT_STREAMS and then 1 RTT later the server sends a second GOAWAY with the actual last seen stream? This seems like it could work in practice, but RTT isn't always stable so it seems like this mechanism could be flaky. The 2xGOAWAY approach would result in a smaller diff to the spec though. We would just need to add some text about expecting 2 GOAWAYs where the first GOAWAY may acknowledge a stream id greater than any initiated stream. However, from an implementation point of view I think a new frame is more straight forward and less error prone. With the new frame, you don't have to measure RTT or do arithmetic. DRAINING is a completely empty frame. In both solutions 2 frames are sent, but with a new frame type, the purpose of the two frames is more clear.
Received on Tuesday, 22 April 2014 16:37:49 UTC