Re: [hybi] hum #3: Message

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
> 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.

I agree.  Being able to send big content as a single frame is
certainly simpler than having to split.

And I think that's likely to result in fewer buggy implementations
than a fixed header.  If there's a small maximum chunk, poor
implementations may implement send-splitting wrong, but go undetected
for years if most applications use messages that fit in a single
chunk.  Whereas it's hard to screw up a variable length encoding, when
you have to get it right for common usages.

I don't think multiplexing is helped or hindered by having fragments
in the base protocol.  A multiplexing implementation is the same
either way.  Proxying between a multiplexed and non-multiplexed stream
is much the same either way.

But I notice fragments are necessary in any situation where you might
want to:

   + abort a message in progress
   + inject a control message

For example when forwarding a large message, if an error is detected
by the forwarder, it might want to abort the message and follow it by
a control message describing the error it has received and start an
orderly close.

Without fragments, the only thing a forwarder could do would be to
close the socket, which gives very little information, not even saying
if it's the forwarder or the earlier sender that failed.

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

I don't think there is any practical overhead to frame header parsing
on modern hardware.  All variations we've talked about are extremely
simple.  However, there may be overhead in moving the data to some
place that benefits from alignment.  Even simple copying can benefit.

   + Answer: Allow a 1-byte padding message.  Let's call it 0x00 for
     simplicity.  Senders can pad if they think it'll improve efficiency.
     Receivers ignore it.

-- Jamie