Re: [hybi] hum #3: Message

Sigh, perils of editing. Should read "The hum _was_ agnostic as to whether
we use fixed or variable length encoding."

2010/8/5 Ian Fette (イアンフェッティ) <ifette@google.com>

> The first hum I think may hopefully be slightly less contentious if people
> read it carefully? The hum was not agnostic as to whether we use fixed or
> variable length encoding. The hum was whether a message is composed of one
> or more frames. In some proposals, e.g. Proposal V [1], a message could be
> either one frame (of variable length) or multiple frames, depending on what
> makes sense in terms of efficiency. If it's more efficient for the client to
> just sendfile() in a single frame and it's not interested in things like
> multiplexing, that's supported, via a variable length "length". If the
> server is generating data dynamically and wants to send it as it becomes
> available to reduce latency, that's also supported. It does require that
> clients be aware of fragmentation and able to receive fragmented data, but
> does not require the client to send fragmented data. Thus, I would hope that
> if people are willing to accept "must be able to receive fragmented data but
> are not required to send fragmented data" they could agree on that as a
> middle ground, which is in line with the first hum.
>
> [1] http://www.ietf.org/mail-archive/web/hybi/current/msg02924.html
>
>
> On Thu, Aug 5, 2010 at 3:17 PM, Jack Moffitt <jack@collecta.com> wrote:
>
>> >> The kernel's sendfile() is responsible for a lot of the HTTP server
>> >> optimization for static resources, and for this case, I think it is
>> >> true that doing any framing that shows up in the middle of the file
>> >> would lead to a big inefficiency.
>> >
>> > I think there's definitely use cases for transferring large static
>> resources over WebSocket. Consider syncing a media library where items may
>> have been added on either end.  Sync seems like a pretty likely target for
>> WebSocket. You will want to do large static transfers in both directions,
>> and it seems better to use the existing warmed-up WebSocket TCP connection
>> than to make fresh HTTP connections.
>>
>> After doing some research, it appears that sendfile() and its ilk use
>> ranges anyway, and that many implementations already chunk them (nginx
>> seems to do so first to get to a sector boundary, and then at a size
>> of 2G-1). Losing sendfile() completely would be bad, but even in the
>> chunked case, you can still do sendfile() for each chunk. Of course,
>> more calls to sendfile() are worse than fewer, but I imagine most of
>> the efficiency is retained as all memory copies in userland are still
>> eliminated.
>>
>> I don't have the data on the difference, but if it comes down to this
>> particular issue being the deciding factor for consensus, such data
>> can be obtained.
>>
>> With this in mind, I'm in favor of fixed length headers, which implies
>> chunking and multiple frames per message in some cases.
>>
>> jack.
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
>