Re: [hybi] hum #3: Message

[Greg Wilkins <[e-mail]>]

Eitherway, I'd like to express strong support for the main parts of the hum:

    *  "Message" is a protocol unit with an end
    * A message may be composed of one or more "frame"s
    * Each frame has a length indication


But I agree with everybody about the arguments for and against the
various length encodings. I think the reason is that everybody is
right!

Sometimes it is more efficient to send big content without chunking
it.  eg in Jetty we use the NIO gather write mechanism to send a
header from a memory buffer with a file mapped buffer of content.
This means the file is sent to the network interface without going via
user space memory.
But then I also very very rarely see any server side developers set
the content-length of dynamic content, so that is almost always best
sent as chunks.  You can have some very large dynamic content coming
out of DB selects etc.


I think the best solution is  fragmentation plus a variable length
encoding since this allows:

 + chunking of dynamic content
 + sending of big content as a single frame
 + minimal cost in bytes for the most frequent little messages.
 + having fragments in the base protocol means that all extensions
must handle them and thus it makes it easier to add extensions like
multiplexing without breaking other things.

The main down side I can think of is that it makes it harder to word
align header and data, but then I don't see a large demand for that.

There is some extra complexity on the receiver for fragments, but I do
not think it is significant.


regards






On 6 August 2010 07:25, Dave Cridland <[e-mail]> wrote:
> On Thu Aug  5 22:18:01 2010, Maciej Stachowiak wrote:
>>
>> On Aug 5, 2010, at 2:09 PM, Maciej Stachowiak wrote:
>>
>> >
>> > On Aug 5, 2010, at 1:43 PM, Jack Moffitt wrote:
>> >
>> >>>> Sending a file from disk to the network without processing it in any
>> >>>> way
>> >>>> is more efficient than cutting it into slices and interleaving with
>> >>>> headers.
>> >>>> The IP layer is already going to cut it into slices, in a way that
>> >>>> almost
>> >>>> certainly won't line up with WebSocket-level fragment boundaries.
>> >>>
>> >>> There's no way to "send a file over the network without processing".
>> >>> You
>> >>> need to read it into memory, and then write it to the network. Of
>> >>> course
>> >>> adding frame headers *is* overhead, but it's really identical or close
>> >>> to
>> >>> the overhead on the wire, nothing more.
>> >>
>> >> 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'm not sure how useful this pattern is with dynamic data though. I
>> >> think people will continue to send most static resources via regular
>> >> HTTP because it is very, very good at it.
>> >
>> > 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.
>>
>> If it's an optional extension that intermediaries could ignore, that makes
>> it unlikely that there will be a default expectation that it should be sent
>> and have a correct value.
>
> I'm fine withdefining the extension in the core spec, and making this a
> SHOULD. I can see cases meaning it cannot be a MUST. Would this satisfy?
>
> Dave.
> --
> Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
>  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>  - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>