Re: BLOCKED frame specification

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

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.

-johnny


On Wed, Apr 16, 2014 at 9:19 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 16/04/2014 10:08 p.m., Roberto Peon wrote:
> > Bleh.
> > We have address space in the frame opcodes, lets use that instead of
> adding
> > new semantics to things which are unstructured.
>
> Indeed. Since the editors or WG decided that frames shall not be
> extensible there are opcodes to spare in abundance. Whereas ping codes
> are potentially open to extensions still by other drafts.
>
> > The only bit of information that is needed is when the remote end is not
> > blocked (confirming that it was blocked intentionally/whatever seems
> like a
> > waste). That is enough for tuning and debugging.
>
> Confirming that it is not-blocked could be as simple as sending the next
> frame for the stream in response to the BLOCKED query. Or perhapse an
> empty non-final DATA frame if one wishes.
>
> /2c
>
> Amos
>
>
>