<div dir="ltr">Hello,<div><br></div><div style>Thanks for analysis and explanation.</div><div style>Then how about the following workaround -</div><div style>- queue blocked frames at the begining of queue in FIFO order.</div>
<div style>(just remove from ngx_http_spdy_queue_blocked_frame the code:</div><div style> if (frame->priority >= (*out)->priority) {</div><div> break;</div><div> }</div><div>)</div><div><br></div>
<div style>- queue non-blocked frames after blocked in priority order:</div><div style><div>static ngx_inline void</div><div>ngx_http_spdy_queue_frame(ngx_http_spdy_connection_t *sc,</div><div> ngx_http_spdy_out_frame_t *frame)</div>
<div>{ </div><div> ngx_http_spdy_out_frame_t **out;</div><div> </div><div> for (out = &sc->last_out; *out <b>&& !(*out)->blocked</b>; out = &(*out)->next)</div><div> { </div><div> if (frame->priority >= (*out)->priority) {</div>
<div> break;</div><div> }</div><div> }</div><div> </div><div> frame->next = *out;</div><div> *out = frame;</div><div>} </div></div><div style><br></div><div style>Do you foresee any obvious drawback of such approach?</div>
<div style><br></div><div style>BR/ Yury</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/25 Valentin V. Bartenev <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tuesday 25 June 2013 12:51:17 Yury Kirpichev wrote:<br>
> Hi Nginx Developers,<br>
><br>
><br>
> Could someone explain what is the purpose to use blocked frame for<br>
> SYN_REPLY frame in spdy implementation?<br>
><br>
> According to our investigation it makes it impossible to use spdy<br>
> priorities because of blocked frames (since each stream is started with<br>
> SYN_REPLY which is blocked there is no way how frames from subsequent<br>
> requests can outrun previous request with lower priority in spdy output<br>
> queue).<br>
><br>
</div>[...]<br>
<br>
SPDY uses zlib compression for output headers in SYN_REPLY frames.<br>
In fact zlib is just a wrapper over deflate compression that consists<br>
of LZ77 and Huffman coding.<br>
<br>
Both client and server must keep LZ77 window in sync between each<br>
other across a whole SPDY session, so the order of SYN_REPLY frames<br>
cannot be changed after the compression has done.<br>
<br>
There is a way to improve things a bit. We may postpone compression<br>
to the latest phase (right before sending of queue), but it requires<br>
more code and we have no ETA for this yet.<br>
<br>
wbr, Valentin V. Bartenev<br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">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>
</blockquote></div><br></div>