Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

["Arman Djusupov" <[e-mail]>]

Good idea.

 

Hmm, actually this model can also work without the server assigning channel
IDs. The server simply needs to provide an initial quota to the slot and
then we have to allow the server to send FC frames to the client's logical
channel before the handshake is complete. So as soon as server receives an
AddChannelRequest and learns the channel ID, it would be sending normal FC
frames to the client. This way the FC would also work as usual both before
and after the handshake. The only difference from the current spec is that
the channel should be considered as established once an AddChannelRequest
received by the server. FC for the logical channel should start from the
moment when the server learns channel ID.

 

If the server sends a FC frame as soon as it receives an AddChannelRequest,
it should arrive to the client before the client uses all initial quota, so
the transmission should not stop. If there is a delay in communication it
would happen only due to the initial quota being too small for the
transmission rate. But such delays are inevitable both before and after
handshake. It depends entirely on the link speed and amount of quota
granted.

 

This way the client would be able to transmit as much as the server can
receive without waiting for an AddChannelResponse. I like this idea, it is
simple and would work fine.

 

With best regards,

Arman

 

 

From: Takeshi Yoshino [mailto:[e-mail]] 
Sent: Friday, June 22, 2012 9:18 AM
To: Arman Djusupov
Cc: Jamie Lokier; [e-mail]
Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

 

As we're going to add, say, NewChannelQuotaUpdate command which replenishes
new channel quota, another idea is assigning a channel ID by the server on
NewChannelQuotaUpdate. This way, the server can give pre-handshake quota to
each potential channel slot by the same manner as post-handshake quota
assignment. Pre-handshake quota can be carried over seamlessly.


Takeshi



On Fri, Jun 22, 2012 at 3:05 PM, Arman Djusupov <[e-mail]> wrote:

Hello Takeshi,

 

This will result in the protocol having two different stages of
communication. One stage before the handshake during which flow control
should be based on the common quota, and a second stage after the
end-of-pre-handshake-data frame is received during which flow control is
based on the logical channel quota. I'm ok with this solution, but I have
the impression that this is a bit of overkill.

 

It will be difficult to implement in a high concurrency multithreaded
environment. I can't say if there are any practical problems until I try
implementing it. But there might be difficulties that are not evident now.
In general it's becoming a bit more complex than simply working with a
self-assigned initial quota. 

 

With best regards,

Arman

 

From: Takeshi Yoshino [mailto:[e-mail]] 
Sent: Thursday, June 21, 2012 3:27 PM


To: Arman Djusupov
Cc: Jamie Lokier; [e-mail]
Subject: Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

 

On Tue, Jun 19, 2012 at 4:06 PM, Arman Djusupov <[e-mail]> wrote:

For reasons of simplicity and API limitations, browsers may simply always
level the quota along the channels, or they might prefer to slightly delay
sending the AddChannelRequest to check what is the size of the first message
being sent so that the AddChannelRequest with IQ_X = message size is sent
along with the first message, to avoid an extra roundtrip.

 

Considering the concern Jamie showed, how about sending some FlowControl
frame variant indicating the end of pre-handshake data after pre-handshake
frames? The client consumes total pre-handshake data quota it has for the
new channel as it like. And then, sends the end-of-pre-handshake-data frame.
It can be after or before receiving AddChannelResponse for the request. The
server knows how much pre-handshake data quota has been spent for the new
channel attempt by summing the data size of frames before the
end-of-pre-handshake-data frame. Delaying AddChannelRequest is fine but not
so flexible enough to address the concern Jamie showed.