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

[William Chan (陈智昌) <[e-mail]>]

Why will the server top out? We set our browser advertised
MAX_CONCURRENT_STREAMS limit to 1000:
https://code.google.com/p/chromium/codesearch#chromium/src/net/spdy/spdy_session.h&sq=package:chromium&rcl=1367246521&l=49.
What receiver of push streams is going to have a low limit? Or are you
worried that it'll want to push more than 1000 streams in a roundtrip?


On Mon, Apr 29, 2013 at 6:08 PM, James M Snell <[e-mail]> wrote:

>
> It does not attempt to solve the core problem completely.  If anything it
> just pushes it down the road a bit.  As currently defined,  servers will
> top out quickly on the number of streams they can push.  With the revised
> scheme I proposed, we would give the recipient more control over the
> decision making process. A server will run up to the limits just as fast,
> but the recipient could allow the server to keep right on going if it
> wishes. In other words,  less coordination required between the endpoints.
>
> On Apr 29, 2013 11:20 AM, "Martin Thomson" <[e-mail]>
> wrote:
> [snip]
> >
> > I don't believe that the proposal improves the situation enough (or at
> > all) to justify the additional complexity.  That's something that you
> > need to assess for yourself.  This proposal provides more granular
> > control, but it doesn't address the core problem, which is that you
> > and I can only observe each other actions after some delay, which
> > means that we can't coordinate those actions perfectly.  Nor can be
> > build a perfect model of the other upon which to observe and act upon.
> >  The usual protocol issue.
>
>