SPDY: what is the purpose of blocked frame

[Yury Kirpichev]

Hi,

We have found one issue with proposed solution. The issue is that now
SETTINGS frame will be send after SYN_REPLY frame. Though, it does not
violate SPDYv2 protocol, it can be easily fixed by changing:
@@ -1662,7 +1662,7 @@
ngx_http_spdy_send_settings(ngx_http_spdy_connection_t *sc)

     buf->last = p;

-    ngx_http_spdy_queue_frame(sc, frame);
+    ngx_http_spdy_queue_blocked_frame(sc, frame);

     return NGX_OK;
 }

BR/ Yury


2013/7/6 Yury Kirpichev <ykirpichev at gmail.com>

> Yes, we did such modification in our test environment and it is working
> well so far.
> Moreover, it showed good results in case of intermixed requests with low
> and high priority are handled.
>
> BR/ Yury
>
>
> 2013/7/5 Valentin V. Bartenev <vbart at nginx.com>
>
> On Wednesday 26 June 2013 12:34:17 Yury Kirpichev wrote:
>> > 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?
>> >
>> [..]
>>
>> At first glance I don't.  Indeed it can be a better strategy, particularly
>> since the SYN_STREAM frames are usually small.
>>
>> Have you tested it already?
>>
>>   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/20130710/1ef3a1b3/attachment.html>