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

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

Oh,  and fwiw, I'm basing this on how things are captured in the spec, not
necessarily how it's actually implemented anywhere.  It may not be a
problem in in running code,  but as written there could be issues.  The
fact that push stream open is tied to originating stream state,  for
instance, is not nearly as obvious in the text as it could be.  The fact
that closing the origin stream causes pushed streams to full close,
thereby decrementing the concurrent stream counter,  is not obvious in the
current text. Perhaps it's just an editorial issue masquerading as a design
issue, but my gut is telling me that placing hard limits on push is going
to be problematic.  I'm liking Roberto's approach more the more I think
about it.
On Apr 29, 2013 2: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.
>