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

[John Tamplin <[e-mail]>]

On Tue, Aug 17, 2010 at 11:15 PM, John Tamplin <[e-mail]> wrote:

> ... I would also be willing to say that the TML be included in a
> multiplexing extension, as that will be the primary use-case (as I see it,
> anyway).
>

I remembered now why I thought it should go in the base protocol.  Imagine
we have endpoints that only speak v1.0 of the protocol, which does not
include multiplexing.  They write their messages in single frames, so don't
have to deal with fragmentation while sending (but do on the receiving end
of course).

Later, we define a multiplexing extension.  Some intermediate network
decides to use the multiplexing extension to coalesce all these small
WebSocket messages going through their network.  To do that without
impacting latency, they need to fragment large messages so you don't wind up
starving the small messages.  At the exit point of their network, they demux
the packets back into separate streams.  However, unless they want a serious
buffering problem at the exit node, they don't want to defragment the
messages there, so they send it to the ultimate receiver still fragmented.
 If the TML is not included in the first fragment of the base protocol, then
the receiver has to reallocate/copy the buffer because it doesn't know how
big it is going to be.  Even if the MUX extension defined some way to pass
the TML to the end node, it would have to be modified to support this
extension even though it doesn't actually care about multiplexing.  Instead,
having the TML included in the first fragment in the base protocol means
these receivers can avoid buffer management problems even without knowing
anything about the MUX extension.

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