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

On 12 April 2012 19:34, Takeshi Yoshino <tyoshino <at> google.com> wrote:
>
> I thought it's fine that a control block may be split into two or more
> fragments. As far as control blocks are sent in-order (relative to both
> other control blocks and data of multiplexed channels), it's not a problem.
>
> I don't see significant advantage from neither of them. Prohibition of
> fragmentation might make message processing easier as you said above, but
> adding constraints to care should be avoided unless we really
> need basically.
> (Maybe this is Patrick's original suggestion which made control frame
> unfragmentable and limited its length up to
> 125 http://trac.tools.ietf.org/wg/hybi/trac/ticket/19#comment:1)
>
> Rather I think we should add a text to say that fragments of a channel ID 0
> message MUST NOT be interleaved with other channels. Such operation makes it
> unclear at which point (of stream of the objective channel) the operation
> should be applied.

Takeshi,

I think to constrain channel 0 fragments to be not interleaved is just
as hard (if not harder) than saying they can't be fragmented and it
still represents adding a constraint either way.

So I believe we should strive to allow entirely normal fragmentation
of channel 0 messages, thus avoiding any constraint.  If we have to
have a constraint, then I'd prefer no fragmentation or fragmentation
on block boundaries rather than a restriction on interleaving.

The problem with normal fragmentation of channel0, is as you say, to
determine when an operation should be applied.  Is there a problem
with saying that the operations within a channel 0 message will only
be applied once the entire message is received?   As I've said
previously, I think it highly unlikely that we will have many blocks
in the same message, so I think fragmentation is unlikely to
occur..... but if it did, are there any bad consequences of delaying
processing?

I note that the current draft says in 7.5

   Multiplex control blocks are sent in data frames, so they can be
   fragmented.  Processing of a multiplex control block MAY be done once
   the block is received completely without waiting for the whole binary
   message is received (and becomes available after decoding if any).

Which say they MAY be processed as they are completely received,
suggesting that there is no MUST about processing them immediately - I
certainly can't think of a reason.   So perhaps this is the most
flexible way - obviously blocks MUST be processed when the entire
message is received, but MAY be processed as each frame is decoded.
I can't see any problems with early processing either.   I guess my
only concern is that it would allow different behaviour which might
allow for future complications, so I'd be OK with enforcing either
early or later processing of the blocks.

Note also that 7.5 only applies to encapsulated control frames - so
perhaps this text needs to be applied to all block types?

cheers