Re: [hybi] Framing take IV

[Jamie Lokier <[e-mail]>]

Ian Fette (イアンフェッティ) wrote:
> 
>    As far as I can tell, what Jamie proposed is basically equivalent to
>    what I proposed
>    in [1]http://www.ietf.org/mail-archive/web/hybi/current/msg02726.html
>    Â - the problem with this approach is that it doesn't work well for
>    extensions that need a variable amount of space in each frame. For
>    something like multiplexing, compression, or fragmentation it works
>    fine as you have a fixed number of bits in each frame, but if you
>    wanted to do something like a mime extension, you would have to
>    reserve a large number of bits in each frame to make sure you had
>    enough. At least, if I am understanding the proposal correctly.
> 
>    That said, it has a very nice advantage in that I don't have to parse
>    header-goo on each frame, and that the data I care about is at a
>    well-defined position, at least for all frames in a single
>    client-server channel (if a different client negotiates a different
>    set of extensions, that would be different, obviously.)

Actually I was suggesting control-byte = the frame type id stored in
the initial, fixed position in the frame header, to avoid the problem
of type id collisions, and the format of the frame after the command
id would be entirely specific to that type id apart from the id and
length.

Since the frame type would only be used if both sides agreed to it in
negotiation (as with all extensions), and there would be no
collisions, that would be future-proof and easy to use.

Naturally an extension frame type like "multiplex" would tend to reuse
the existing frame types *inside* the multiplex frame type, so it can
carry anything.  (It's not the same as two separate frames, because
the multiplex frame would have an ordinary length field, then the
contents would include the subsidiary frame type without a length field).

I suggest that even message splitting into chunks could be treated as
an optional extension, which simple implementations needn't accept or
care about.  It would make simple implementations simpler.  We'd still
standardise this early, but make it optional.

Everything needs to be able to parse just the command id, the length,
and any flags which bear on forwarding/splitting/aggregating behaviour
to the limited extent those are universal.  The latter don't matter,
if they can be regarded as extensions.

[It's quite desirable that everything knows hows to ignore frame types
they don't understand, by parsing the type and length, so that (a)
active intermediaries don't trash the stream (since they might not
participate in negotiation), and (b) it helps with latency reduction
at connection startup.]

-- Jamie

ps. This turns out similar to IP-style "variable-length options",
represented in a different way.  Its major difference is, if the
receiver doesn't understand the frame type, then it won't know how to
skip the "option" by itself; it'll skip the whole frame.  For some
extension frame types, that is preferable to ignoring the "option"
part, but for others (as we learn from IP options) it's good to have
options which can be ignored by themselves.  Luckily we can create
either, by encoding the option as a frame by itself, or a frame
containing the remainder to be ignored if not understood.  That is
very flexible, and at the same time very easy to implement.