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

[Dave Cridland <[e-mail]>]

On Wed Aug  4 15:33:13 2010, Patrick McManus wrote:
> 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.
> 
> 
I think some of these are bad arguments.


> 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.
> 
> 
No, because the receiver cnnot process portions of messages - at  
least with our current API. And you can achieve this behaviour by  
sending multiple messages anyway.


> * 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)
> 
> 
This is true, but again, you can do this by sending multiple messages.


> * 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.
> 
> 
Again, multiple messages.


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


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

This is true, in part.

The main reason I'd like to see fragmentation supported is to allow  
us to have a fixed-width length field, without having a maximal  
message length.

I would expect messages to be usually a single frame, and only larger  
when they couldn't be squeezed in or logically broken up.

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