Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Jetty PUSH strategy

Thx, got it.

2013/12/31 Simone Bordet <sbordet@xxxxxxxxxxx>

On Mon, Dec 30, 2013 at 5:20 PM, Ryan Young <ryanyoung.soloy@xxxxxxxxx> wrote:
> I mean at client side we may need to face the case:
> the resource is being pushed, but the data has not yet arrived
> So I wonder how the client deal with this case to avoid sending redundant
> "GET" for resource that is being pushed.

This is more a question for browser implementers, but I'll give you my version.

The client is about to ask for a secondary resource B that may be pushed.
It first checks B in its cache. If present and valid, it uses that
(and possibly discards the push).
Then, it looks at the push cache built for the primary resource. If B
is present and valid, it uses that.
If B is going to be pushed, but not there yet (your case above), it
waits for it. When it is arrived it just renders it on the viewport.
Otherwise it issues a GET (which may also contain if-modified-since
headers, etc.).

There always is a race between what is being pushed and the GET from the client.
The server can optimize that and send the pushed headers before or
concurrently with the data for the primary resource.
Jetty does this, and along with other SPDY improvements, there is a
good chance that the reply and the pushed headers are sent in a single
write, probably even in the same TCP packet.
This reduces the window between the client issuing GETs and the server
pushing resources, since the client will know pretty early that pushed
data will arrive, and can avoid to GET it.

SPDY push is not a fool proof mechanism to push resources; however, in
most cases provides a sensible perceived improvement in page
"rendering", from our experience.

Simone Bordet
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.
jetty-users mailing list

Back to the top