Re: [hybi] Framing Take VI (a compromise proposal)

[John Tamplin <[e-mail]>]

On Mon, Aug 16, 2010 at 10:32 AM, Greg Wilkins <[e-mail]> wrote:

> An extension-data op-code would allow a channel id to be associated
> with every extension-data frame, so messages would just have to be
> sent using that frame type.  I'm not sure that is a bad restriction
> given that I think intermediaries that do not understand MUX should do
> nothing with the data other than forward it.
>

To make sure I understand what you are proposing, here is a sample
conversation according to my understanding of what you are suggesting:

INI=1/FIN=1 opcode=CONTROL
   control: MUX - create channel (details)

INI=1/FIN=1 opcode=CONTROL
   control: MUX - use channel 1

INI=1/FIN=1 opcode=MUXDATA
   payload: multiplexed data:
      channel 1, 42 bytes: (channel 1 payload)

...

INI=1/FIN=1 opcode=CONTROL
   control: MUX - close channel 1

INI=1/FIN=1 opcode=CONTROL
   control: MUX - acknowledge close channel 1

If my understanding is correct, then I think that can work though I do think
it limits what intermediaries can do if they don't understand the frame
type.  As you say above, some extensions will mean they either blindly pass
the frame or drop it.  I worry that corporate firewalls will default to
dropping anything they can't inspect, which would limit the ability to
actually use extensions defined in the future, or at least greatly delay
their usefulness as such intermediaries will have to upgraded first.

The bigger problem is that this approach of allocating new opcodes means
that we need more opcodes, and we will have to pay that cost up front for
even unextended frames, since we won't be able to make it larger later
without breaking existing implementations.  Having a variable-length
extension header basically means we can allocate it later as we define new
extensions.

Maybe a compromise would be to define an opcode EXTENDED_FRAME, and for that
opcode the n bytes (however many we want to allocate) are an extension ID,
and the rest are extension-defined (which might include data from multiple
logical channels, for example, so it would need multiple frame
types/lengths).

Also note that you were previously suggesting moving the message length
field to the extension data -- that wouldn't be possible if we do away with
extension data and instead make it an opcode.  So, I assume that means we
would keep the message length as defined in the current proposal.

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