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

As I understand the proposal, which I believe ties into the issue James
raised at the beginning here, the goal is to be able to open and close a
directional stream without an ACK, which I am nervous about as I said above
without much detail. Concretely speaking, a HTTP GET is a HEADERS+PRIORITY
frame with a FINAL flag or an extra DATA frame with FINAL flag. This means
that the request effectively never gets counted against the directional
stream limit, as controlled by the receiver which sends a
MAX_CONCURRENT_STREAMS setting, since it open and closes the direction in
the same frame (or closes in the subsequent empty DATA frame).


On Fri, May 3, 2013 at 1:52 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 3 May 2013 09:44, William Chan (陈智昌) <willchan@chromium.org> wrote:
> > I'd like server folks to chime in, but doing this makes me feel a bit
> > nervous. I feel this effectively disables the directional concurrent
> streams
> > limit. The bidirectional full-close essentially acts like an ACK, so
> > removing it might result in an unbounded number of streams.
>
> I think that I know what you mean here, but can you try to expand a
> little?  Do you refer to the possible gap between close on the
> initiating direction and the first frame on the responding direction;
> a gap that might cause the stream to escape accounting?  I think that
> is a tractable problem - any unbounded-ness is under the control of
> the initiating peer.
>