Re: HEADERS and flow control

+1

On May 22, 2014, at 20:11, "gregw@intalio.com<mailto:gregw@intalio.com>" <gregw@intalio.com<mailto:gregw@intalio.com>> wrote:


Martin et al,

I really see the problems and confusion in this thread as another example of the complexities and problems that result when you "conflate some of the stream control functions with the application semantics functions in the interests of efficiency."

The definition of streams should be simple and robust and entirely independent of the semantics of the content of the streams.    A stream should be defined to exist from the time it ID is first mentioned (either in a frame ID or a PP) until frames have been sent in both directions with an end frame bit set.    Between those two events, the stream should be flow controlled regardless of content.

Once you have robust multiplexed framing, then you can layer HTTP semantics on top of that.   If a client wants to avoid the dispatch of its requests from being deferred, then it should just restrict it's headers to < the stream window size.

I think the hpack tail is really wagging this protocol dog!

Currently hpack is forcing this protocol to have a user accessible non flow controlled un-segmentable size unlimited meta data streams that has strict ordering criteria resulting in significant parallel slow down.

Our experience with SPDY is that the vast majority of the speed up comes from avoiding round trips rather than compression.    This means you need good multiplexing and good push mechanisms.  Compression is worthwhile, but I suspect that 90% of the gains can be achieved with a far simpler algorithm that does not impose such onerous constraints on the framing.

again apologies for giving these opinions late in the process.

--
Greg Wilkins <gregw@intalio.com<mailto:gregw@intalio.com>>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Thursday, 22 May 2014 19:39:25 UTC