Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Reprioritization of Jetty

Hi,

On Mon, Sep 28, 2015 at 6:19 AM, Muhui Jiang <jiangmuhui@xxxxxxxxx> wrote:
> Hi
>
> The thing I want to do is :
>
> Download a big file from a HTTP/2 server like h2o, using my client(Jetty) to
> send windows_update frame periodically and see whether it can restrict the
> size of returned packet and control the timing. But I find I can do this
> with settings frame. So I am a little bit confused because I thought  this
> is what window_update frame should do.

The size of the DATA frames returned by the server is controlled by
the server buffer size and by the stream window size.
You can control the latter with a SETTINGS frame that sets the initial
stream window size.

The timing can be controlled by the FlowControlStrategy and by calling
succeed() on the content callback (of method
Stream.Listener.onData(Stream, DataFrame, Callback)), which means that
the content bytes have been consumed.
The default FlowControlStrategy (BufferingFlowControlStrategy)
accumulates bytes consumed by the client until a threshold is reached,
and then sends a WINDOW_UPDATE.
There is a simpler FlowControlStrategy (SimpleFlowControlStrategy)
that sends a WINDOW_UPDATE every time the client consumes the content.

Using SimpleFlowControlStrategy and succeeding the DATA frame callback
at the time you want gives you full control on when the WINDOW_UPDATE
frames are sent.

It's still not clear *why* you want to do this; if you want to stream
a large content from the server controlling the rate like YouTube
does, it is better done on the server than on the client.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.


Back to the top