Re: [hybi] Flow control quota

[John Tamplin <[e-mail]>]

On Fri, Jun 8, 2012 at 7:06 AM, Arman Djusupov <[e-mail]> wrote:

> Since we don't have better ideas, currently I see us having 2 options:
>
> 1. Permit the sender to send above the quota if the frame that has to be
> sent is not fragmentable, resulting in the quota going negative. The sender
> will have to wait for the quota to go positive before it can send the next
> frame. The receiver has to make sure that it supplements the sender's quota
> to a normal flow control window value once it detects that the sender has
> sent a frame above the quota. As long as circumstances are normal the size
> of the frame sent above the quota would be normal (e.g. more or less equal
> to the size of the frames sent previously). If the receiver detects an
> abuse
> of this functionality it may discard all frames and drop the logical
> channel.
>
> 2. Permit the mux extension to fragment frames of any type and to
> reassemble
> those frames to their original state on the receiving side. This is
> probably
> the most flexible solution in case if we can find an optimal format for
> writing those enveloped frames.
>
> A solution for the 2nd option:
> We need to encapsulate frame fragments into a mux message. In this case all
> mux frames would have their FIN bit set to 1 and opCode set to 2 (binary),
> so the payload of a mux frame will be transparent to all intermediaries
> that
> do not support mux. Mux frames would retain the current format and would
> have channelID in their extension data. In addition to that each mux
> message
> that corresponds to the first fragment of the original frame would include
> the frame length, opCode, FIN flag and RSV bits of the original frame;
> subsequent mux frames would include only the payload of the fragment.
>
> This format would introduce an additional overhead of 16 to 72 bits per
> original frame.
>
> This are just some option, I would be happy to read more ideas.


The original mux proposal introducing another framing layer which is
essentially your #2.  I rewrote it to something close to the current
proposal because lots of people didn't like it.

I think the fundamental issue is not having a separate message-level
framing rather than using one layer of framing for both messages and
frames, which was necessary for efficiency with small messages (which data
with the two apps we had at the time, Wave and GwtQuake, indicated would be
the bulk of the frames; it would be interesting to see the data again now
that there are some deployed apps) and to get consensus on simplicity.

-- 
John A. Tamplin
Software Engineer (GWT), Google