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

The impact on client-to-server initiated streams is another reason why
I suggested the credit-based approach and why it would likely be good
to have an RST_STREAM "ENHANCE YOUR CALM" error code [1]. If the
client misbehaves and sends too much too quickly, we have flow
control, settings, rst_stream and goaway options to deal with it.

[1] http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Server_Error

On Fri, May 3, 2013 at 10:34 AM, William Chan (陈智昌)
<willchan@chromium.org> wrote:
> 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.
>
>

Received on Friday, 3 May 2013 18:03:28 UTC