- From: David Krauss <potswa@gmail.com>
- Date: Tue, 22 Apr 2014 11:17:34 +0800
- To: Roberto Peon <grmocg@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
WINDOW_UPDATE frames are the tricky part. Consider a multithreaded server with a scheduling algorithm arbitrating the network output stream. If the scheduler sends an incomplete header block, then the usually asynchronous processes of sending WINDOW_UPDATEs and responding to PINGs need to wait for it to finish. The solution is to either schedule the entire block all at once, which perhaps imposes a size limit, or to be prepared for the priority inversion. The upshot is that large header blocks will be handled poorly by some implementations (which isn�t really news), and protocols with large header blocks going one way and data going the other way may tend to self-throttle (which sounds like a minor corner case). On 2014�04�22, at 7:49 AM, Roberto Peon <grmocg@gmail.com> wrote: > And by timely delivery, we all mean that the *execution* of priority changes be timely :) > That could happen as a result of a new stream appearing at a higher priority than a previously existing stream, and thus doesn't require a priority frame.
Received on Tuesday, 22 April 2014 03:18:11 UTC