Re: Unidirectional streams PR

[Kazuho Oku <[e-mail]>]

2017-07-07 12:33 GMT+09:00 Martin Thomson <[e-mail]>:
> On 7 July 2017 at 12:21, Kazuho Oku <[e-mail]> wrote:
>> Considering the complexity of guessing when the server runs out of
>> stream IDs, it might be easier if we could use a server-sent
>> CANCEL_REQUEST frame as an indication that the client needs to resend
>> the request on a new connection.
>
> If we ever get to the point where we have a good graceful shutdown,
> then that should mostly cover this.  CANCEL_REQUEST is likely still
> useful here to cover reordering.
>
> Here's my thinking on this: the server sends a GOAWAY identifying the
> highest numbered request that it has accepted (requests, not pushes).
> Anything higher than this will not be processed.  The connection goes
> away when responses to all those requests have been delivered,
> including all the promises that attach to those.
>
> The only trick here is that the server might be able to answer a
> request on stream X, but find that it can't answer X-1, which could
> arrive out of order.  So, yeah, CANCEL_REQUEST is a good fit for that.
> RST_STREAM isn't useful here because the stream can be closed when the
> server makes this discovery.
>
> Either way, having the server being able to cancel requests is good
> practice, because it might not be in a position to use RST_STREAM.

Thank you for the answer. I agree with your observations.

In https://mailarchive.ietf.org/arch/msg/quic/9VqjoX4acCDrxMKV2AmOQjspe3Q
Igor has suggested using DISINTEREST frame for cancelling requests
from the client-side. In the end, it might make sense for the
uni-directional-stream-only approach to have a frame that can be sent
in any direction for cancelling a request.

-- 
Kazuho Oku