<div dir="ltr">Hi,<div><br></div><div style>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:</div>
<div style><div>@@ -1662,7 +1662,7 @@ ngx_http_spdy_send_settings(ngx_http_spdy_connection_t *sc)</div><div> </div><div>     buf->last = p;</div><div> </div><div>-    ngx_http_spdy_queue_frame(sc, frame);</div><div>+    ngx_http_spdy_queue_blocked_frame(sc, frame);</div>
<div> </div><div>     return NGX_OK;</div><div> }</div><div><br></div><div style>BR/ Yury</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/6 Yury Kirpichev <span dir="ltr"><<a href="mailto:ykirpichev@gmail.com" target="_blank">ykirpichev@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Yes, we did such modification in our test environment and it is working well so far.<br>Moreover, it showed good results in case of intermixed requests with low and high priority are handled.<br>
</div>
<br></div>BR/ Yury<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/7/5 Valentin V. Bartenev <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span><div>
<div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wednesday 26 June 2013 12:34:17 Yury Kirpichev wrote:<br>
> Hello,<br>
><br>
> Thanks for analysis and explanation.<br>
> Then how about the following workaround -<br>
> - queue blocked frames at the begining of queue in FIFO order.<br>
> (just remove from ngx_http_spdy_queue_blocked_frame the code:<br>
>  if (frame->priority >= (*out)->priority) {<br>
>             break;<br>
>         }<br>
> )<br>
><br>
> - queue non-blocked frames after blocked in priority order:<br>
> static ngx_inline void<br>
> ngx_http_spdy_queue_frame(ngx_http_spdy_connection_t *sc,<br>
>     ngx_http_spdy_out_frame_t *frame)<br>
> {<br>
>     ngx_http_spdy_out_frame_t  **out;<br>
><br>
</div>>     for (out = &sc->last_out; *out *&& !(*out)->blocked*; out =<br>
<div>> &(*out)->next)<br>
>     {<br>
>         if (frame->priority >= (*out)->priority) {<br>
>             break;<br>
>         }<br>
>     }<br>
><br>
>     frame->next = *out;<br>
>     *out = frame;<br>
> }<br>
><br>
> Do you foresee any obvious drawback of such approach?<br>
><br>
</div>[..]<br>
<br>
At first glance I don't.  Indeed it can be a better strategy, particularly<br>
since the SYN_STREAM frames are usually small.<br>
<br>
Have you tested it already?<br>
<div><div><br>
  wbr, Valentin V. Bartenev<br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</div></div></blockquote></div></div></div><br></div>
</blockquote></div><br></div></div>