Re: Design Issue: Max Concurrent Streams Limit and Unidirectional Streams

[Martin Thomson <[e-mail]>]

On 25 April 2013 10:50, James M Snell <[e-mail]> wrote:
> https://github.com/http2/http2-spec/issues/78
>...
> If a client sets a limit of 4 concurrent streams, and the server
> initiates 4 separate PUSH_PROMISE streams that the server half-closes
> but that are never half-closed by the client, the server will not be
> able to initiate new push streams for the duration of the session.

Yep, it's a problem.  We got rid of the unidirectional flag that
addressed this.  I can't speak for others, but I was aware of the
issue at the time, but I had a solution in mind.  That never got
written down, partly because we didn't have this discussion :)

On first blush, the only way to avoid the problem is to expect the
framing layer to be aware of what is going on above, but that's
probably not sensible.  But there's a better way:

Each stream has two separate state variables, each with three state
values: no packet yet, open, half-closed.  Streams that have inbound
== open || outbound == open are "in use" and count toward the stream
limit.  Documenting this might help clarify how the accounting is
done.

Importantly, this means that promised streams do not count toward the
limit.  It does however also imply that implementations will need to
be careful about how they allocate stream resources.  Pushes
complicate that a little because the lifecycle of headers doesn't
match stream lifecycles.  Again, I'd suggest an approach where
implementations defer commitment of flow control buffers until the
first flow-controlled frame arrives (memory pre-allocation might be
advisable for performance reasons, but that would not be an actual
commitment) and to ensure that any state for send and receive don't
have the same lifecycle.