SPDY: what is the purpose of blocked frame

[Yury Kirpichev]

Hello,

Thanks for analysis and explanation.
Then how about the following workaround -
- queue blocked frames at the begining of queue in FIFO order.
(just remove from ngx_http_spdy_queue_blocked_frame the code:
 if (frame->priority >= (*out)->priority) {
            break;
        }
)

- queue non-blocked frames after blocked in priority order:
static ngx_inline void
ngx_http_spdy_queue_frame(ngx_http_spdy_connection_t *sc,
    ngx_http_spdy_out_frame_t *frame)
{
    ngx_http_spdy_out_frame_t  **out;

    for (out = &sc->last_out; *out *&& !(*out)->blocked*; out =
&(*out)->next)
    {
        if (frame->priority >= (*out)->priority) {
            break;
        }
    }

    frame->next = *out;
    *out = frame;
}

Do you foresee any obvious drawback of such approach?

BR/ Yury


2013/6/25 Valentin V. Bartenev <vbart at nginx.com>

> On Tuesday 25 June 2013 12:51:17 Yury Kirpichev wrote:
> > Hi Nginx Developers,
> >
> >
> > Could someone explain what is the purpose to use blocked frame for
> > SYN_REPLY frame in spdy implementation?
> >
> > According to our investigation it makes it impossible to use spdy
> > priorities because of blocked frames (since each stream is started with
> > SYN_REPLY which is blocked there is no way how frames from subsequent
> > requests can outrun previous request with lower priority in spdy output
> > queue).
> >
> [...]
>
> SPDY uses zlib compression for output headers in SYN_REPLY frames.
> In fact zlib is just a wrapper over deflate compression that consists
> of LZ77 and Huffman coding.
>
> Both client and server must keep LZ77 window in sync between each
> other across a whole SPDY session, so the order of SYN_REPLY frames
> cannot be changed after the compression has done.
>
> There is a way to improve things a bit.  We may postpone compression
> to the latest phase (right before sending of queue), but it requires
> more code and we have no ETA for this yet.
>
>   wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20130626/0504d7d2/attachment.html>