GB2557878A

GB2557878A - Method and device for managing the reception of unrequested resources associated with requested resources

Info

Publication number: GB2557878A
Application number: GB1609576.2A
Authority: GB
Inventors: Bellessort Romain; Fablet Youenn; Ruellan Hervé
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2016-06-01
Filing date: 2016-06-01
Publication date: 2018-07-04
Also published as: GB201609576D0

Abstract

A method for managing the reception of unrequested resources (e.g. web pages) associated with requested resources. The method comprises, at a client device of a client-server system: receiving an unrequested resource associated with a first resource in response to a request for this first resource; analyzing usage of the received unrequested resource associated with the first resource; and determining, based on the result of the analysing, a policy for handling an advertised unrequested resource associated with a second requested resource.

Description

(54) Title of the Invention: Method and device for managing the reception of unrequested resources associated with requested resources

Abstract Title: Managing the reception of unrequested resources associated with requested resources (57) A method for managing the reception of unrequested resources (e.g. web pages) associated with requested resources. The method comprises, at a client device of a client-server system:

receiving an unrequested resource associated with a first resource in response to a request for this first resource; analyzing usage of the received unrequested resource associated with the first resource; and determining, based on the result of the analysing, a policy for handling an advertised unrequested resource associated with a second requested resource.

100

110

120

130

140

Fig. 1

1/6

100

110

120

130

140

Fig. 1

2/6

200

Obtain secondary resources previously sent by considered server

210

Define a set of filtering criteria

220

Select secondary resources matching filtering criteria

No

230

Are there enough selected

240

250

260

Fig. 2

3/6

300

310

320

330

340

Fig. 3

4/6

Fig. 4

5/6

Fig. 5

6/6

Fig. 6

METHOD AND DEVICE FOR MANAGING THE RECEPTION OF UNREQUESTED

RESOURCES ASSOCIATED WITH REQUESTED RESOURCES

FIELD OF THE INVENTION

The present invention relates in general to transmission of data between a server device and a client device in a communication network, and in particular to method and device for managing the reception of unrequested resources associated with requested resources.

BACKGROUND OF THE INVENTION

HTTP (HyperText Transfer Protocol) is an application protocol used on top of the TCP/IP (Transmission Control Protocol / Internet Protocol) allowing data exchanges over the Internet. More specifically, the HTTP protocol allows a client and a server to communicate by exchanging requests and responses. Requests are sent by the client to obtain data (referred to as a resource), while responses are returned by the server with the required data (or resource). HTTP requests and responses are transmitted on a TCP connection between the client and the server.

According to early versions of the HTTP protocol, different TCP connections are established for each pair of (request, response). More recent versions of the HTTP protocol allow reusing a TCP connection to exchange a new pair of (request, response).

In the HTTP/2 version of the HTTP protocol, a single TCP connection is used between the client and the server. All the requests and responses are exchanged on this single connection. Moreover, HTTP/2 allows a full multiplexing of requests and responses.

To allow this multiplexing, HTTP/2 defines the notion of stream, which is a bidirectional channel between the client and the server used to exchange a request and a response. A stream is characterized by its identifier (ID), which is an integer value. For managing streams and for transmitting data over these streams, the client and the server exchange HTTP/2 frames.

Each time a new request is sent by the client, a new stream is created. This request is sent through one or more HTTP/2 frames, each of them comprising the corresponding stream ID. As a result, even though a single TCP connection is established, several HTTP/2 streams can be opened concurrently. Generally, a stream is closed once the response associated with a given request has been received by the client that has sent this request.

The multiplexing allows the client to start sending a part of a first request, a second request and finally to finish the sending of the first request. According to the HTTP/2 version ofthe HTTP protocol, the server is able to respond to requests in any order and to send them by parts, possibly not in order, without need to establish a new TCP connection for each new request and corresponding response.

Web resources such as web pages or streaming contents generally contain links to other data or resources, which themselves may contain links to other data. To fully load a web resource, all the linked and sub-linked data generally need to be retrieved. This incremental discovery may lead to a slow loading of the web resource, in particular on high latency networks such as mobile networks.

For the sake of illustration, these web resources can be HTML (HyperText Markup Language) resources (structuring the content of the page), CSS (Cascading Style Sheets) resources (describing the layout and the style of the content), JavaScript resources (providing dynamic behaviour for the page), image resources and other media or font resources.

In order to optimize the transfer of data between the server and the client, HTTP/2 makes it possible for the server to push data that have not been requested by the client. Pushing a resource is useful in that it makes it possible for the client device to obtain the different resources it needs more quickly.

Thus, when receiving a request for a given web resource, hereafter called primary resource, the server may send it and also push unrequested data (unsolicited data) that are linked to the requested resource, hereafter called pushed resource or secondary resource. The load time of the web resource is thus reduced.

In general terms, pushing a secondary resource is useful as it enables the client to obtain more quickly the different resources it needs, typically to render a web page. The HTTP/2 push feature thus makes it possible to increase the responsiveness of the server from the client standpoint since the server sends resources to the client without waiting for the client to request them.

In order to push a resource to the client, the server must first send a

PUSH_PROMISE frame, which indicates (or advertises) which secondary resource the server intends to push. Once the PUSH_PROMISE frame for a secondary resource has been sent, the server may create a new stream in order to transmit it. The client may also reject the pushed resource, for instance by closing the server-initiated stream used to transmit the pushed resource.

PUSH_PROMISE frames can only be sent on streams that have been initiated by clients. For instance, when the client requests a primary resource example.html, the request is sent through a client-initiated stream. Consequently, if the server considers that pushing the secondary resources example.js, example.css and example.jpeg would be advantageous for the client, typically because these resources are referred to in the primary resource example.html and because the client will obtain them faster if they are pushed than if it had to request them after parsing the primary resource example.html, the server will use said client-initiated stream to send one PUSH_PROMISE frame for each of those three secondary resources.

In general terms, the push feature is somehow difficult to implement and the sending of pushed resources occupies the bandwidth.

For instance, depending on the client considered, some of the pushed resources are already available to the client (in its cache memory), or not useful. This is because the server may push several times the same data. This implies an inadequate management of the bandwidth available for streaming the data. Given that the server must handle thousands to millions of clients, storing the list of available data in the cache memory of all clients is not a realistic approach.

Also, the needs or implementation may be different for two clients requiring the same primary resource. For instance, two clients may require different resolution of images or videos. Hence, the server has to determine which secondary resources should be pushed when a primary resource is requested by the client, given that the list of secondary resources may be different than for another client requesting the same primary resource. This is an important issue for clients and servers compliant with HTTP/2 that do not understand dedicated HTTP headers allowing exchanging information relating to push.

Consequently, there is a need for improving the management of pushed resources, in particular at the client, so that the client is less vulnerable to servers pushing data very aggressively, even if not useful for the considered client, and so that the bandwidth can be optimized.

SUMMARY OF THE INVENTION

The present invention has been devised to address one or more of the foregoing concerns.

In this context, there is provided a solution for a client to determine how to handle a pushed resource based on the resources previously pushed by the same server.

According to a first aspect of the invention, there is provided a method for managing the reception of unrequested resources associated with requested resources. The method comprises, at a client device of a client-server system:

receiving an unrequested resource associated with a first resource in response to a request for this first resource;

analyzing usage of the received unrequested resource associated with the first resource; and determining, based on the result of the analyzing, a policy for handling an advertised unrequested resource associated with a second requested resource.

Therefore, the method of the invention makes it possible to optimize the use of the bandwidth between the server and the client and to improve the handling by the client, of pushed resources (unrequested resources) that are advertised by the server.

Consequently, the client is less vulnerable to a server pushing data very aggressively, even if not useful for it. Also, the client is not dependent on server as regards to the handling of pushed resources because it does not have to send a specific header value that has to be understood by the server.

Thanks to the claimed method, there is no need for a solution ensuring interoperability between clients and servers regarding the pushing of resources. This is because any client may take advantage of the proposed solution. On the other hand, the proposed solution would be compatible with such solution, as well as with a proprietary solution.

As will be shown in the following description, the usage of already pushed resources may be analyzed based on a large variety of criteria so that the result of this analyzing may be useful for different purposes, such as building the set of resources, as well as analyzing this set of resources, or modifying settings of the stream used to receive a considered pushed resource.

Optional features of the invention are further defined in the dependent appended claims.

According to embodiments, the second requested resource is the first requested resource.

According to embodiments, the method also comprises receiving the first resource.

According to embodiments, a plurality of unrequested resources associated with at least one requested first resource are received and the analyzing step is performed for at least part of this plurality of received unrequested resources.

According to embodiments, the analyzing step comprises selecting a subset of unrequested resources from among all the received unrequested resources of the plurality, according to at least one filtering criterion, and analyzing usage is performed only for the unrequested resources of the subset.

A decision based on the selected subset is even more relevant than a decision based on all the unrequested resources received from a considered server.

According to embodiments, the at least one filtering criterion depends on previous exchanges with the server from which is the advertised unrequested resource.

According to embodiments, the at least one filtering criterion is at least one of the following criteria:

the type of the unrequested resource or of the first resource associated with the unrequested resource;

the size of the unrequested resource or of the first resource associated with the unrequested resource;

the server from which is the unrequested resource or the first resource associated with the unrequested resource;

a header associated with the unrequested resource or with the first resource associated with the unrequested resource;

parameters associated with the unrequested resource or with the first resource associated with the unrequested resource;

the application of the client requiring the first resource or the different contexts handled by the application;

the relevancy of the unrequested resource or of the first resource associated with the unrequested resource with regard to the advertised unrequested resource and the associated first resource.

According to embodiments, a number of points is set for each fulfilled filtering criterion according to the advertised unrequested resource, and an unrequested resource is selected only if the sum of the corresponding points reaches a predetermined threshold.

Advantageously, each criterion may be given more or less importance.

According to embodiments, the analyzing step comprises defining a table associating a set of filtering criteria with each category of unrequested resource, a given category being defined based on at least one of: resource type, resource size, associated HTTP header, associated application of the client or associated context.

According to embodiments, the analyzing step comprises computing the value of at least one parameter among the following parameters for the unrequested resources of the subset:

the number of unrequested resources in the subset;

the mean number of access to the unrequested resources of the subset;

the mean elapsed time between the receiving of the unrequested resource of the subset and the first time of access of this unrequested resource by an application of the client;

the ratio between the number of unrequested resources of the subset that have been accessed by an application of the client and the total number of unrequested resources in the subset;

the ratio between the size of the unrequested resources of the subset that have been accessed by an application of the client and the size of all the unrequested resources of the subset.

According to embodiments, the analyzing step also comprises computing the ratio between the number of advertised unrequested resources that have been rejected according to the current handling policy and that have not been requested by an application of the client and the total number of rejected advertised unrequested resources.

According to embodiments, the determining step is based on parameter values computed during the analyzing step.

According to embodiments, determining the handling policy comprises defining at least one action to be performed by the client for the advertised unrequested resource among the following actions: rejecting the advertised unrequested resource, modifying the flow control of the corresponding stream, modifying the priority of the corresponding stream.

According to embodiments, the method also comprises determining the handling policy comprises defining at least one of these actions to be performed by the client: using a specific header when requesting a resource, indicating to the server from which is the advertised unrequested resource that unrequested resources are no longer accepted.

According to embodiments, when at least one triggering criterion is met, the steps of analyzing or determining are performed again.

According to embodiments, the triggering criterion is an amount of time elapsed since the last analyzing step or the last determining step.

Thus, all the advertisements for pushing resources associated with the requested resource can be received before this amount of time has elapsed.

According to embodiments, the triggering criterion is the receiving of a predetermined number of unrequested resources from a considered server of the client-server system.

According to embodiments, the method also comprises, when the at least one triggering criterion is met, waiting for a predetermined amount of time before performing again the steps of analyzing or determining.

According to a second aspect of the invention, there is provided a client device for managing the reception of unrequested resources associated with requested resources. The device is configured for:

According to a third aspect of the invention, there is provided a proxy device comprising a client device as aforementioned.

According to a fourth aspect of the invention, there is provided an end-user device comprising a client device as aforementioned.

The second, third and fourth aspects of the present invention have optional features and advantages similar to the first aspect above-mentioned.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium, and in particular a suitable tangible carrier medium or suitable transient carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

The invention also concerns a method substantially as hereinbefore described with reference to, and as shown in Figures 1 to 5, and a client device substantially as hereinbefore described with reference to, and as shown in Figure 6.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure 1 is a flowchart illustrating steps of a method for managing the reception of unrequested resources associated with requested resources according to embodiments;

Figure 2 is a flowchart illustrating steps for analyzing usage of received unrequested resources in the method of Figure 1;

Figure 3 is a flowchart illustrating steps for determining a handling policy in the method of Figure 1;

Figures 4 and 5 are flowcharts illustrating two exemplary handling policies according to embodiments; and

Figure 6 represents a block diagram of a client device, in which steps of one or more embodiments may be implemented.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

It is proposed that a client determines how to handle an advertised pushed resource based on the resources previously pushed, for instance by the same server.

In the following description, a pushed resource is equally well referred to as unrequested resource or secondary resource, and it is linked to a resource that is requested by the client. The resource requested by the client may be referred to as a primary resource.

According to general embodiments, the client performs an analysis of at least one previously pushed resource, for instance by computing the value of parameters such as the mean time of first access to the resource(s) by an application of the client, or the mean number of accesses to the resource by an application of the client.

In preferred embodiments, several unrequested resources associated with one or more requested resources are available in memory or there is at least some information about their (possibly former) presence available in memory and during the analysing step, the usage of at least part of them is analysed.

In some embodiments, the client may select a subset of previously pushed resources according to filtering criteria such as the type or size of the pushed resource (compared to the type or size of the advertised resource for instance), and perform the analysis only on the pushed resources of this subset.

According to general embodiments, the client determines how to handle the secondary resources advertised by the server, based on the result of the analysis of previously pushed resources. In other words, a handling policy is determined based on parameters representative of the usage of previously pushed resources.

For instance, if it appears that the server generally pushes data that are not useful, the client may close the corresponding stream. If the server does not push only data that are not useful, the client will adapt its rejection ratio to the level of “usefulness” of the pushed resources. According to a variant, based on this level of “usefulness”, it may also modify the flow control of the stream, or its priority.

Thanks to the invention, the client can optimize its handling of pushed resources and is not vulnerable to a server pushing data very aggressively, even if not useful for the client.

Figure 1 shows steps of a method for managing the reception of unrequested resources associated with requested resources according to embodiments. The process is implemented for example at a client device of a clientserver system.

According to a general principle of the invention, the method for managing the reception of unrequested resources associated with requested resources, starts after a first exchange of request/response for obtaining a first resource has already been performed between the client and the server, such that there is/are already existing one or more pushed resources (secondary resources), typically stored in a (cache) memory of the client.

According to a variant, some pushed resources may no longer be in the cache memory of the client, but there is still at least some information about their former presence available in memory. For instance, this may be a history recording useful data about resources that have been stored (and also about resources that are currently stored), in the memory.

To these purposes, the client sends a request for at least one primary resource (first resource) from the server. This primary resource is typically asked by an application of the client, for instance a web application.

In response to this request, the client receives unrequested data associated with the first requested resource. These unrequested data corresponds to at least one secondary resource that is pushed by the server on its own initiative.

According to embodiments, the usage of at least part of these unrequested resources will be analysed by the client in order to determine an adapted handling policy for unrequested resources that will be advertised by the server, for instance in response to another request for another resource or for the same first resource.

In the given example, a primary resource is requested (second requested resource) at step 100 by the client to a server. This request is generated according to a protocol such as HTTP/2 which allows the server, in response to the request, to advertise (or announce) that it intends to send secondary resources relating to the requested primary resource, even though the client has not requested them. In other words, the secondary resources are unrequested data.

At step 110, such advertisement is obtained by said client from said server for a given secondary resource.

An analysis of the usage of at least some of the secondary resources previously pushed by said server is then performed during step 120. The analyzing step comprises computing the value of at least one parameter representative of the usage of already received unrequested resources. It may also comprise an evaluation of the reject decisions made for the previously advertised unrequested resources. The analyzing step is further described with reference to Figure 2.

In a particular embodiment, the analyzing step is performed on only a part of the pushed resources available in the cache memory of the client, preferably the most relevant part of these resources according to at least one filtering criterion. To that end, a subset of unrequested resources may be selected from among all the received unrequested resources associated with the first resource, according to this or these filtering criteria, and the analyzing step is performed only for the unrequested resources of the subset.

According to a variant, the analysis may be performed on all the pushed resources available in the cache memory of the client.

At step 130, the secondary resources advertised at step 110 are handled by the client, according to a handling policy determined based on the result of the analysis performed at step 120. For instance, determining the handling policy may comprise defining at least one action to be performed by the client for the advertised unrequested resource among the following actions: rejecting the advertised unrequested resource, modifying the flow control of the corresponding stream, modifying the priority of the corresponding stream.

It may also be another kind of actions such as using a specific header when requesting a resource, or indicating to the server that pushed resources are no longer accepted. An example of handling is further described with reference to Figure 3.

In a particular embodiment, the handling policy may also affect other secondary resources in addition to those advertised at step 110, for instance secondary resources that were previously advertised. As another example, secondary resources that will be advertised in the future may be concerned by the handling policy determined based on the analysis result. Such a case is described with reference to Figures 4 and 5.

After this, the process ends at step 140.

In embodiments, steps 120 and 130 are not performed just after steps 100 and 110.

For instance, the analysis step 120 is performed when the client does not have any request/response to handle. This is advantageous since it makes it possible to avoid a request/response handling slowdown. In this case, for example after a first run of steps 100 to 130 in the order above-described or after receiving a first pushed resource, steps 100, 110 and 130 may be run consecutively based on the analysis step 120 previously performed. In this way, the parameters required to determine how to handle a given secondary resource (i.e. the handling policy for this secondary resource) can be defined in advance. Such parameters may typically be obtained for all the servers with which a connection is currently established. This is because analysis parameters generally depend on the considered server.

According to a particular implementation, step 130 may be performed periodically, and not just after the receiving step 110. For instance, step 130 may be performed every 5 seconds.

According to some embodiments, when at least one triggering criterion is fulfilled, the steps of analyzing or determining are performed again.

For instance, the triggering criterion is an amount of time elapsed since the last analyzing step (or the last determining step). It may correspond to a multiple (preferably small) of the Round Trip Time (RTT) of the considered connection between the client and the considered server.

Advantageously, the secondary resources advertisements for the requested primary resource have more chances to be received before this amount of time has elapsed. Hence, a step 120 and/or 130 will be performed once for each new primary resource request.

The amount of time may be set at 60 seconds or several minutes, especially if the processing of steps 120 and/or 130 is expensive for the considered client.

In another example, the triggering criterion is the receiving of a predetermined number of advertisements for unrequested resources (secondary resources) from the considered server. In this case, steps 120 and/or 130 are performed only when this number has been reached. For example, the predetermined number may be equal to 1.

In another example, the triggering criterion is an amount of time elapsed since the receiving of a predetermined number of unrequested resources from the considered server. For instance, a timer of 5 seconds may be started when the predetermined number of secondary resources is reached. Advantageously, the secondary resources advertisements for the requested primary resource have more chances to be received before this amount of time has elapsed.

According to an example, when the triggering criterion is met, the client waits for a predetermined amount of time before performing again the steps of analyzing or determining.

A combination of these different criteria can be considered. In this case, it may be needed to meet all the criteria of the combination in order to perform again steps 120 and/or 130. Alternatively, as soon as one criterion of the combination is met, steps 120 and/or 130 are performed again.

For the sake of illustration, it is considered a web application executed by a web browser installed on a client device, requests a video (first resource). A server pushes the four first segments (unrequested resources) of the requested video in low resolution. However, the web application would like to display the high resolution version of the video. The client library has no indication that the pushed resource is not HD, so it assumes that server pushed a useful resource. Yet, after a short amount of time, it appears that pushed segments have not been accessed by the web application: this may mean that the server pushed data that are not useful.

When a second video is later requested (second resource) by the same web application to the same server, it pushes the first segment of the video. The client analyses the usage of segments previously pushed by the server. It may for example observe that none of them has been accessed by the application. This is a very low ratio (0%), but only a small number of pushed resources are considered. Therefore, since the sample is limited in size, the client cannot really conclude that the server pushes only data that are not useful. This is because the server may simply have made a bad decision. Hence, in this context, the client may decide that 50% of pushed resources from this server may be rejected (handling policy).

This is just an example and many other different handling policies may be adopted, as shown in the following description. In particular, handling policies do not necessarily involve rejecting pushed resources. Instead, other actions may be performed, such as modifying a priority of a stream, modifying the flow control associated with a given stream, or determining that a specific frame has to be sent to the server to indicate that client no longer accepts the pushing of resources from this server.

Back to the illustrative example, if the server pushes high quality segments, the client will use them and this will benefit the user as the video in high quality will be displayed more quickly. In this case, the ratio of useful pushed resources will grow, and the client will continue to accept more pushed resources from this server. On the other hand, if the server still pushes low quality segments, the client will not use them and the bandwidth is thus wasted. Therefore, in this case, the ratio of useful pushed resources will remain at 0%, and since the size of the sample has grown, the probability of rejecting the next pushed resources will increase.

Figure 2 illustrates steps that can be performed during the analyzing step 120 of Figure 1, according to embodiments. During this analysis, parameters representative of the usage of at least some of the secondary resources already pushed by the server in response to a first request for a first resource are computed. They are needed to determine how to handle a secondary resource.

First, at step 200, secondary resources (unrequested resources) previously sent by the considered server are obtained. In practice, they may be retrieved from the cache memory of the client.

At optional step 210, a set of at least one filtering criterion is defined in order to select a subset of the available pushed resources to be analyzed. The subset comprises the most relevant part of the pushed resources according to the at least one filtering criterion thus defined.

For instance, a filtering criterion may be:

the type of the unrequested resource or of the resource associated with the unrequested resource;

the size of the unrequested resource or of the resource associated with the unrequested resource;

- a header associated with the unrequested resource or with the resource associated with the unrequested resource;

parameters associated with the unrequested resource or with the resource associated with the unrequested resource (e.g. the resolution of data or properties of the transfer protocol used for transferring the resource, for instance the priority of the stream);

the application of the client requiring the resource or the different contexts handled by the application;

the relevancy of the unrequested resource or of the resource associated with the unrequested resource with regard to the advertised unrequested resource and the associated first resource.

When the type of data is considered, it may allow the selection of pushed resources of same type or similar types.

For instance, it may be defined that if the advertised secondary resources are images of a given type, for instance only JPEG images or both JPEG and PNG images, only pushed resources corresponding to images of the same type may be selected. As another example, if the advertised resource is a video, both the resource type and the resource size may be considered as filtering criteria to select only video resources that have a relatively similar size (e.g. 20% larger or smaller).

In practice, a table associating a set of filtering criteria with each category (such as data type, data size, associated HTTP header, associated application of the client or associated context of unrequested resource) may be defined for these purposes. Hence, in this table, a category may be defined using one or more parameters such as the data type, the data size, the associated HTTP header, the associated application of the client or again the associated context of the unrequested resource.

When the size of data is considered, it may allow the selection of pushed resources with a similar size, for instance pushed resources of more or less 20% of the reference size.

When the HTTP header or HTTP/2 parameter is considered, it may allow the selection of pushed resources associated with a given HTTP/2 priority value.

It is recalled that in the HTTP/2 version of the HTTP protocol, one single TCP connection is used for multiple message exchanges. Each message exchange is performed on a stream belonging to the TCP connection. For an optimal usage of the TCP connection, given that the streams have different properties, a client may need the data be conveyed by a specific stream rather than other streams. To allow the client to express how it would prefer the server to handle the different streams, the HTTP/2 specification provides a priority mechanism. By setting priorities for each stream, the client is able to build a weighted tree organizing all the streams. The server may start processing the streams at the root of the tree, sharing its resources between the branches according to the weights of the branches.

Other properties of pushed resources may be used for selecting the subset of pushed resources to be analyzed, for instance the image size or the video resolution. The properties considered may be known from the pushed resource itself or from an associated HTTP header.

For the sake of illustration, it is assumed that the client is a library used by an application (e.g. a HTTP/2 library). The filtering criterion used for selecting a resource may be that it has to have been accessed at least once by the application This criterion allows the selection of only the resources associated with a given application. This may be particularly useful in the case where different applications have different access rights to data.

In some embodiments, a given application, for instance a web browser, is able to distinguish different contexts, for instance different tabs. In this case, a filtering criterion may take into account such contexts. For instance, the filtering criterion may be such that if a resource has been accessed by several tabs (or at least one tab or all the tabs) of the same web browser, it will be selected. This criterion allows the selection of only the resources associated with a given context of a given application. This may be particularly useful in the case where different contexts of a given application have different access rights to data.

In general terms, a filtering criterion allows the selection of a secondary resource based on the relevancy of secondary resources (pushed resources) or primary resources (requested resources). A circumstance that may lead to considering a resource as irrelevant is when a change of usage is observed.

For the sake of illustration, if an application of the client uses a HTTP/2 library, this application may make a first request for a primary resource, but soon after, for instance because of a specific user input, makes a second request for another primary resource, making secondary resources pushed with regard to the first primary resource not useful. This may for instance be the case for a media player application: user starts a video (i.e. application requests a first primary resource), but then quickly moves to the end of said video (i.e. application requests a second primary resource).

In such cases, when the first primary resource is requested (first part of the video), the corresponding server may try to push next parts of the video as secondary resources. However, since user has moved to the end of the video, such secondary resources will not be accessed by the application.

This shows that secondary resources that are not useful are not necessarily the result of a bad decision from the server. For instance, in the example above, they are due to the fact that the server could not anticipate that the user would move to another part of the video or to another video. The same kind of situation may occur with a web browser: inside a given tab, the user may load a first website and then quickly move to another one, for instance because the user initially did not select the right web site in a list of suggested web sites.

A possible means for allowing the client to determine whether resources are relevant comprises enabling applications to indicate their currently used context. This may for instance be achieved by having the application to provide an identifier for said context. Such identifier may be provided through a specific interface dedicated to indicating the current context, or as a parameter of another interface, e.g. an interface allowing the request of a resource.

Hence, if the application requests a first resource and then a second one shortly after, it can indicate whether the second request has been performed in the same context as the first one. If so, it means that the second request somehow replaces the first one (e.g. user has moved to a different part of the video), hence the firstly requested resource and corresponding secondary resources are probably not relevant.

On the other hand, if a different context identifier is used for the second request, it means that the application has currently two contexts in parallel, i.e. both the first and the second requested resources are of interest for the application. In this case, both resources are relevant, as well as the associated secondary resources that may be pushed by the server.

For the sake of illustration, a web browser relying on an HTTP/2 client is considered. The web browser may for instance distinguish one context per browsing context (e.g. a tab). Thus, if the user moves to a different URL in a given tab, the same context will be used. Since the user has loaded another primary resource, the secondary resources that may have been pushed with regard to the previous primary resource are unlikely to be useful.

In addition, in some cases, the web browser may decide to define a new context for a new tab if it appears useful to obtain the secondary resources associated with the previous primary resource. This may typically be the case if the new URL belongs to the same domain as the previous one and that both are HTML documents: as a matter of fact, the secondary resources (such as images, scripts or style sheets) may still be useful when loading another HTML resource from the same domain.

Considering the contexts of an application of the client as a filtering criterion may also be interesting, notably when different users with different access rights use the same application on the same device. In particular, a device used as a proxy may take advantage of this model since it makes it possible to consider distinctly several connections to the same server originating from different devices.

A filtering criterion may also be defined based on other filtering criteria: for instance, a number of points may be allocated to (or set for) each of the previously mentioned criteria, and a resource may be selected only if the sum of corresponding points reaches a given threshold. By associating different numbers of points to different criteria, each criterion may be given more or less importance.

The number of points may depend on the value of the considered criterion. For instance, if an advertised unrequested resource has a given size, the number of points granted to a previously received unrequested resource may be function of the difference between the size of the advertised unrequested resource and the size of the previously received unrequested resource.

At optional step 220, the pushed resources that match the filtering criteria are selected. In practice, each filtering criterion may be given a status indicating if it is compulsory to meet this criterion to be selected or if it is sufficient to meet this criterion to be selected.

For instance, it may be decided that each criterion of the set must be met by a given secondary resource to be selected. In such a case, the status of each criterion is “required” (i.e. compulsory). According to a variant, it may be decided that meeting at least one criterion from the set is enough to be selected: in such a case, the status of each criterion is “sufficient”. Accordingly, in a given set, each criterion may have a status “required” or “sufficient”. When a secondary resource meets one of the sufficient criteria or all the required criteria, it is selected.

At step 230, it is tested whether or not the number of selected resources is sufficient. If not, i.e. when the number of selected resources is too small or even equal to zero, the selection process of steps 210 and 220 is performed again. During the new step 210, a broader set of criteria may be considered. For instance, instead of considering secondary resources with exactly the same type and a 20% larger/smaller size, a broader set of types may be considered, and the size may be 50% larger/smaller. The new step 220 is performed with this newly defined set of criteria.

According to a variant (not shown), when the number of selected resource is not sufficient, all the secondary resources may be selected instead of a subset only.

According to another variant (not shown), when at step 230, the number of selected resources is not sufficient, the analysis process (step 120) ends and the handling of advertised secondary resources at step 130 of figure 1 is performed according to a default policy. For instance, this default policy may consist of accepting all the advertised secondary resources pushed by the server.

Back to the given example, the interest of the filtering process of steps 210, 220 and 230 is to select secondary resources that are similar to one or more advertised resources in order to build a significant/relevant sample. This is because a sample of already received resources which are similar to at least one advertised secondary resource or which have been received in a similar context, makes it possible to analyze whether or not the receiving of such secondary resources have proven useful. A handling policy determined as described below which is based on the subset (sample) is expected to be more relevant and efficient than a handling policy determined based on all the secondary resources received from considered server.

In some cases, it may happen that secondary resources received from different servers may be considered during the analysis step. For instance, it may be the case when a same entity uses several servers with different names but relying on the same logic for determining which resources to push. Thus, in this case, resources pushed by these servers may all be considered (e.g. example.org and example.com, or serverl.example.com and server2.example.com).

However, as mentioned, the process of steps 210, 220 and 230 is optional. Hence, in some embodiments, the analysis step is performed on all the pushed resources obtained at step 200.

At step 240, it is determined which parameters have to be computed. These parameters depend on the policy currently used for handling secondary resources. More details on the handling policy are given with reference to Figures 3, 4 and 5. It may happen that a given client uses different parameters for different servers. It may also happen that different parameters may be used for a given server at different times.

One or more parameters representative of the usage of already received unrequested resources (secondary resources) may be computed. For instance, the following parameters may be considered:

the number of unrequested resources in the subset;

the mean number of access to the unrequested resources of the subset;

Other types of parameters may be considered. For instance, an evaluation of the reject decisions made for the previously advertised unrequested resources may be useful. Hence, the parameter may be the ratio between the number of advertised unrequested resources that have been rejected according to the current handling policy and that have not been requested by an application of the client and the total number of rejected advertised unrequested resources. As described with reference to Figure 4, this parameter may be very useful for determining an appropriate handling policy as regard to the unrequested resources pushed by a considered server. For instance, if this ratio is especially high, the client should probably accept more of the advertised secondary resources.

Once the parameters to be computed are determined, they are computed at step 250.

For instance, the ratio of advertised unrequested resources that have been rejected according to the current handling policy and that have not been requested by an application of the client may be computed thanks to a list of advertised secondary resources rejected by the client (i.e. a history of rejections). For each item of the list, the client records whether or not it has been requested by an application. Then, a ratio of appropriate decisions can be computed.

As another example, the ratio of the size of the unrequested resources that have been accessed by an application of the client may be computed as the ratio between the size of accessed secondary resources and the size of all considered secondary resources.

The process ends at step 260.

Figure 3 illustrates steps that can be performed for determining how to handle a secondary resource at step 130 of Figure 1, according to embodiments. These steps are typically performed once an analysis (step 120) has been performed, for instance according to the process described with reference to Figure 2.

First, at step 300, an advertised secondary resource is obtained. In this example, it is assumed that the receiving of this secondary resource has not been completed yet.

Next, at step 310, the policy for handling advertised secondary resources (unrequested resources) is determined This step comprises defining at least one action to be performed by the client for the advertised unrequested resource depending on the value of some parameters (as computed at step 250 in Figure 2).

For instance, this action may be one of:

rejecting the advertised unrequested resource, modifying the flow control of the corresponding stream, modifying the priority of the corresponding stream.

Other kinds of actions to be performed by the client may be defined, for instance using a specific header when requesting a resource or indicating to the server that unrequested resources are no longer accepted.

Thus, a handling policy is defined as a set of (threshold, action) pairs so that when the value of a considered parameter reaches a given threshold, the associated action is performed. More specific examples are described with reference to

Figures 4 and 5.

The thresholds may be ordered and tested successively (as shown in Figures 4 and 5). A single threshold may involve more than one parameter, and an action may comprise multiple sub-actions. The corresponding parameters values are obtained as a result of the analysis process of Figure 2.

At step 320, it is determined one of the thresholds of the pairs defined at step 310 that is met by the result of the analysis step 120, i.e. the parameters computed during the process of Figure 2. Examples of implementation of this step are described in more details with reference to Figures 4 and 5.

At step 330, the action associated with the threshold determined at step 320 is performed.

For instance, in the case of HTTP/2, the flow control for corresponding stream or the priority of corresponding stream may be modified. It is recalled that HTTP/2 enables the client and the server to define the amount of data that may be sent on each stream, as well as the amount of data that may globally be sent on the connection. This is called flow control.

Flow control is performed by defining a window size. In general terms, this window size is defined by a receiving node (client or server) and determines the amount of data that may be received from a sending node. If this amount of data has been reached, no more data can be received by the receiving node until it sends a WINDOW_UPDATE frame that increments the amount of data that can be received. Typically, such a frame is sent once part of the already received data has been processed. A WINDOW_UPDATE frame comprises an identifier:

if greater than 0, the size increment indicates the stream associated with said identifier;

- if equal to 0, the size increment targets the global connection window.

The increment size value may be between 1 and 2^Λ31 - 1.

The process ends at step 340.

Even if the receiving of considered secondary resource has not started, it may be possible to perform the determined action at step 330. For the sake of illustration, HTTP/2 defines that a secondary resource is advertised along with the identifier of the stream that will be used by the server to send said secondary resource. Even if the receiving has not yet started, the client may send a frame to server, this frame being associated with the stream identifier and indicating that the stream has to be closed.

In addition, an action may also be performed with future resources that will be requested in the future or advertised in the future, as well as for connections that will be established. For instance, it may be decided that next connection to a server will be started with parameters that prevent usage of push feature by the server.

As another example, it may be decided that no other pushed resource is accepted. This may be achieved by sending a SETTINGS frame with the parameter SETTINGS_ENABLE_PUSH set to 0 or by adding a specific header with a corresponding value to each future request for a primary resource. For instance, a header named expects-push with the value “no” may be used to indicate that client does not expect server to push resources.

More generally, if a specific header can be used by the client to indicate to the server how it expects the server to push resources (e.g. push only specific resources, push only headers associated with a resource, push only the beginning of a resource), determining that this header has to be used with a future request (and how, i.e. with corresponding value or values) may be an action determined at step 320 and executed at step 330.

Figures 4 and 5 illustrate two exemplary handling policies that may be obtained at step 310 and used during steps 320 and 330 in Figure 3.

In the example of Figure 4, the different ways of handling a secondary resource only involve the probability of rejecting a secondary resource (i.e. of preventing their sending by server). According to this policy, secondary resources from the server are rejected if it appears that the server pushes only secondary resources that are not useful. The more not useful previously received secondary resources are, the more likely to reject an advertised secondary resource it is.

In this example, the considered parameters are the mean number of access per selected secondary resource (denoted MAN) and the number of selected secondary resources (denoted SRN) computed during the analysis step (120) for instance according to the process of Figure 2.

The MAN may correspond to different mathematical means, such as arithmetic or geometric means. The algorithm described below may also be applied with other parameters similar to MAN. For instance, instead of MAN, the ratio of the number of accessed resources by the number of pushed resources may be used.

These parameters, which have been computed during the analysis process

120, for instance according to the process of Figure 2, are obtained at step 400. Next, as described with regard to steps 320 and 330, the action corresponding to the met threshold is performed with the considered secondary resource.

At step 410, it is checked whether the MAN is greater than 0.8 or if the SRN is lower than 5. If the response is yes, it may mean that the server has generally pushed useful secondary resources and/or that too few secondary resources have been pushed so that none of them have been rejected (see the description of step 230 with reference to Figure 2). Therefore, in this case, the action performed is that the advertised secondary resource is accepted (step 415). In other words, the receiving of the secondary resource advertised at step 300 is accepted and the secondary resource is thus received from the server.

If the response is no, i.e. if the first threshold is not met at step 410, it is checked at step 420 whether the MAN is greater than 0.6 or whether the SRN is lower than 10. If so, the action performed is that the receiving of the secondary resource advertised at step 300 is rejected with a ratio of 1 out of 4 (step 425). In other words, the unrequested resource may be rejected with a probability of 25%.

In practice, this ratio may be achieved by picking randomly a number between 0 and 1 and if this number is lower than 0.25, the resource is rejected.

According to a variant, this ratio may be achieved by counting the secondary resources already received in this context (i.e. step 420 verified), and if the number is, for instance, a multiple of 4, then the resource is rejected.

If the second threshold is not met at step 420, it is checked at step 430 whether the MAN is greater than 0.4. If so, the action performed is that the receiving of the secondary resource advertised at step 300 is rejected with a ratio of 1 out of 2 (step 435). In other words, the unrequested resource may be rejected with a probability of 50%.

In practice, this ratio may be achieved by picking randomly a number between 0 and 1 and if this number is lower than 0.5, the resource is rejected.

According to a variant, this ratio may be achieved by counting the secondary resources already received in this context (i.e. step 430 verified), and if the number is, for instance, a multiple of 2, then the resource is rejected.

If the third threshold is not met at step 430, it is checked at step 440 whether the MAN is greater than 0.2. If so, the action performed is that the receiving of the secondary resource advertised at step 300 is rejected with a ratio of 3 out of 4 (step

445). In other words, the unrequested resource may be rejected with a probability of

75%.

In practice, this ratio may be achieved by picking randomly a number between 0 and 1 and if this number is lower than 0.75, the resource is rejected.

According to a variant, this ratio may be achieved by counting the secondary resources already received in this context (i.e. step 440 verified), and if the number is, for instance, not a multiple of 4, then the resource is rejected.

Finally, if the fourth threshold is not met at step 440, it is checked at step 450 whether the MAN is greater than or equal to 0. In this case, the action performed is that the advertised secondary resource is rejected (step 455). In other words, the receiving of the secondary resource advertised at step 300 is not accepted and the secondary resource is thus not received from the server.

After action steps 415, 425, 435, 445 and 455, the process ends (step 460).

According to a variant, a specific test may be added before each step 415, 425, 435, 445, and 455 for taking into account the rightness of rejection decisions taken by the client regarding advertised unrequested resources. For instance, this specific test allows the determination of whether the value of a ratio of advertised unrequested resources that have been rejected according to the current handling policy and that have not been requested by an application of the client is especially high (for instance greater than 0.8), especially low (for instance greater than 0.2) or acceptable (between 0.2 and 0.8).

In the case where the client took a lot of bad decisions of rejecting data that were finally required by the application, the action to perform may be to accept all advertised resources instead of one of the actions of steps 425, 435, 445 and 455.

In the case where the client took a lot of good reject decisions, the action to perform is to reject all advertised secondary resources instead of one of the actions of steps 415, 425, 435 and 445.

In the example of Figure 5, the parameter considered for determining the handling policy is the ratio of bytes accessed for selected secondary resources (ABR). For a considered set of secondary resources, this ratio is equal to the size of received secondary resources that have been accessed by an application of the client divided by the size of all received secondary resources (accessed and not accessed).

This example is particularly adapted to HTTP/2 as it relies on flow control and priority models defined by this protocol.

According to this policy, the greater the ABR is, the more useful an advertised secondary resource should be. Hence, the parameters of the considered stream are adapted to carry useful secondary resources.

It is recalled that the initial window size for the flow control is always the same default value (65535 bytes) and that it cannot be reduced. Hence, only the way to increment this initial size can be modified, as described hereafter. It is also recalled that the WINDOW_SIZE parameter is the size by which the window is incremented, and is not the initial size of the windows.

In this example, the ABR parameter is obtained at step 500. It has been computed during the analysis step 120, for instance according to the process of Figure 2.

At step 510, it is determined whether the ABR is greater than 0.8.

If so, the action to be performed at step 515 is to set the WINDOW_SIZE parameter associated with the stream of the secondary resource advertised at step 300 to the value 2^Λ24 - 1. This value allows the server to send a large amount of data. In practice, the value set for this parameter is sent to the server in a WINDOW_UPDATE frame.

In addition, it may be defined as another action to perform if this data amount is to be reached, and even if no access to this data has been done (e.g. no application of the client has requested the secondary resource advertised at step 300 and being currently received), that a new WINDOW_UPDATE frame has to be sent in order to allow the server to send additional data.

In some embodiments, the sending of this frame may be performed prior to receiving the corresponding amount of data (e.g. when only half of the window remains available), so that the server does not have to stop sending data.

The sending of a WINDOW_UPDATE frame with a considered WINDOW_SIZE value is dependent on whether the client has enough memory to do so. This is because a client should not send a WINDOW_UPDATE frame with a WINDOW_SIZE that it cannot actually support.

If the first threshold is not met at step 510, it is checked at step 520 whether the ABR is greater than 0.6. If so, the action to be performed at step 525 is to set the WINDOW_SIZE parameter associated with the stream of the secondary resource advertised at step 300 to the value 2^Λ20 - 1.

In addition, it may be defined as another action to perform, only if the secondary resource has been accessed, that a new WINDOW_UPDATE frame has to be sent. As for step 515, the sending of such frame is done only if the client has enough memory to process additional data.

If the second threshold is not met at step 520, it is checked at step 530 whether the ABR is greater than 0.4. If so, the action to be performed at step 535 is to set the WINDOW_SIZE parameter associated with the stream of the secondary resource advertised at step 300 to the value 2^Λ16 - 1.

In addition, it may be defined as another action to perform, only if the secondary resource advertised at step 300 and being currently received has been accessed, that a new WINDOW_UPDATE frame has to be sent. In such a case, it is also defined as another action to perform that the priority of corresponding stream has to be increased. Since a small window has been defined, if it appears that the secondary resource is actually useful, it is indeed advantageous to increase the priority of corresponding stream. For instance, the highest priority value may be set.

It may also be useful to increase the value of WINDOW_SIZE parameter. This may also be an additional criterion considered in the defined thresholds.

If the third threshold is not met at step 530, it is checked at step 540 whether the ABR is greater than 0.2. If so, the action to be performed at step 545 is to set the WINDOW_SIZE parameter associated with the stream of the secondary resource advertised at step 300 to the value 2^Λ14 - 1.

In addition, it may be defined as another action to perform, only if the secondary resource advertised at step 300 and being currently received has been accessed, that a new WINDOW_UPDATE frame have to be sent. In such a case, it is also defined as another action to perform that the priority of corresponding stream has to be increased. Since a small window has been defined, if it appears that the secondary resource is actually useful, it is indeed advantageous to increase the priority of corresponding stream. For instance, the highest priority value may be set.

If the fourth threshold is not met at step 540, it is checked at step 550 whether the ABR is greater than or equal to 0. In such conditions, the action to be performed at step 555 is to reject all advertised secondary resources.

After steps 515, 525, 535, 545 and 555, the process ends (step 560).

According to a variant, a specific test may be added before each step 515,

525, 535, 545, and 555 for taking into account the rightness of rejection decisions taken by the client regarding advertised unrequested resources. For instance, this specific test allows the determination of whether the value of a ratio of advertised unrequested resources that have been rejected according to the current handling policy and that have not been requested by an application of the client is especially high (for instance greater than 0.8), especially low (for instance greater than 0.2) or acceptable (between 0.2 and 0.8).

In the case where the client took a lot of bad decisions of rejecting data that were finally required by the application, the action to perform may be to accept all advertised resources instead of one ofthe actions of steps 515, 525, 535, 545 and 555.

In the case where the client took a lot of good reject decisions, the action to perform is to reject all advertised secondary resources instead of one of the actions of steps 515, 525, 535 and 545.

Figure 6 represents a block diagram of a computer device 600, for instance a client device, in which steps of one or more embodiments may be implemented.

The device 600 may be an end-user device such as a mobile device, a micro-computer (laptop), a workstation, a desktop computer or a light portable device. It may also be a proxy device.

The device 600 comprises a communication bus 602 to which there are preferably connected:

- a central processing unit 604, such as a microprocessor, denoted CPU;

- a read only memory 606, denoted ROM, for storing computer programs for implementing the invention;

- a random access memory 608, denoted RAM, for storing the executable code of methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing methods according to embodiments of the invention;

- a communication interface 612 connected to the communication network 614 over which a client-server based communication can be implemented. The communication interface is provided to send requests or responses, such as HTTP requests/responses including web data, possibly in the Push or Pull model of communication, as well as to receive the requests or responses; and

- a data storage means 610 such as a hard disk, for storing computer programs for implementing steps of one or more embodiments of the invention and for storing data, during the implementation of one or more embodiments of the invention, and typically for implementing a cache memory. The cache memory -also called cacheis made of a plurality of cache entries, configured to store data.

Optionally, the device 600 may also include interfaces 616 to display information to, and/or receive inputs from, a user. For instance, it may be a screen for displaying data such as a web page in the case of the device and/or serving as a graphical interface with a user, by means of a keyboard or any other pointing means.

The communication bus provides communication and interoperability between the various elements included in the device 600 or connected to it. The representation of the bus is not limiting and in particular the CPU 604 is operable to communicate instructions to any element of the device 600 directly or by means of another element of the device 600.

The disk 610 can be replaced by any information medium such as for example a compact disk (CD-ROM), rewritable or not, a ZIP disk or a memory card and, in general terms, by an information storage means that can be read by a microcomputer or by a microprocessor, integrated or not into the device, possibly removable, and adapted to store one or more programs whose execution enables a method according to the invention to be implemented.

Instructions relating to the software application may be loaded to the main memory 608 from a hard-disk (HD) 610 or the program ROM 606 for example. According to a variant, the executable code of the programs can be received by means of the communication network 614, via the interface 612, in order to be stored in one of the storage means of the device 600, such as the hard-disk 610, before being executed. Such software application, when executed by the CPU 604, causes the steps described with reference to Figures 1 to 5 to be performed in the device 600.

The CPU 604 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to the invention, which instructions are stored in one of the aforementioned storage means. On powering up, the program or programs that are stored in a non-volatile memory, for example on the hard-disk 610 or in the ROM 606, are transferred into the RAM 608, which then contains the executable code of the program or programs, as well as registers for storing the variables and parameters necessary for implementing the invention.

In this embodiment, the device is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). It can consist of one or more dedicated integrated circuits that are capable of implementing the method as described with reference to Figures 1 to 5.

While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive, the invention being not restricted to the disclosed embodiment. Other variations to the disclosed embodiment can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. It is to be noted that resources or main resources may be sub-resources of other resources and that sub-resources or auxiliary resources may be requested as main resources.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used. Any reference signs in the claims should not be construed as limiting the scope of the invention.

Claims

1. A method for managing the reception of unrequested resources associated with requested resources, the method comprising, at a client device of a client-server system:

2. The method of claim 1, wherein the second requested resource is the first requested resource.

3. The method of claim 1 or 2, also comprising receiving the first resource.

4. The method of any one of claims 1 to 3, wherein a plurality of unrequested resources associated with at least one requested first resource are received and the analyzing step is performed for at least part of this plurality of received unrequested resources.

5. The method of claim 4, wherein the analyzing step comprises selecting a subset of unrequested resources from among all the received unrequested resources of the plurality, according to at least one filtering criterion, and wherein analyzing usage is performed only for the unrequested resources of the subset.

6. The method of claim 5, wherein the at least one filtering criterion depends on previous exchanges with the server from which is the advertised unrequested resource.

7. The method of claim 5 or 6, wherein the at least one filtering criterion is at least one of the following criteria:

8. The method of any one of claims 5 to 7, wherein a number of points is set for each fulfilled filtering criterion according to the advertised unrequested resource, and an unrequested resource is selected only if the sum of the corresponding points reaches a predetermined threshold.

9. The method of any one of claims 5 to 8, wherein the analyzing step comprises defining a table associating a set of filtering criteria with each category of unrequested resource, a given category being defined based on at least one of: resource type, resource size, associated HTTP header, associated application of the client or associated context.

10. The method of any one of claims 5 to 9, wherein the analyzing step comprises computing the value of at least one parameter among the following parameters for the unrequested resources of the subset:

the number of unrequested resources in the subset;

the mean number of access to the unrequested resources of the subset;

11. The method of claim 10, wherein the analyzing step also comprises computing the ratio between the number of advertised unrequested resources that have been rejected according to the current handling policy and that have not been requested by an application of the client and the total number of rejected advertised unrequested resources.

12. The method of claim 10 or 11, wherein the determining step is based on parameter values computed during the analyzing step.

13. The method of any one of claims 1 to 12, wherein determining the handling policy comprises defining at least one action to be performed by the client for the advertised unrequested resource among the following actions: rejecting the advertised unrequested resource, modifying the flow control of the corresponding stream, modifying the priority of the corresponding stream.

14. The method of any one of claims 1 to 13, wherein determining the handling policy comprises defining at least one of these actions to be performed by the client: using a specific header when requesting a resource, indicating to the server from which is the advertised unrequested resource that unrequested resources are no longer accepted.

15. The method of any one of claims 1 to 14, wherein, when at least one triggering criterion is met, the steps of analyzing or determining are performed again.

16. The method of claim 15, wherein the triggering criterion is an amount of time elapsed since the last analyzing step or the last determining step.

17. The method of claim 15, wherein the triggering criterion is the receiving of a predetermined number of unrequested resources from a considered server of the client-server system.

18. The method of any one of claims 15 to 17, comprising, when the at least one triggering criterion is met, waiting for a predetermined amount of time before performing again the steps of analyzing or determining.

19. A computer program product for a programmable apparatus, the computer program product comprising instructions for carrying out each step of the method according to any one of claims 1 to 18 when the program is loaded and executed by a programmable apparatus.

20. A computer-readable storage medium storing instructions of a computer program for implementing the method according to any one of claims 1 to 18.

21. A client device for managing the reception of unrequested resources associated with requested resources, the device being configured for:

22. A proxy device comprising a client device according to claim 21.

23. An end-user device comprising a client device according to claim 21.

24. A method substantially as hereinbefore described with reference to, and as shown in Figures 1 to 5.

25. A client device substantially as hereinbefore described with reference to, and as shown in Figure 6.