Re: BLOCKED frame specification

On 2014–04–16, at 9:43 PM, Johnny Graettinger <jgraettinger@chromium.org> wrote:

> I'm not sure what is meant by a BLOCKED "query". This is (and IMO should be) a unidirectional rather than query/response pattern.

Is there really a point to notifying of blockage by default? Every dependent stream is blocked as long as its dependency (or another dependency up the hierarchy) is unblocked. How often does a client need to be reminded which streams remain blocked?

The interesting information is whether something has been unblocked by the expected time. What is to be debugged is avoiding excessive dependencies (on the client side) and correct dependency resolution (on the server side).

> I hesitate to suggest this, as I think Hasan's proposal is strictly better, but an alternative might be to send a single empty DATA frame under the blocked condition. This has the advantage of compatibility with the current spec: receivers must handle empty DATA frames anyway, and can choose to ignore the semantics. However it loses the explicitness of BLOCKED about whether it's stream or session flow control that's the culprit; the receiver would need to make a guess.

An empty DATA frame will simply be coalesced (ignored) by the first intermediary. An empty segment would get through, but segmentation is reserved to the application.

Received on Wednesday, 16 April 2014 14:46:16 UTC