Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

[Jamie Lokier <[e-mail]>]

Takeshi Yoshino wrote:
>    On Fri, Jun 22, 2012 at 9:17 PM, Jamie Lokier <[1][e-mail]>
>    wrote:
> 
>    Why not just send NewChannelSlots[ADD=3], instead of 3
> 
>      NewChannelSlot messages?
>      The slot messages are wasteful if the server is happy to accept 1000
>      low-usage slots from the beginning.
> 
>    >    (C) receives FlowControl[ID=1, quota=1024]
>    >    (C) receives FlowControl[ID=2, quota=1024]
>    >    (C) receives FlowControl[ID=3, quota=1024]
>    >    Now (C) is allowed to send pre-handshake data up to 1024 for each
>    of
>    >    allocated slots.
> 
>      Why not just send NewChannelSlots[ADD=3,PER_CHANNEL_QUOTA=1024]?
> 
>    This is fine if we don't need a way to increase pre-handshake quota for
>    the slots after allocating them e.g. when the server gets more room for
>    processing after the allocation.

So how do you do it in your scheme - resend FlowControl for each slot?

In that case, do this:

   NewChannelSlots[ADD=0,PER_CHANNEL_QUOTA=2048]

I suggest the per-channel quota, is a single value available to all
new channels, not a different value per channel.  Does it make sense
to have different new-channel "sizes"?

ADD increments the available quota for new channels, while
PER_CHANNEL_QUOTA sets that, I guess.  It's not allowed to reduce the
data quota, unless we have an "optimistic" mechanism for retracting
flow control in other ways as well, which a hop-by-hop extension might
do.  The message is, in effect, a flow control allocation to each new
channel that hasn't been created yet.

However, I wonder, if it decides to have more memory, why would the
server increase the per-channel data quota instead of increasing the
number of available slots?  Is there a reason for one over the other?

There may still a case for a shared pool of pre-handshake data quota
instead, but it would need to be carefully done because memory can't
be carved up arbitrarily; a per-channel overhead factor would be needed.

-- Jamie