US20090077205A1 - Object transfer control in a communications network - Google Patents

Abstract

A method and an intermediate component for controlling in a communications network an object transfer from a first network component via the intermediate component to a second network component which is remote from the first network component are described. The object transfer is based on a plurality of object requests relating to objects referred to in one or more codes to be processed by the second network component or another network component. The intermediate component forms the steps of sending an object request to the first network component, receiving the requested object from the first network component, updating and/or assessing a priority of the requested object, and, in dependence of the priority of the requested object, delaying the requested object or forwarding the requested object to the second network component. An initial priority is assigned to the requested objects on the basis of an analysis of at least one of the object request and the code that refers to the requested object.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of U.S. application Ser. No. 10/509,979, filed Mar. 18,2005, now pending, which was the National Stage of International Application No. PCT/EP02/03802, filed Apr. 5, 2002, the disclosure of which is incorporated herein by reference.
BACKGROUND
• 1. Technical Field
• The invention generally relates to the field of communications networks and more particularly to an object transfer from a first network component via an intermediate component to a second network component, the second network component being remote from the first network component.
• 2. Description of the Prior Art
• The transfer of information over modem communications networks like the public Internet or internal networks is based on specific transfer protocols. The World Wide Web for example, which constitutes a major aspect of the Internet, uses the Hyper Text Transfer Protocol (HTTP) for exchanging files comprising text, images, sound, video, and other contents.
• Any WWW server contains, in addition to the files it can serve, an HTTP component that is designed to wait for HTTP requests and to handle them when they arrive. A WWW browser can be considered as an HTTP client that is configured to send HTTP requests to WWW servers. Whenever a user of the browser enters a file request by either “opening” a WWW file (by typing in a Uniform Resource Locator (URL)) or by clicking on a hyper text link, the browser builds a corresponding HTTP request for the file and sends it to the destination address. The HTTP component in the destination server receives the HTTP request and returns the requested file.
• The requested file may be constituted by a Hyper Text Mark up Language (HTML) page that includes HTML code. When the browser receives the HTML page from the server and detects that the HTML code, which can be considered as an object itself, includes further objects such as (background) images, sounds, scripts or HTML frames, the browser issues further HTTP requests to the server in order to fetch the further objects which are included in the HTML code. Upon receipt of the further HTTP requests, the server sends HTTP responses including the requested objects like images to the browser. As becomes apparent fromFIG. 1, the HTTP responses are sent from the server to the browser running on the client in the same order as the browser has issued the HTTP requests.
• The order in which any additional objects included in the HTML code of the HTML page are requested by the browser usually depends on how the HTML page was written. For example an object that is included at the beginning of the HTML code is not necessarily displayed at the top of the HTML page because features such as tables, layers and frames allow the HTML author to use complex layouts. In addition, the order in which a browser issues HTTP requests depends also on internal browser algorithms. For example some browsers use complex heuristics for generating the HTTP requests by starting with requesting the first four objects as they appear in the HTML code of the page. After the first four objects have been requested, every second object starting from the top of the area that is currently visible to the user is requested, then every fourth object and so on. Other browsers use a simpler algorithm that requests the objects one by one as they appear in the HTML code. From the above it becomes apparent that it is usually difficult to predict the order in which HTTP requests for objects referred to in an HTML code are generated.
• Moreover, it is difficult to predict the order in which requested objects are received by the browser. Although the current HTTP standard (HTTP/1.1) requires that on each Transfer Control Protocol (TCP) connection the HTTP responses are sent from the server to the browser in the same order as the HTTP requests are received by the server, the order in which HTTP responses are received becomes unpredictable as soon as more than one connection is opened to the server. The reason therefore is the fact that due to varying network conditions and different request processing times, some connections may transfer HTTP responses faster than others.
• There is a need for a method and a device that enable an improved transfer of objects from a first network component to a second network component which is remote from the first network component.
SUMMARY OF THE INVENTION
• According to one aspect of the invention this need is satisfied by a method of controlling in a communications network an object transfer from a first component via an intermediate (hardware or software) component to a second component which is remote from the first component, wherein the object transfer is based on a plurality of object requests relating to objects referred to in one or more codes to be processed by the second or another component of the communications network and wherein the intermediate component performs the steps of sending an object request to the first component, receiving the requested object from the first component, at least one of assessing and updating a priority of the requested object, wherein an initial priority has been assigned to the requested object on the basis of an analysis of at least one of the object request and the code that refers to the requested object, and, in dependence of the priority of the requested object, delaying the requested object or forwarding the requested object to the second component. An object may itself comprise code portions referring to one or more further objects. Furthermore, a code may itself form a (e.g. previously requested) object.
• By intentionally delaying the object transfer based on an assigned priority, the overall transfer of objects is improved from a user's point of view (even if the total amount of data to be transferred is not decreased) because important objects are transferred preferentially. Furthermore, by implementing appropriate priority assignment schemes the object transfer from the first network component to the second network component becomes more predictable. For example objects being of higher significance to the user may be assigned a higher priority and may thus be preferentially transferred to the second component. On the other hand, objects being of lesser significance may be delayed. In the extreme case an object having a low significance may be delayed to such an extent that it is not transferred to the second component at all. This allows to control the order in which objects are received by the second component.
• The assignment of absolute or relative priorities to objects (or classes of objects) may be performed dynamically. Once a priority has initially been assigned, this priority may be assessed with respect to specific absolute values like thresholds or with respect to priorities of other objects. Based on the assessment it can be decided whether or not an object is to be delayed. Prior to the assessment a priority initially assigned to an object may be evaluated anew with the purpose of determining whether the initial priority has to be updated.
• The intermediate component may be operated to re-order objects received from the first component. The delaying of objects is thus preferably performed such that the order in which the intermediate component receives the objects from the first component differs from the order in which the objects are forwarded to the second component. The reordering may be based on the priorities of the objects to be transferred. During the reordering there might arise the situation that due to the delay of some objects the transfer of other objects is actually accelerated.
• The object request that is sent to the first component may be generated by the intermediate component. When the requested object is received by the intermediate component, it “pushes” it to the second component without having received an explicit object request from the second component. Alternatively, the object request may be generated by the second component and sent to the intermediate component. Upon receipt of the object request from the second component, it may be processed by the intermediate component and forwarded to the first component.
• When the intermediate component receives the requested object from the first component, the received object may either be delayed or directly forwarded to the second component. There exist various possibilities how the requested object that is received by the intermediate component can be delayed. Delaying of the requested object can for example include at least one of instructing the second component to repeat the object request, suspending a connection to the second network component via which the requested object is to be forwarded, and informing the second component that the requested object will automatically (e.g. without any further object request from the second component) be forwarded to the second component at a later point in time.
• If delaying of the requested object includes instructing the second component to repeat the object request, the intermediate component may perform the steps of assigning a specific attribute to the object to be delayed, informing the second component of the attribute, receiving a reference to the attribute (e.g. the attribute itself or an unambiguous reference derived from the attribute) from the second component, and, upon receipt of the reference to the attribute, sending the delayed object to the second component or further delaying the delayed object. The decision whether a delayed object is to be sent to the second component or delayed further may be based on the newly assessed relative priority of the repeatedly requested object.
• The attribute can be considered as a common denominator which enables the intermediate component and the second component to negotiate about the transfer of the object to which the attribute has been assigned. Usually, the form of the attribute will depend on the characteristics of the transfer protocol that is used for the object transfer. In the case of HTTP for example, the attribute may be constituted by a virtual URL created by the intermediate component. It should be noted that the attribute-based delay scheme of instructing the second component to repeat the object request can generally be used to delay objects and does not necessarily require that priorities have been assigned to the objects to be transferred.
• In the attribute-based delay scheme the object may be send from the intermediate component to the second component in response to an object request received from the second component or in accordance with a pushing scheme, i.e. independently of such an object request from the second component. If the delay scheme is based on an object request received from the second component, the second component may be informed about the attribute in context with an instruction to repeat the object request. In such a case the reference to the attribute may be received by the intermediate component in context with a repeated object request from the second component.
• The objects to be transferred to the second component may be forwarded to the second component via a single or via a plurality of connections between the intermediate component and the second component. In such a multiple connections scenario selected ones of the connections to the second component may be suspended dependent upon the (initial or updated) priorities of the requested objects that are to be forwarded via the selected ones of the connections to the second component. The intermediate component may thus suspend one or more connections so that objects having a high priority can make use of the additional bandwidth that is released on the link between the intermediate component and the second component. In order not to waste available bandwidth the intermediate component is preferably configured such that it ensures that a link formed by two or more connections is fully used before suspending one or more connections thereof.
• There exist various techniques for suspending a connection. For example transmission over the connection could be blocked for a specific period of time while leaving the connection as such open (intermediate state=open). Alternatively, the connection could be closed (intermediate state=closed) while saving the state of the connection. In such a case the connection may be reopened at a later point in time in the same state in which it was closed. According to a third possibility, the connection may be completely closed without saving any information about the state of the connection. In any case the second component can be informed that the one or more objects to be transmitted via the closed connection will be sent later, either in response to or independently from a (repeated) object request.
• Instead of or in addition to suspending individual connections, the object transfer may also be delayed by a priority based adjustment of the transfer speed. To that end, a specific share of processing capabilities may be dynamically allocated to each object or each connection. In the case of multiple connections, all connections or at least some connections get a share of the CPU time, i.e. a share of the network bandwidth. The share of processing capabilities allocated to a specific connection may be changed (e.g. decreased constantly) while one or more objects are transferred via the respective connection.
• It has been mentioned above that the object transfer is based on a plurality of object requests relating to objects referred to in one or more codes. According to a first variant of the invention a code is readily available to at least one of the second and the intermediate component. According to a second variant of the invention the code has yet to be loaded by either one of the second and the intermediate component. In the latter case the intermediate component may send a code request that has been generated by the second component or by the intermediate component to the first component or a third component that is different from the first component. When the requested code is received from the first or the third component, it may be analyzed by the intermediate component with respect to references to objects comprised within the code. Any references to objects contained in the code may then be assessed with the purpose of assigning (initial) priorities to the objects referred to in the received code. The code received from the first or the third component may eventually be forwarded by the intermediate component to the second component.
• Upon receipt of a response from the first component the requested object contained in the response may be evaluated with respect to the received objects priority. For example at least one of the object size, the object content and a header of the response may be analyzed to that end. It can then be determined whether or not an initial priority of a received object has to be updated.
• Preferably, at least some information about each object or each class of objects is stored for example by the intermediate component. The stored information may comprise priority information for individual objects or a classes of objects, preferably, in the form of a priority list. This priority list may be repeatedly assessed. Such an assessment can relate to at least one of updating priority information and deleting objects or classes of objects from the priority list.
• The invention may be implemented as a hardware solution or as a software solution. In the case of a software solution the invention may be realized in the form of a computer program product comprising program code portions for performing the individual steps of the invention. The computer program product may be stored on a computer readable recording medium.
• According to a preferred embodiment of the invention the intermediate component is implemented as a proxy component in the form of a piece of software running on the first or the second component of the communications network. If the invention is implemented as a hardware solution, the intermediate component may be constituted by a separate piece of hardware like a proxy server arranged between the first and the second component in the communications network. The intermediate component may include one or more appropriately configured communication interfaces for communicating with at least the first and the second component of the communications network as well as a unit for performing the processing in context with delaying of objects.
• In the communications network there exists a first link between the intermediate component and the first component and a second link between the intermediate component and the second component. Preferably, the first link and the second link have different transfer rates. For example a fast link may be provided between the intermediate component and the first component and a comparatively slower link may be provided between the intermediate component and the second component. This situation is usually given when the first component is a network server, the second component is a network client and the intermediate component is located in the vicinity of (in terms of network links) or on the network server. However, the intermediate component could also be located close to (in terms of network links) or on the network client. In such a case the link between the intermediate component and the second component (the network client) has a much higher capacity and lower latency than the link between the intermediate component and the first component (the network server).
• It should be noted that the invention is not restricted to the case that the first component acts as network server and the second component acts as network client. In particular, the intermediate component could also be used to improve the object transfer between two network clients or two network servers.
• According to an especially preferred embodiment of the invention the intermediate component is part of a wireless communications network like a GSM, GPRS, etc. cellular network. In such a network the second component may be constituted by a mobile terminal.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
• Further aspects and advantages of the invention will become apparent upon reading the following detailed description of preferred embodiments of the invention and upon reference to the drawings, in which:
• FIG. 1 is a schematic diagram illustrating a transfer of objects between a network server and a network client in accordance with HTTP;
• FIG. 2 is a block diagram of a network system comprising an intermediate component in the form of a HTTP proxy server according to the invention;
• FIG. 3 is a block diagram of the HTTP proxy server ofFIG. 2;
• FIG. 4 is a schematic diagram depicting a redirection-based object delay in the network system depicted inFIG. 2;
• FIG. 5 is a flow chart reflecting the steps preceding an object delay;
• FIG. 6 is a flow chart depicting the decisions involved in an object transfer according to the invention; and
• FIG. 7 is a block diagram depicting a proxy component according to the invention located on a network client.
DETAILED DESCRIPTION
• Although the present invention can be practiced in any communications network in which a request-based object transfer via an intermediate component is performed, the following description of preferred embodiments is exemplarily set forth with respect to the transfer of HTML code in accordance with the HTTP protocol over the WWW. In principle, transfer protocols different from HTTP, like the wireless WAP transport protocol or some Remote Procedure Call (RPC) mechanisms, and codes different from HTML, for example the WAP Markup-Language (WML) or any derivatives of the eXtensible Markup-Language (XML), could be utilized as well. Furthermore, although the following description mainly concerns an object transfer from a server to a client, the object transfer could be performed between any two or more network components.
• InFIG. 2, a block diagram of anetwork system10 according to the invention is depicted. As becomes apparent fromFIG. 2, thenetwork system10 comprises a first component in the form of aserver20, an intermediate component in the form of aHTTP proxy server30 and a second component in the form of aclient40. Theproxy server30 is arranged in thenetwork system10 such that it has afast link12 towards theserver20 and a comparativelyslower link14 towards theclient40. Eachlink12,14 is constituted by a plurality ofTCP connections50. EachTCP connection50 is configured to allow the transfer of HTTP requests and HTTP responses between theserver20 and theclient40.
• Theproxy server30 performs some traditional proxy functions like caching and filtering of objects. Additionally, theproxy server30 is configured to artificially delay an object that is received from theserver20 and that is to be forwarded to theclient40. This is done by using a combination of temporary suspension of data transfer on someconnections50 and HTTP redirection messages that force a browser running on theclient40 to repeat an object requested after a certain period of time. By using these mechanisms theproxy server30 re-orders the HTTP responses received from theserver20 in such a way that objects having a higher priority are delivered to theclient40 first. For that purpose theproxy server30 dynamically assigns priorities to the objects to be forwarded to theclient40. In order to ensure that delaying of the less important objects does not cause thelink14 between theproxy server30 and theclient40 to become idle, theproxy server30 continuously or at least repeatedly monitors the traffic on thislink14.
• The construction of theproxy server30 is depicted in more detail inFIG. 3. As becomes apparent fromFIG. 3, theproxy server30 comprises acommunications interface32 coupled between thefirst link12 to theserver20 and thesecond link14 to theclient40. Thecommunications interface32 is configured such that it enables the sending of object requests to and the receipt of the requested objects from theserver20. Aprocessing unit34 of theproxy server30 communicates with thecommunications interface32. Theprocessing unit34 allows to assess and/or adapt the priority of any object received via thefirst link12 from theserver20. Additionally, theprocessing unit34 allows to assign an initial priority to a requested object on the basis of an analysis of at least one of the object request and the code that refers to the requested object. Possible assignment schemes will be discussed later in more detail.
• In dependence of the initial or updated priority of an requested object theprocessing unit34 controls thecommunications interface32 such that a requested object received from theserver20 is either delayed or forwarded via thesecond link14 to theclient40. If a requested object received from theserver20 is to be delayed, it is temporarily stored in abuffer36 that can be accessed by both thecommunications interface32 and theprocessing unit34. Alternatively or in addition, thebuffer36 may be implemented as a software or hardware component of theprocessing unit34.
• Besides the tasks outlined above, theprocessing unit34 is additionally configured such that it allows to assign a specific attribute to an object which is to be delayed (an exemplary format of this attribute will be discussed later in more detail). Theprocessing unit34 enables to control thecommunications interface32 such that thecommunications interface32 informs theclient40 about this attribute. If thecommunications interface32 receives a reference to the attribute from theclient40, theprocessing unit34 evaluates this reference and controls thecommunications interface32 such that the delayed object to which this attribute has previously been assigned and which is currently stored in thebuffer36 is either sent to theclient40 or further delayed. A further delay of the object stored in thebuffer36 may become necessary if objects of a higher priority have to be forwarded to theclient40 first.
• In the following, a preferred operational mode of thenetwork system10 shown inFIG. 2 will exemplarily be described.
• When a user enters a URL, clicks on a link or follows a bookmark, the browser running on theclient40 issues a HTTP request for the corresponding HTML page including HTML code. The HTTP request issued by the browser is received by theproxy server30 via thelink14 and forwarded via thelink12 to thedestination server20. Theserver20 replies by sending the HTML code for the requested page to theproxy server30, which analyzes the HTML code received from theserver20 to assign an initial priority to any kind of objects like links, frames, scripts, images, etc. referred to in the HTML code (first analysis phase).
• Independently from this analysis of the HTML code, theproxy server30 forwards the HTML code via thelink14 to theclient40. When the browser running on theclient40 receives the HTML page including the HTML code it processes the HTML code. If the browser detects that the HTML code includes further objects, it issues further HTTP requests for the objects referred to in the HTML code. These HTTP requests for further objects are received and evaluated by theproxy server30. To most of the requested objects an initial priority will have been assigned already during the proxy server's30 previous analysis of the HTML code that it has forwarded to theserver40. However, in this second analysis phase theproxy server30 either assigns initial priorities to those objects to which a priority has not yet been assigned or updates the priority of such objects to which an initial priority has already been assigned. The priority is updated on the basis of additional information available in the HTTP request received from theclient40.
• Theproxy server30 forwards any HTTP requests for additional objects received from theclient40 to theserver20. Theserver20 replies by sending the requested objects to theproxy server30. Theproxy server30 analyzes the HTTP responses (including the requested objects) from theserver20 in a third analysis phase and updates—if necessary—the priorities of the objects comprised in the HTTP response. Additionally, theproxy server30 assesses the relative priority of any received object with respect to the priority of previously received objects that are still stored in the buffer36 (seeFIG. 3) and the priorities of objects that are expected soon. Information regarding the objects that will be received soon from theserver20 can be derived from the HTML code that has previously been forwarded to theclient40 or from HTTP requests from theclient40 for which the corresponding objects have not yet been received from theserver20. Alternatively or additionally, theproxy server30 may be configured such that it compares a priority of an object that has just been received from theserver40 with an absolute value like a priority threshold.
• Based on the evaluation of an object's absolute and/or relative priority and the current and/or predicted traffic on thelink14, theproxy server30 decides if this object is to be delayed, e.g. if this object is to be temporarily stored in thebuffer36 or if the corresponding HTTP request is not yet to be forwarded to theserver20, or if the object is to be immediately forwarded to theclient40.
• The intentional delay of individual objects improves the overall object transfer from a user's point of view. It is for example well known that the relative importance of the various objects included in a web page varies greatly: An image that is used to build a graphical menu may be essential for the navigation of a site, while a background image merely makes the page look nicer. The invention can thus be employed to provide the user with the more important information first. As soon as there is enough information of a web page displayed on the user's screen, the user can decide to click on a link and request another web page without having to wait for the remaining (less important) parts of the previous web page that is still being transferred. As a result, the user is no longer forced to wait until some uninteresting objects are transferred before being able to see the important ones. This is especially useful in conjunction with the mobile Internet, which is usually slower and more expensive than the fixed Internet.
Assignment and Adjustment of Priorities
• As has become apparent from the above, theproxy server30 can assign or adjust the priority of an object to be sent to theclient20 during three different phases, namely when a reference to that object is found in an HTML code (i.e. in a previous object) that is to be forwarded to theclient40, when a HTTP request relating to that object is issued by the browser running on theclient40, or when the corresponding HTTP response containing the requested object is received from theserver20.
• In the following, various schemes for assigning or updating priorities during each of these three phases are exemplarily described. During any of the three phases a priority list that contains priority information for individual objects or classes of objects is either generated or updated. In the priority list, the individual objects or classes of objects are ordered with respect to increasing or decreasing priority. The order of the objects in the priority list can thus be considered as priority information. However, additional priority information like absolute or relative priority values (numbers) may alternatively or additionally be part of the priority list.
• The exact priority assigned to specific objects or classes of objects is implementation-dependent and in the exemplary embodiment configurable by the operator of theproxy server30 or a user of the browser running on theclient40. For example in order to allow the operator of theproxy server20 to have more control over the priority of some objects, there could be one or several lists of URLs (using pattern matching) that allow the operator to increase or decrease the priority of the objects appearing on those lists. For example an operator could decide to increase or decrease priority of all images downloaded from an advertising company. The same possibilities may be made available to the user. For example the user could send his preferences to theproxy server30. This can be done by a specific software running on theclient40 or by using designated web pages provided directly by theproxy server30 and allowing the user to set his preferences.
• In the first analyzing phase theproxy server30 can assign an initial priority to an object by analyzing an HTML code that has been requested by theclient40 from theserver20. In particular, references to objects referred to in the HTML code may be assessed to that end. In this way a priority list may be generated that lists individual objects which are referred to in the HTML code in the following order (objects of highest priority are mentioned first):
• links to other pages
• frames
• inlined images (if the IMG tag includes width and height information, this information can be used to refine the priority of images depending on the expected dimensions so that smaller images get a higher priority than larger ones)
• style sheets
• scripts (JavaScript, VBScript, etc.), embedded objects and applets
• background image (page background, table background, style sheet, etc.)
• any object that was already sent to theclient40 gets the lowest priority
• In addition the priority of a specific object can be lowered if the object is not located on thesame server20 or on the same domain as the current HTML page.
• A further possibility to assign or adjust the priority of an object occurs when a request for that object is issued by the browser and received by theproxy server30. In such a case the HTTP request can be analyzed by theproxy server30 in an URL context (second analysis phase). Since initial priorities have already been assigned during analysis of the HTML code that led to that HTTP request, analysis of the HTTP request will usually result in an adjustment of the initial priority. However, in some cases initial priorities may be assigned also (see above).
• The adjustment or assignment of initial priorities in the second analysis phase can be performed in dependence on additional information available for example in the header of the HTTP request. One or more of the following rules for updating the priorities may be implemented:
• • The analysis leads to the result that the browser has already requested the same object once. Such an object is preferably assigned a very high priority in order to avoid infinite loops caused by browsers that are not fully compliant to HTTP/1.1 and ignore the Retry-After header (this header will be discussed below in more detail).
  • The object does not have a priority yet, but the file extension looks like HTML (“.HTML”.“.HTM”) or XML (“.XML”) or looks like a directory index (ends“/”). Such a priority assignment ensures that a HTML page requested from the bookmarks or typed in directly will be requested with a high priority.
  • The browser makes a conditional HTTP request for an object, using if-modified-since or similar conditions. This indicates that the browser has probably cached a copy of the object. The reply is expected to be small if the cached copy is still valid (HTTP reply code “304 not modified”).
  • The URL of the requested object was found while parsing a previous HTML page.
  • Any object that was not inserted in the list while parsing the HTML tags of a previous page was probably requested indirectly by a script and should get a lower priority than most of the other requested objects.
• In the third analysis phase, the adjustment of object priorities is based on an analysis of the HTTP response from theserver20. The adjustment of the priorities in the third analysis phase (as well as in the second analysis phase mentioned above) can be calculated as a weighted sum of several criteria. The weights may be configurable by the operator of theproxy server30 or the user of the browser running on theclient40.
• In the third analysis phase, all objects will usually have a priority assigned to them. However, this priority can be updated before sending the requested objects to theclient40. To adjust the priorities, the headers and contents of the HTTP responses received from theserver20 may be assessed. The priorities may then be adjusted in accordance with one or more of the following rules:
• • Assessment of the reply code: the relative priority of the HTTP responses depends on the first digit of the reply code. Error codes (4xx, 5xx) should have a higher priority than normal replies (2xx).
  • Assessment of the content type: a HTML code should have a higher priority than any image.
  • Assessment of the objects size (derived from the content-length if specified in the headers, or from the total size if the object is already cached): smaller objects should have a slightly higher priority than larger ones.
  • Analysis of the content: for example animated images can be assigned a lower priority than static images. The analysis of the content can also form the basis for estimating the size of the object if this information is not available in the HTTP header and the object has not yet been cached.
  • If the reply code is a permanent or temporary redirection (3xx) specifying a new location for the requested object, then this new location gets the same priority as the original object.
• In the three analysis phases described above theproxy server30 sets and updates the priorities of the objects that are to be transferred to theclient40. Theproxy server30 thus keeps some information about each object like the object's URL, priority, time of last request and, if required, some further parameters. However, this information can not be kept forever since otherwise theproxy server30 would run out of memory. Moreover, if an object to which a high priority has been assigned is never requested, action is preferably taken so that it does not prevent other objects from being transferred.
• For these reasons a routine is implemented that ensures that information that is no longer up to date or that is no longer required is deleted. To that end one or more of the following mechanisms may be used:
• • Any object that is successfully transferred to the client is marked as having been sent or is moved to a separate list of objects that have been sent to theclient40.
  • A maximum size for one or more lists containing relevant information is set and configured such that older objects or objects with the lowest priority expire first.
  • Whenever the client resets a TCP connection before the object is fully transferred (meaning that the user has stopped the download and may have selected another page), clear the information of objects to be sent.
  • As an alternative to the previous solution, keep cross-references for each object in order to associate each HTML page with the objects that it contains and vice versa. When theclient40 resets a TCP connection, remove only the objects that are included in the same HTML page.
  • The priority of all objects can be decreased after a specified amount of time or after some number of HTTP requests or HTTP responses have been processed.
Reordering of Objects
• In the previous chapter the generation of a priority list for the requested objects to be transferred to theclient40 as well as possible updating mechanisms for this priority list have been described. Usually, the requested objects will be received by theproxy server30 from theserver20 in an order that is different from the order indicated in the priority list. Consequently, theproxy server30 has to reorder the objects received from theserver20 in such a manner that they are forwarded from theproxy server30 to theclient40 in an order which reflects the order in the priority list as closely as possible. Theproxy server30 reorders the objects received from theserver20 by intentionally delaying objects having a lower priority and by forwarding objects having a higher priority without any substantial delay to theclient40.
• Theproxy server30 uses a combination of different delay mechanisms to reorder the objects received from theserver20. In the following, two of these delay mechanisms, namely suspension of TCP connections on the one hand and HTTP redirections on the other hand, will exemplarily be described in more detail
Suspension of TCP Connections
• As becomes apparent fromFIG. 2, thelink14 between theproxy server30 and theclient40 is constituted by a plurality ofTCP connections50. Dependent upon the priorities of the requested objects that are to be forwarded via individual ones of theconnections50, one or more of theconnections50 that are intended for the transfer of objects having a low priority are suspended. This suspension of individual connections releases some bandwidth on thelink14 that is now available for preferentially transferring objects having a higher priority. Consequently, objects having a higher priority will be delivered before objects having a lower priority.
• The suspension of anindividual connection50 is performed such that theconnection50 is left open without transferring objects for a certain period of time. Alternatively, suspension of aconnection50 could be effected by closing theconnection50, either with our without saving the state of theconnection50 prior to its suspension. When the state of the suspendedconnection50 is saved, it can be opened at a later point in time in the same state as it has been suspended (i.e. closed).
• Suspension of aconnection50 has the advantage that no extra data has to be sent via thelink14. Preferably, aconnection50 is suspended only if the released bandwidth can be fully used by someother connections50 for the transfer of objects having a high priority.
• Theproxy server30 is thus configured such that it checks that thelink14 is fully used before suspending aconnection50 in order not to waste available bandwidth. A possible routine for predicting if thelink14 is or will be partially idle includes comparing the average throughput (over the last N seconds) of allconnections50 going to theclient40 with the amount of data that is currently cached or buffered in thebuffer36 of the proxy server30 (seeFIG. 3) and is ready to be sent. Other and in particular simpler techniques for estimating the utilization of thelink14 could be implemented as well, especially if the available bandwidth on thelink14 is known by other means.
HTTP Redirections
• If theproxy server30 expects that objects having a high priority will soon have to be transferred to the client14 (e.g. because links to these objects have previously been detected by theproxy server30 while forwarding the HTML code of a HTML page to the client40), and suspension of aconnection50 would waste some bandwidth because there is currently nothing else to transfer on theother connections50, then theproxy server30 may utilize another delay scheme. A possible delay scheme that is applicable in such a case includes instructing theclient40 to repeat an object request at a later point in time.
• Although HTTP specifies that any HTTP responses must be sent to theclient40 in the same order as the browser running on theclient40 has issued the HTTP requests, it is possible to instruct the browser to retry a HTTP request later. This can be done by sending a HTTP response with the status code “302” to theclient40, together with the header field “Retry-After”. This header field tells theclient40 to retry his HTTP request after a specified amount of time. In response to the receipt of the status code “302” (possibly including the “Retry-After” header field), current browsers re-schedule the HTTP request after all pending HTTP requests have been processed.
• The status code “302” as specified in the HTTP standard 1.1 tells the browser that a given object can be found (temporarily) at a location that is different from the one that was requested. The HTTP response sent to theclient40 includes the new location of the object. This mechanism is used to implement the delay scheme according to the invention.
• According to the invention theproxy server30 generates an attribute in the form of a new (virtual) URL for the object to be delayed. Theproxy server30 then instructs the browser running on theclient40 to try the HTTP request again, using this temporary attribute (i.e. URL) as the new location of the object. The browser is thus instructed to reschedule the HTTP request at a later point in time. When the browser repeats its HTTP request (including the temporary attribute, i.e. the virtual URL), theproxy server30 converts the attribute to the original URL and forwards the HTTP request to theserver20. Alternatively, the original HTTP request could have been forwarded to theserver20 after receipt thereof by theproxy server30. In such a case the HTTP response received from theserver20 is temporarily stored by theproxy server30 until it receives the repeated HTTP request from theclient40.
• In the following, the inventive delay mechanism discussed above will exemplarily be described in more detail with reference toFIGS. 4 and 5. It will be assumed that the HTTP request received by theproxy server30 from theclient40 relates to an object that is considered by theproxy server30 to be of a low priority.
• In afirst step402 ofFIG. 4, theproxy server30 receives a HTTP request from theclient40 via thelink14. In the exemplary case of HTTP this first request from the client could have the following format:
• GET http://example.com/some/image.png HTTP/1.1
• Host: example.com
• User-Agent: Mozilla/5.0 (X11; Linux i686; en-US; rv: 0.9.9) Gecko/20020311
• Connection: close
• In response to the HTTP request received instep402 from theclient40, theproxy server30 redirects theclient40 instep404 to a new (virtual) location and instructs theclient40 to wait for a certain period of time (delay) before retrying the HTTP request. The redirection message from theproxy server30 on the basis of the status code “302” as specified in the HTTP standard 1.1 can have the following format:
• HTTP/1.1 302 Found
• Date: Thu, 21 Mar. 2002 15:12:47
• Server: PrioTest/0.9
• Location: http//example.com/some/( )image(0001).png
• Retry-After: 5
• Connection: close
• Transfer-Encoding: chunked
• Content-Type: text/html; charset=iso-8859-1
• (some human-readable text follows)
• Theproxy server30 can now request the object from theserver20 at any time after receipt of the initial HTTP request from the client40 (step402) and the time at which it decides to deliver the object to the client40 (steps406 and408).
• After receipt of the above redirection message theclient40 waits for a period of time specified in the redirection message, i.e. five seconds (or until all other objects have been transferred). Instep412 theclient40 then repeats his HTTP request indicating the new (virtual) location as follows:
• GET http://example.com/some/( )image(00001).png HTTP/1.1
• Host: example.com
• User-Agent: Mozilla/5.0 (X11; Linux i686; en-US; rv:0.9.9) Gecko/2002031 1
• Connection: close
• Upon receipt of the repeated HTTP request from theclient40, theproxy server30 decides whether to delay the requested object further (e.g. by suspending aconnection50 or by a further redirection message) or whether to forward the delayed object to theclient40. If theproxy server30 decides to forward the delayed object without any further delay, this can be done in the following format:
• HTTP/1.1 200 OK
• Date: Thu, 21 Mar. 2002 15:12:50
• Server: Apache/1.3.23 (Unix)
• Content-Type: image/png
• Content-Length: 1520
• (the contents of the image follow)
• Now, the decisions taken by theproxy server30 in the course of the redirection routine discussed above with reference toFIG. 4 will be explained with reference toFIG. 5.
• Instep502 theproxy server30 receives the HTTP request from theclient40. In thefollowing step504 theproxy server30 determines whether the URL included in the HTTP request is a modified URL, i.e. the result of a previous redirection. If this is the case, theproxy server30 decodes the URL and restores the original location instep506 and moves vianode508 to step510. Otherwise the method directly moves fromstep504 vianode508 to step510.
• Instep510 theproxy server30 determines if the object requested by means of the HTTP request is already available, i.e. stored in thebuffer36 of the proxy server30 (seeFIG. 3). If the object is not already cached, theproxy server30 requests the object from theserver20 or marks it for later retrieval instep514. Fromstep514 the method moves vianode512 to step516. Step516 can also be reached directly fromstep510 vianode512 in the case the object requested by theclient40 is already available.
• Instep516 the HTTP response including the requested object is ready to be sent to theclient40. This corresponds to the first step in the flow chart ofFIG. 6 which will be discussed below.
• In principle, the redirection message (step404 inFIG. 4) can be sent to theclient40 at any time whilesteps502 to516 are performed or afterstep516. It should be noted that the availability of an object (i.e. whether a requested object is already cached, currently in transfer or whether the object is not requested yet) is a further factor that influences the initial priority of a requested object.
Re-Ordering Decisions
• Once the HTTP response is ready to be sent to the client40 (step516 inFIG. 5), it has to be decided if an object comprised in the HTTP response should actually be delivered to theclient40, if theclient40 should be redirected or if theconnection50 via which this object is to be sent to theclient40 should be suspended. A flow chart depicting an exemplary decision scheme in this regard is depicted inFIG. 6.
• Instep602 the HTTP response is ready to be sent to the client. In thefollowing step604 the priority of this object is evaluated with respect to the fact whether or not the priority has to be updated. If the priority of the object has to be updated, the priority is adjusted instep604.
• In thenext step606 the current priority of the object is assessed to find out if it has the highest priority of all objects that are being transferred or that are expected soon. If it is determined instep606 that the requested object actually has the highest priority, the method moves vianode610 to step612. Instep612 the requested object is sent to theclient40.
• If the comparison of the priority of the currently requested object with the priority of other objects instep606 leads to the result that the currently requested object does not have the highest priority, the method continues withstep614. With respect to step606 it should be noted that instead of comparing the priority of the currently requested object with the priorities of other objects it is also possible to compare the priority of the currently requested object with a fixed threshold or to add an offset in the comparison so that two priorities have to be different by more than a predefined threshold before the difference is considered significant enough.
• Instep614 theproxy server30 estimates if thelink14 to the client40 (seeFIG. 2) is or will be idle. As explained above, there are several ways to do that. One of them comprises calculating a running average of the maximum amount of data that was sent and acknowledged during the last N seconds over allconnections50 going to thesame client40. This gives an estimate of the maximum throughput available.
• The result thus obtained is then compared with the amount of data that is ready to be sent on theconnections50 that are not suspended. If theproxy server30 detects that it does not have enough data to send in order to fill the link during at least one complete round-trip time, then it considers that there is some spare bandwidth on thelink14 towards theclient40 and continues withstep616.
• In step616 a comparison similar to that ofstep606 is performed. If it is determined instep616 that the currently requested object has a higher priority than all objects expected soon, theproxy server30 continues vianode610 withstep612 and sends the currently requested object immediately to theclient40. Otherwise the method continues withstep618 and a redirection message (status code “302”) is sent to theclient40 as discussed above in conjunction withFIG. 4.
• The decision taken instep616 can be influenced by the size of the currently requested object (if it is already known). If the object is known to be small (e.g. less than twice the size of a redirection message), then the proxy server will always send the object instead of sending a redirection message, even if the object had been assigned a very low priority until then (this can be considered as one way of updating the priority).
• If it is determined instep614 that there is enough data to be sent in order to fill thelink14, the method continues with step620 and suspends theconnection50 to theclient40 via which the currently requested object is to be transferred.
• From either one ofstep612,618 and620 the method continuous withstep622. Instep622 theproxy server30 re-evaluates all suspendedconnections50 to find out whether any one of the suspendedconnections50 are to be opened again.
• The HTTP/1.1 protocol supports the pipelining option, which allows theclient40 to send several requests to theserver20 orproxy server30 on the same TCP connection without waiting for the previous replies. In the case pipelining is used, more than one object that is ready to be sent could be sent on thesame connection50 towards theclient40. It is apparent that in such a case an object having a low priority could block a second object having a high priority that is to be sent on thesame connection50. If there are several objects waiting on thesame connection50, the maximum or average priority of these objects may be determined and considered insteps606 and616. This ensures that objects of lower priority do not block objects of higher priority.
Possible Extensions
• Several extensions, some of which have already briefly been discussed, to the exemplary embodiment described with reference toFIGS. 1 to 6 could be implemented.
• One of these extension relates to constraining the transfer speed onlink14 in dependence of the priority of the objects to be transferred. This could be done for example by allocating a specific share of processing capabilities to eachconnection50 depending on the priority of the objects to be transferred. The priority of the individual objects is decreased while the process is running. If theproxy server30processes connections50 in a round-robin fashion, this feature can be implemented by limiting the amount of data transferred per round on eachconnection50 by a number that is derived from the priority of that object. The dynamic allocation of processing capabilities can advantageously be combined with the suspension and redirection mechanisms discussed above. The processing capabilities can also include any transformation of the objects or codes being transferred.
• According to a further extension of the invention, the priorities are assigned directly by the browser running on theclient40. The browser can then schedule the HTTP requests for individual objects according to their priority. If the priorities are assigned directly by the browser, there are some additional factors that can be used for refining the priority of each object:
• • position of the object in the page (coordinates)
  • relative position of the visible area (objects that are outside the visible area have a lower priority)
  • if image loading or script execution is disabled, the browser knows immediately that it is not necessary to assign a priority to these objects.
• Additionally, the browser knows when a user selects a new HTML page from the bookmarks or by typing in a new URL. The browser can thus clear the list of objects that are no longer required.
• A further extension of the invention relates to a proxy component that is located on the same computer (client) as the browser or close to this computer in terms of network links. This situation is depicted inFIG. 7.
• As becomes apparent fromFIG. 7, theclient40 not only comprises abrowser component42 but an additional proxy component30 (having the structure shown inFIG. 3) in communication with thebrowser component42. In such a case thelink14 between theproxy component30 and thebrowser component42 has a much higher capacity and lower latency than thelink12 between the proxy component and the server20 (not depicted inFIG. 7).
• As a result, the client-side proxy component30 influences the request stream because it cannot do much on the response stream. Based on the priority information derived from the current HTTP request and previous HTTP responses (e.g. previous HTML codes referring to further objects) as well as an estimate of the link availability, the client-side proxy component30 will decide if a HTTP request should be forwarded to the server and/or if it should reply immediately with a redirection message.
• The decisions to be taken are simpler than depicted in the flow chart ofFIG. 6. More particularly, the decisions can be reduced to evaluating if the currently requested object has a lower priority than some of the objects being transferred or expected to be transferred soon and if the link is already fully used. If both conditions are given, then a redirection message is sent to thebrowser component42. In all other cases, the HTTP request is immediately forwarded to the server.
• If HTTP pipelining is used on a specific connection and if some previous HTTP requests are being processed, then the client-side proxy component30 can suspend the HTTP request until it can take the decision. It will have to take a decision at the latest when the previous objects have been fully received.
• A still further extension of the invention relates to the blocking of downloads for some objects based on their priority. This means that the priority that is assigned to the objects can also be used to block the objects completely. If a threshold on the priority has been set, any object that has a priority that is lower than this threshold will not be sent to theclient40. In this case the proxy server (or proxy component)30 would simply return one of the “4xx” or “5xx” status codes defined in the HTTP/1.1 standard to theclient40 when it detects such an object. Possible status codes are “403 forbidden”, “409 conflict” or “503 service unavailable”.
• As an additional extension the priorities assigned to the objects could be used for pre-fetching. A pre-fetching mechanism allows theproxy server30 to fill its buffer36 (seeFIG. 3) with some objects before theclient40 actually requests them. Such a pre-fetching mechanism may for example be based on the analysis of a HTML code that is sent from theproxy server30 to theclient40 and that includes references to further objects. Based on the analysis of the references to the objects theproxy component30 assigns priorities to the individual objects and on the basis of this assignment it is defined which objects are to be pre-fetched and in what order. Preferably, the objects are pre-fetched starting with the objects having the highest priority.
• According to a still further extension that may be combined with the pre-fetching mechanism discussed above, specific pushing schemes are implemented that allow to transfer objects from theproxy server30 to theclient40 without having received an explicit object request from theclient40.
• Various modifications of the preferred embodiment are possible without departing from the scope and spirit of the present invention. Although the invention has been described in connection with a preferred embodiment, it is to be understood that this description is not intended to limit the invention thereto. Rather, the invention is intended to cover all modifications and/or additions to the above-mentioned description, without departing from the spirit and the scope of the invention.

Claims (25)

1. A method of operating a proxy server, comprising:

finding a reference to an object in a previous object that is to be forwarded to a client; and

upon finding the reference to the object, assigning or adjusting a priority of the object to be sent to the client.

2. The method according toclaim 1, wherein the previous object comprises HTML code.

3. The method according toclaim 1, comprising the step of generating a priority list that lists individual objects, which are referred to in the previous object, according to their priority.

4. The method according toclaim 1, wherein the priority of the object is determined depending on the following order of decreasing priority of an object type:

a link to another page,

a frame, an inlined image,

a style sheet,

same priority for a script or an embedded object or an applet,

lower priority for a background image,

lowest priority for an object that was already sent to the client.

5. The method according toclaim 1, wherein the priority of the object to be sent to a client is assigned or adjusted, when a request, that is issued by a browser running on the client, relating to said object is received.

6. The method according toclaim 5, wherein the request is an HTTP request.

7. The method according toclaim 6, comprising the step of analyzing the request in an URL context.

8. The method according toclaim 6, wherein the priority is adjusted or assigned in dependence of information in the header of the HTTP request.

9. The method according toclaim 5, comprising the steps of determining whether the object has already been requested once by the browser, wherein the object gets a high priority assigned if the object has already been requested once by the browser.

10. The method according toclaim 5, wherein the object gets a high priority assigned if the object does not have a priority yet and the file extension indicates one of an HTML file, an XML file or a directory index.

11. The method according toclaim 5, wherein the priority, which is assigned or adjusted in reaction of the received request, depends on whether the request is a conditional HTTP request.

12. The method according toclaim 5, wherein the priority, which is assigned or adjusted in reaction of the received request, is lower than for most of other requested objects, if the object was requested indirectly by a script.

13. The method according toclaim 5, wherein the priority of the object to be sent to a client is assigned or adjusted, when a response corresponding to a request of the object is received, wherein said response contains the object.

14. The method according toclaim 13, wherein the response is a HTTP response.

15. The method according toclaim 14, wherein a header or a content of the HTTP response is assessed to adjust the priority.

16. The method according toclaim 14, wherein a reply code is assessed to adjust the priority, and wherein a higher priority is assigned if the assessment of the reply code indicates an error code than if the assessment of the reply code indicates a normal reply.

17. The method according toclaim 14, wherein a content type is assessed to adjust the priority, and wherein a higher priority is assigned if the assessment of the content type indicates a HTML code than if the assessment of the reply code indicates an image.

18. The method according toclaim 14, wherein a size of the object is assessed, and wherein a smaller object gets a higher priority than a larger object.

19. The method according toclaim 14, wherein a content of the object is analyzed to adjust the priority.

20. The method according toclaim 19, wherein an animated image gets a lower priority than a static image.

21. The method according toclaim 14, wherein if a reply code is a redirection specifying a new location for the requested object, said new location gets the same priority as the original object.

22. The method according toclaim 14, wherein the priority of all objects is decreased after a specified amount of time or after several HTTP requests or HTTP responses have been processed.

23. Proxy server, having means adapted to perform the method according toclaim 1.

24. A computer program comprising program code portions for performing the steps ofclaim 1 when the computer program is run on a computer system.

25. A computer readable recording medium, which stores a computer program ofclaim 24.

Images