Re: [hybi] hum #3: Message

[Jack Moffitt <[e-mail]>]

>> 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.