- 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