Re: Multiplexing: Efficiency of multiple multiplex controls in one WebSocket message

Note that I think the nature of sending flow control messages is that
there will be little opportunity to aggregate them into a single
message while sending.  Typically a flow control message will be sent
as some channel specific buffer it consumed below some threshhold.
It may then be more work (and latency) to attempt to build a queue of
such control messages in order to be able to send them as a single
message - it is probably simpler to just immediately frame them and
add them to the byte buffer that is being flushed.

So my hunch is that we will mostly end up sending a single control
frame per message. However, I don't see too much complexity or
problems in allowing them to be batched into a single message, so I
think it is low cost for a possible low gain.

But to be really clear, the current draft says:

   Binary frames with a channel ID of 0 contain zero or more multiplex
   control blocks in "Payload data".

This is written in terms of frames rather than messages.    Does this
mean we can assume that a channel ID 0 frame will never be fragmented,
even by intermediaries?     It would certainly make it easier to
handle if they were restricted to frames, as control blocks would not
be split over multiple frames - but I'm not sure we can guarantee
this?  what if we had 100,000 flow control ops in a single frame -
would intermediaries be prevented from fragmenting that?    If they
did fragment, they would have to put channelIDs into the fragments,
but would we also insist that they break the frames on control block
boundaries?

cheers

On 5 April 2012 19:20, John Tamplin <jat <at> google.com> wrote:
> On Thu, Apr 5, 2012 at 5:12 AM, Takeshi Yoshino <tyoshino <at> google.com> wrote:
>>
>> Current multiplexing spec allows putting multiple multiplex control blocks
>> in one WebSocket message. Maybe this is optimization to reduce overhead
>> (WebSocket header (2-10 octet), masking (4 octet, only C->S direction) and
>> channel ID of 0 (1 octet)) by merging multiple multiplex controls into one
>> message (especially for FlowControl which is exchanged frequently). Right,
>> John?
>
>
> Yes, the idea was that flow control messages, in particular, will be very
> frequent so we need to aggregate them to have acceptable efficiency.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> _______________________________________________
> hybi mailing list
> hybi <at> ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>