Re: [hybi] hum #3: Message

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
>