Re: [hybi] sample implementation of my most recent proposal posted

[Greg Wilkins <[e-mail]>]

On 1 September 2010 04:15, Willy Tarreau <[e-mail]> wrote:
> On Tue, Aug 31, 2010 at 01:45:35PM -0400, John Tamplin wrote:
>> On Tue, Aug 31, 2010 at 1:19 PM, Pieter Hintjens <[e-mail]> wrote:
>> > If the use case for fragmentation is streaming of arbitrarily long
>> > messages whose size is unknown upfront (which is the only real use
>> > case that's been cited afair, with reference to HTTP chunking)
>>
>> The other main use case is for multiplexing, where you don't want
>> other logical channels blocked behind one sending a very large frame,
>> so you need to be able to fragment that frame.  Certainly, you could
>> define fragmentation within the mux payload, but it seems cleaner if
>> it can just reuse the fragmentation support defined in the base
>> protocol.
>
> That's one point where I agree with what was said by Shelby, we should
> not confuse fragmentation of the connection stream caused by multiplexed
> data streams and fragmentation of messages caused by unknown (or too
> long) message lengths.


The extension mechanism we need in the framing layer should be for
extensions that cannot be done in the data layer, such as:
  + tagging frames with channel ID's for multiplexing
  + telling the framing layer hints like total message size for more
efficient buffering.

If there is a use-case for arbitrary long meta-data associated with a
message, then I think that should be sent as part of the message body
(eg as a mime message), so that can be fragmented the normal way.

So perhaps we should define another op-code for a mime message that
has headers (hopefully length rather than CRLF encoded) and data, and
can be fragmented normally.   Having this defined will help stop
misuse of the frame extension mechanism.


cheers