Re: BLOCKED frame specification

<resend from correct address>


On Wed, Apr 16, 2014 at 10:45 AM, David Krauss <potswa@gmail.com> wrote:

>
> 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 think there's a misunderstanding here. Priorities are about the relative
ordering of multiple *ready-to-write* streams. A sender can and certainly
should send a dependent stream frame, if that's what's available.



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

That's fine. Flow control is also hop-by-hop.

cheers,
-johnny