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

[James M Snell <[e-mail]>]

Perhaps a simpler approach would be to just redefine the limit such
that an endpoint MUST NOT have more than MAX_CONCURRENT_STREAMS in the
Open state at any given time. We have already established that once
the stream is half-closed, new frames cannot be sent, so once the
server half-closes a steam it initiates, the counter is decremented
and the server is permitted to initiate another stream. The client can
choose to reject those additional streams if it chooses.

On Thu, Apr 25, 2013 at 12:25 PM, Martin Thomson
<[e-mail]> wrote:
> 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.