Re: [hybi] Framing take IV [why fragment]

[Patrick McManus <[e-mail]>]

On Wed, 2010-08-04 at 00:53 +0000, Ian Hickson wrote:
>  I could see an argument for supporting 
> fragmentation in the case of multiplexing, but without that it doesn't 
> seem to actually gain us anything.

In the absence of fragmentation the sender must have the entire message
available in order to prefix the total length in the header - so it
engages in store and forward instead of streaming behavior.

Benefits of streaming:

* Reduced memory consumption on the sender in cases where the message is
being "passed through". A service that does a large database query is a
good example here - the results can be passed back as they are found
even before you know how many there are.

* overall transfer time is reduced when the data to be sent takes time
to generate. Again, consider the DB query example. the transfer time for
the initial records is overlapped with the "think time" of the whole
transaction. Instead of the total send time being "processing + bulk
transfer" it is max (processing + network latency, bulk transfer)

* the receiver can overlap decompression with the receipt of streamed
chunks instead of adding decompression as a store-and-forward step onto
the end. (because without chunking the server cannot begin to send the
document until the whole thing is spooled). This will improve effective
message transfer time up to the JS layer.

* better latency properties to the recving ws stack. Other APIs than the
anticipated JS one may make use of that at no cost to the JS one.

And of course, as you say, fragmentation allows multiplexing and
effective prioritization of flows by the sender.