Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

[Takeshi Yoshino <[e-mail]>]

On Wed, Jun 13, 2012 at 7:18 PM, Takeshi Yoshino <[e-mail]>wrote:

> On Thu, Jun 7, 2012 at 12:44 PM, Jamie Lokier <[e-mail]> wrote:
>
>> If there is a max_simultaneous_handshakes - why not recast that as
>> "initial new-channels window" - meaning a flow control grant, which is
>> updated by further grants from the server.  (Very similar to the flow
>> control per channel).
>>
>
> Good idea. I'll take it.
>

I'm designing algorithm to realize this. My current idea is as follows.
Just a first strawman. It's very complicated.

- New channel window is a set of slots for new channel creation attempts
-- Each slot corresponds to one future/in-flight AddChannelRequest
-- Each slot (Slot_k) has pre-handshake quota (PQ_k)
-- When received, say, NewChannelQuota block, add a new slot. The new slot
has pre-handshake quota of 0
- When received, say, PreHandshakeQuota block, split it up and add to slots
so that PQ_k are leveled (older ones first) among all slots
- To issue an AddChannelRequest with channel ID X, the client picks oldest
unused slot (Slot_i) for it
- The client MAY send pre-handshake data for the channel X up to PQ_i
- When received the corresponding AddChannelResponse,
-- send quota for X is set to (PQ_i) - (total pre-handshake data sent) +
(initial send quota assigned by the AddChannelResponse)
-- Slot_i is removed from the new channel window

Goals are:

- make it able to increase the pre-handshake send quota for already
allocated slots
- give pre-handshake quota equally to all active slots
- carry over remaining pre-handshake quota into post-handshake quota
- deterministic, not affected by timing