Re: Unidirectional streams PR

[Kazuho Oku <[e-mail]>]

2017-07-07 11:04 GMT+09:00 Martin Thomson <[e-mail]>:
> On 7 July 2017 at 11:43, Kazuho Oku <[e-mail]> wrote:
>> So it would be sensible to stop initiating new requests on an existing
>> connection when the number of unused stream IDs of the peer becomes as
>> low as max-concurrent-streams multiplied by some safety factor
>> (something like 10 would be enough, considering the probability of
>> loss or reordering of packets carrying DATA frames and consecutive
>> MAX_STREAM_ID frames).
>
> Yeah, you have to allow for the possibility of the server wanting to
> push some number of times in response to each of your requests.  I was
> originally going to say that you hit the wall only once you
> MAX_STREAM_ID hits the limit, but the server can always promise in
> excess of this limit.  If you want those promises to be resolved, then
> allowing more space is reasonable.  10 sounds reasonable, but we can't
> know the distribution of pushes to requests (today it is close to 0 in
> the aggregate, but this could change).

That's a good point.

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.

-- 
Kazuho Oku