CZ20001058A3 - A method and system for prefetching data - Google Patents

Abstract

The method and system is designed to pre-draw data for clients (22) associated with the proxy server hierarchy (21, 23, 24) and improved data transfer from content servers (20) to clients (22). The data pumping method identifies patterns data access and pre-draws selective information on based on dynamic interpretation of data access patterns. Content server or proxy server (20,23,24) identifies client data access patterns (22) associated with the content server or proxy hierarchy (20) servers (21, 23, 24). Data access patterns are preferred stored in a statistical table. Content server (20) generates pre-pumping instructions on based on statistical table entries. Information with instructions regarding pre-pumping comments on requested information or objects requested by clients (22). Information with instructions for pre-pumping are optimally updated at the desired information through the proxy server hierarchy (21, 23, 24). Information on overfilling instructions they comment on the required information requested by clients (22). Final decision on pre-withdrawal of selective information for clients (22) is based on guidance information on pre-pumping and pre-pumping values from the guidelines. The pre-pumping value from the instructions is calculated based on local node-specific factors such as storage constraints and access time.

Description

METHOD AND SYSTEM FOR PUMPING INFORMATION

Technical field

The invention relates to a method and apparatus for dynamically retrieving information or objects for clients, wherein the clients are preferably associated with a hierarchy of proxy servers, such as that which may be involved in prefetching objects on the Web.

BACKGROUND OF THE INVENTION

Dictionary of terms

Internet: A network and router network that uses the TCP / IP family.

Client: A client is a computer that issues commands to a server that performs a task associated with a command.

Server: Any computer that performs a task at the command of another computer is a server. A web server typically supports one or more clients.

World Wide Web: An Internet application that allows users looking for information on the Internet to switch connections from server to server and from database to database by selecting (tapping) the desired highlighted words or sentences (known as hyperlinks). The Internet www server supports clients and provides information to clients. A site that can be considered the Internet, with all resources addressed as URLs, uses HTML to display information

79 274

0 and provides a 'show and' interface • 099 00 ··

0 I «’

Β 0 0 «·« matching the given URL click to the next URL.

Universal Resource Unique Identifier (URL): A URL is a way or address of information on the Internet and can be considered as a version of the email address of a Web document. URL can be accessed by hyperlink. An example of a URL identification is http://www.philipyu.com:80/table.html. The URL has four parts. Starting from the left in the example, the first part specifies the protocol to be used (in this case http), separated from the rest of the locator. The next part is the node name or IP address of the destination node; this part is separated by a double slash // left and right one slash / (alternatively the port number is an optional part and is separated to the left of the node name and to the right by a single slash /. The fourth part is the actual file name or program name (table.html in this example) ), using other simple slashes to separate directories and subdirectories in the normal way, in this example, the .html suffix means that it is an HTML file.

HyperText Markup Language (HTML): HTML is the language used by web servers to create and merge documents that are viewed by web clients. HTML generates hypertext documents.

Hypertext Transfer Protocol (HTTP): HTTP is an example of a stateless protocol in which each client-to-server request is handled independently. The server has no record of previous connections. At the beginning of the URL, http :, the requesting client and destination server should communicate using the HTTP protocol for the specified resource.

Web browser or web browser: A graphical interface tool that runs Internet protocols such as HTTP and displays results on the user's screen. Browser can act as internet guide «

• 0 ·

0 ·

• 0 tt * * • 0 · 000 ·· ♦ 00

0 »·· with desktop with images, directories and search tools for surfing the Internet. In this application, the web browser is a client service that communicates with www.

Client Cache: Client caches are typically used as the primary group (caches) of objects that a client accesses. In a Web environment, client caches are typically implemented by Web browsers and can cache objects that are accessed during the current session, that is, a temporary cache, or they can capture objects between sessions.

Capture Proxy Servers: Specialized servers on the network that act as agents representing the client to locate an object, possibly returning a captured copy. Capture proxy servers typically serve as secondary or higher-level caches because they are invoked as a result of not finding an item in the client cache.

Meta tagging: Linking information to a given object. For example, in HTTP, information can be associated with both requests and responses in HTTP header fields. For example, the HTTP client might specify the URL from which the returned page was requested.

Due to the increase in the popularity of www (the web) in the Internet, traffic has increased considerably. The Web has now become one of the main bottlenecks in network performance. For example, a site user may experience significant delays if a user who is connected to the server through a slow network link requests documents or information. Transferring information over the Web to the user further increases the level of network traffic. Increased traffic reduces the bandwidth available for other users' requests and this contributes to further potential delays.

• · 0 0 0 * * * * * * * *

To reduce client access delays, prior art copies of favorite documents with information closer to the user have been stored or captured on network nodes from which access delays are more permissible. Caching can be implemented at various locations in the network. For example, a large university or company may have its own local cache from which all users who are logged on to this network can access documents. The local cache can be implemented as a dedicated server.

A specialized server, called a capture proxy, can act as an agent to represent clients for any potentially captured copy of the requested information. Capture proxies typically serve as secondary or higher-level caches because capture proxy servers only handle items that are not found in the client cache. Client caches are built into various web browsers. Client caches can either store only document accesses during the current session (temporary cache, such as Mosaic), or they can intercept documents between sessions.

Previous work on capturing web documents in the cache was mainly in the field of capturing responses to requests. Capturing responses to requests means that the capture decision is made after the object is requested. For example, Proxies: Limitations and

Abrams et al., Caching Potentials, Proc. 4th

The International World Wide Web Conference, 1996, describes various strategies for capturing response responses that have been explored for the Web.

4 4 fc 4 4 fc 4 4 fc

In an Internet Service Provider (ISP) network or in a company network, different regional or departmental proxy servers in the hierarchy may follow different reference behaviors or have different network traffic and delays. The presence of a proxy hierarchy further complicates the prefetch decision about whether all intermediate proxies, the client, or a subset thereof should perform the prefetch. Thus, there is a need for a prepayment method and system that is capable of effectively coordinating the prepayment activities with respect to the hierarchy of proxy servers and associated clients.

SUMMARY OF THE INVENTION

Thus, the present invention provides a method of prefetching selection information from a content server to make it available to one or more clients associated with a content server through a communications network and one or more proxy servers, the method comprising the steps of:

requesting information from at least one of the proxy servers; establishing pre-withdrawal information for said clients based on past withdrawals or access to the requested information by any of said clients;

adding a comment to the required information with that information with instructions for pre-pumping; and prefetching the selection information from any of said servers based on the prefetch information and the requested information.

Typically, the required information includes the required information.

The objects and selection information contain candidate prefetch objects such as Internet data. In this case, the desired object may refer to the select object via a hypertext transfer protocol (HTTP) link associated with the Internet data, wherein the proxy server identifies the relationship of the select object to the desired object via the universal protocol locator of the requested object or URL stored in the object header of the requested object. .

Preferably, the step of establishing information with prefetch instructions comprises the steps of: tracking data link patterns associated with said clients; organizing data reference patterns into object identifier groups, wherein the object identifier groups are organized according to the relationships between the requested objects and the candidate prefetch objects; and determining which of said groups has sufficient relationships between the pre-pumping candidate objects and the required objects to ensure that said pre-pumping candidate objects are pumped as selection information. Thus, the data link pattern of said clients is preferably based on past draws or previous accesses to the requested information, wherein the pattern of data links is selected to represent any common trends in past draws or hits by other of said clients associated with one of said proxy servers. These can then be used to define information with pre-pumping instructions.

Preferably, the tracking and organizing steps comprise establishing databases to store the reference data patterns in the proxy servers; arranging fields in each of said databases, the fields comprising object identifiers; and

4 »0 0 0 · · 0 number of objects, where object identifiers distinguish between required objects; the number of objects indicates how many times the requested objects have been requested by monitoring one of said servers; and associating access lists with said databases, each of said access lists comprising one or more candidate pre-pumping objects associated with each desired object.

Such a database may be used to define the relationship between the requested objects and the candidate prefetch objects and to monitor access statistics for the requested objects and the candidate prefetch objects; access statistics include the frequency of accesses to the parent objects of the requested objects and the frequency of accesses to the filial objects of the candidate pre-pumping objects; the frequency of accesses to the parent objects indicates how many times a particular object is requested by at least one of said clients; the frequency of accesses to the filial objects indicates how many times one or more of said candidate objects are actually required to be pumped immediately following access to a particular object. This makes it possible to select a pre-pumping list with pre-pumped candidate objects based on the ratio of the access rate to the child object to the access rate to the parental object associated with the access frequency to the child object.

Generally, only a subset of pre-pumped candidate objects is pre-pumped and received at one of said proxy servers or one of said clients, typically the selection of the pre-pumped candidate pile is based on factors such as selection information such as Fefe · fefe · fefe · available storage space on one of the specified proxy servers and / or access time on one of the specified proxy servers. The candidate pre-pumping objects are therefore pre-pumped according to the priority associated with any corresponding pre-pumping value.

In a preferred embodiment, the step of commenting on the requested information includes the step of placing information with prefetching information in a prefetch label having a format of the Internet Content Selection Platform (PICS) or a label protocol compatible with the PICS format. In a particular implementation of this (PICS) format, an object identifier category and a referrer identifier category are defined, and the method further comprises the step of returning the referring object identifier category to the content server to identify all candidate pre-pumping objects that have actually been referenced. Organizing information with PICS pre-pumping instructions or PICS-compatible protocols already uses a format supported by many browsers.

Typically, there is a hierarchy of said proxy servers. By defining the sending node and the receiving node in this hierarchy, the prefetch information is preferably adjusted from the initial state to the final state, the initial state being determined by the sending node, the final state being determined by the receiving node. Information with instructions on final drawdown then forms the basis of the final drawdown decision (assuming that the drawdown of the sampling information is started by the receiving node).

»

0 0 ···· · · · · 0 0 ··

0 «00 0 · · ♦

In other words, information with prefetch instructions can be interpreted and updated as they transmit the hierarchy of proxy servers to clients. Preferably, the proxy server updates the prefetch information if there are local references to the requested information and if the number of servers at the local level exceeds the minimum threshold number (i.e., reliable statistics are available locally). The prefetch information may also be updated based on state interception in the hierarchy of proxy servers (eg to indicate where a particular prefetch candidate object may be intercepted in the hierarchy).

The invention further provides a data processing system for pumping selection information from a network content server, said system comprising one or more network-connected proxy servers and clients for communicating with the content server and one or more of the network proxy servers; said system comprising:

means for requesting information from at least one of the proxy servers;

means for establishing information with instructions for pre-drawing for said clients based on past drawing or access to the requested information by any of said clients;

means for commenting on the requested information with said information with pre-pumping instructions; and means for prefetching the selection information from any of said servers based on the prefetch information and the requested information.

In a preferred embodiment, the requested information includes the requested objects and the selection information comprises the candidate pre-pumping objects, wherein each of said proxy servers and at least one of the clients have memory that it has at least a logical separation between the main cache and the prefetch cache, where the prefetched information is stored in the prefetch cache.

It is preferred that the objects and the pumping cache be pumped so that the pumping resources store the pumped objects in a priority scheme, wherein the priority scheme stores the objects with the highest pumping value first, considering the available memory of the pumping cache. pre-pumped objects by one or more clients. In particular, the overdraft value may be based on the expected probability of access for a particular client to access the overdraft object on the overdraft information list and the cost of accessing the object based on the required storage space to be selected from the overdue candidate objects.

In a preferred embodiment, the pumping means comprises a pumping manipulator comprising computing means for calculating said pumping value and evaluating means for evaluating the pumping value calculated by the computing means; wherein said computing means calculates a pumping value for each pumping object identifier from the pumping information information list; said evaluation means evaluate the pre-pumping values of several pre-pumping objects and prefer to capture the pre-pumping objects into

XI this to this cache that is associated with the highest pre-pumping values from the pre-pumping information list. The pre-pump means may comprise a first pre-pump manipulator in at least one of said proxy servers and a second pre-pump manipulator in at least one of said clients (ie, pre-pump may be performed at several different locations in the hierarchy).

The preferred embodiment also includes a client object request handler stored in the memory of one of said clients, wherein the client object request handler searches in the main cache and in the pumping cache for the desired object before requesting the desired object from a proxy server or network. notifies the content server or proxy server if the object is located in the pumping cache by generating and a request message for the pumping object on the server that indicates that the pumping object has just been accessed by the client. Similarly, it is preferred that at least one of said proxies includes a message handler for requesting a pumped object to forward links to the pumped messages after invoking the cache manager routine if the requested object is located in the pumped cache. This ensures that the server can maintain an accurate record of access statistics even if it is not directly contacted for the filial object because it is accessible from the pre-pumping cache on the client or proxy server.

The invention further provides a content server or proxy server for use in such a data processing system, wherein the requested information comprises the desired objects and wherein the selection information comprises the candidate objects for the data processing.

F c c c c c c c c c c c c c c c c c

a statistical table storing the identifiers of the parent objects and the associated identifiers of the filial objects, the statistical table comprising the first numbers of the parent objects, the first numbers representing the frequency to which the parent objects are referenced by the clients; with which the corresponding filial objects are referenced after referring to the selected one of said parent objects; and generating means for generating an information list with instructions for prefetching based on the information in the statistical table.

In one embodiment, the generating means receives inputs of the first counts, second counts, filial object identifiers, and parental object identifiers from the statistical table, the generating means comprising evaluating means for evaluating the access relationship between the parent objects and their associated filial objects, to an information list with instructions on pre-pumping when filial objects are referenced with a reasonable frequency immediately and in succession before client references to the corresponding parent objects. Adequate frequencies can be based on the ratio of accesses to filial objects to accesses to corresponding parent objects. This typically includes calculating a ratio of the second count to the first count for each of said parent object identifiers; comparing the ratio with the threshold in the instructions; and grouping or associating the filial objects and associated parent objects in the information list with this pre-pumping instruction if the ratio exceeds the threshold value. in the instructions.

Preferably, the server further comprises statistics update means for updating the statistical table based on the currently requested filial object; the statistics update means first searches for the identity referring from said parent objects, wherein the referring object or referrer object was referenced before the actual reference to the filial object, and the just filial object being updated updates its corresponding second number in the statistical table. Also, the statistics table should be updated after receiving the pumped object request message from the pumped object request handler.

It is preferred that, where the proxy server is, it further includes update prefetching means for receiving and updating the prefetch information list. The update prefetch resources compare the first counts with the first local threshold counts and generate generating resources for each of the filial object identifiers for which the first counts exceed the first local threshold counts, while the update prefetch resources maintain the original prefetch list if the first counts do not exceed the first local thresholds. counts. In a more sophisticated approach, the update pre-pumping means compares the first counts with the first and second local threshold counts, and (i) maintains the original information list with the instructions for prefetching if the first counts do not exceed the first local threshold counts; (ii) amend the original information list with instructions for pre-pumping if the first numbers exceed

X * 1 first local threshold counts, but not second local threshold counts; and (iii) replace the original pre-pumping information list if the first counts exceed both the first and second local threshold counts.

Preferably, the server further comprises: a proxy object handler for returning a desired downstream proxy object or to a client that requested the desired object, wherein the proxy object handler returns the requested object and updates the statistics table accordingly if the desired object is not a pumped object; and a pre-cache memory manager for managing the pre-cache memory. Therefore, the proxy object handler returns the requested object from the pre-cache to the requesting client or proxy server and marks the object as removable from the pre-cache if the object was requested in accordance with the pre-draw request. The object proxy handler sends an object request to another server if the requested object is not in the main cache or pre-pump cache. Accordingly, the object proxy manipulator updates the statistics table if the requested object is not associated with a prefetch request and if the requested object is located in the prefetch cache or in the main cache.

In another aspect, the invention provides a method of prefetching selection objects from a content server to instantly make selection objects available to clients associated with one or more proxy servers through a communication network; the method comprises the steps of:

a) requesting requested objects from at least one of said proxy servers;

b) identification of data link templates or corresponding clients based on past draws or iJ:

φ · · φ · φ ·

V ΦΦ «In accessing required objects by clients; (c) transforming prefetch information into a list of prefetch information from data link templates;

(d) commenting on the required objects with information on pre-pumping;

e) pre-pumping selective objects from at least one of said servers based on information with instructions on pre-pumping and currently requested objects.

Thus, the selection information that is pre-pumped contains candidate pre-pumped objects; and the step of establishing the prefetch information further comprises establishing the prefetch information on the sending node in the hierarchy of said proxy servers; wherein the candidate prefetch object is sent by a hierarchy of said proxy servers; and the selection information that is prefetched at the receiving node in the hierarchy is based on the information with prefetching instructions.

Typically, a hierarchy of proxy servers is associated with the network, wherein the hierarchy of proxy servers comprises a lower level server more closely associated with clients than other proxy servers. In one preferred embodiment, the prefetch information is updated via a hierarchy of proxy servers when there are local references to the requested object and if the number from the local level server exceeds the minimum threshold number; alternatively (or in addition) information with prefetch instructions may be updated by analyzing the cached capture state above the hierarchy, with the highest level of hierarchy being closest to the network.

0 0 0 lb • 00

0000 0 ·

0 ·

In another aspect, the invention provides a processing system for improving data flow from servers to network clients, the processing system comprising:

network-connected proxy servers; network-connected content server;

clients configured to communicate with one or more of said proxy servers;

a statistical table that is stored in at least one of said proxy servers, wherein the statistical table stores the parental object identifiers and the associated filial object identifiers, the statistical table comprising the first numbers of the parent objects, the first numbers representing the frequency to which the parent objects refer to clients wherein the statistical table comprises second numbers of filial objects, the second numbers representing the frequency with which the corresponding filial objects are referenced after referring to selected objects from said parent objects; and generating means for generating a prefetch information list by receiving inputs of first counts and corresponding second counts to derive a prefetch list, said generating means comprising:

computing means for calculating a ratio of the second count to the first count for each of said parent object identifiers;

comparative means for comparing the ratio to the threshold of the instructions, the comparative means grouping or associating the filial objects and associated parental objects in the information list with the prefetch instructions when the ratio exceeds the threshold from the instructions; and pre-pumping means for pre-pumping filial objects based on information with pre-pumping instructions and /

0 ·

0

0 0

0

9 •

0 0 0 0

0 0 0 0

0 «00 parent objects actually requested by clients.

In a preferred embodiment, each of said proxy servers has a first processor, a first memory, and a first data storage means; the first memory having at least a logical separation between the first main cache and the first pre-pumping cache; the content server having a second processor, a second memory, and a second data storage means; and at least one of the clients has a third processor, a third memory, and a third storage means, the third memory having at least a logical separation between the second main cache and the second prefetch cache, the manipulation prefetch resources storing the child objects in the first prefetch cache or the second prefetch cache .

In a preferred embodiment, the pre-pumping means comprises computing means for calculating the pre-pumping value and evaluation means for evaluating the pre-pumping value calculated by the computing means; said computing means calculating a pumping value for each identifier of the filing object of the prefetch instruction list and preferring to capture the filing objects with the highest prefetch values from the prefetch instruction list, wherein the manipulation prefetching means manages the available space in the prefetch cache.

Preferably, the system further comprises: pre-pumping update means for updating the pre-pumping instruction list; wherein the pre-pump update means compares the first counts with the first local threshold counts and the second local threshold counts, wherein the first local threshold counts are based on statistics.

IQ from one server, the other local thresholds are based on statistics from another server, where said pre-pumping update means generating generating means for each of the filial object identifiers for which the first counts exceed both the first local threshold counts and the second local threshold counts; the pre-pump update means retain the original pre-pump information list if the first counts do not exceed the first local threshold counts.

It is preferred that such a system further comprises: statistics update means for updating the statistical table;

a proxy object handler stored on one of said proxy servers, wherein the proxy object handler invokes a prefetch list update routine, the proxy object handler returns the desired lower level proxy object if the lower level proxy server requested the requested object, and the manipulator object proxy returns the requested object and invokes statistics update means if the requested object is not a pre-drawn object;

a prefetch cache manager for managing the prefetch cache associated with one of said proxy servers, wherein the proxy object handler invokes the prefetch cache manager if the downstream server did not request the requested object;

the proxy object handler is stored on one of said proxy servers, wherein the proxy object handler returns objects to the requesting client and marks the objects as removable from the pre-cache if the objects are in the pre-cache and if the object was requested • fcfc • fc • fcfc fcfcfcfc fcfc fcfc fc fcfc fcfc fcfc in accordance with the pre-pumping requirement; the proxy object handler sends an object request to another server if the requested object is not in the main cache or pre-pumping cache, the proxy object request handler communicates with the statistics update means when the requested object is not associated with the prefetch request and if the requested object is located or in the main cache.

It is also preferred that the system further comprises: statistics update means for updating the statistical table;

The prepay object message handler stored at one of said proxy servers, wherein the prepay object message handler invokes statistics update means, wherein the prepay object message handler passes the prepay object request message after invoking an administrator routine. If the requested object is located in the pre-pumping cache.

The invention further provides a processing system for improving data flow from servers to network clients, the processing system comprising:

network-connected proxy servers; network-connected content server;

clients configured to communicate with one or more of said proxy servers;

a statistical table that is stored on the content server and at least one of said proxy servers, the statistical table storing the identifiers of the parent objects and the identifiers of the associated filial objects, the statistical table containing the first counts • 0 0 ·

0 0 0

0 0 0

0 · 0 · 0 · 0 * * 000 000 · 0 · 0 0 · 00 ·· of the parent object, the first numbers representing the frequency with which the clients refer to the parent clients, the statistical table containing the second number of filial objects, the second the numbers represent the frequency with which the corresponding filial objects are referenced immediately after reference to the selected one of said parent objects;

generating means receiving inputs of first counts, second counts, filial object identifiers and parental object identifiers from the statistical table, the generating means comprising evaluation means for evaluating the access relationship between the parent objects and their associated filial objects, the evaluation means placing the filial object identifiers on the information list with instructions on pre-pumping when filial objects are referred to with adequate frequencies immediately and in succession before client references to the corresponding parent objects; and • pre-pumping means for pre-pumping filial objects based on information with instructions regarding pre-pumping and parental objects actually requested by clients.

In a preferred embodiment, the pre-pumping means further comprises allocating means for allocating storage priorities to the son objects specified in the prefetch information information list, and selective storage means for storing the selective son objects according to the storage priorities. Preferably, the allocation means allocates storage priorities based on the expected likelihood of accessing the child's object on the prefetch information list and based on the cost of accessing the child's object based on the size needed to

ZI this to this storage space to store selected objects from filial objects.

Thus, the information may be prefetched in the proxy hierarchy to reduce access time to network objects (ie, the Internet) for clients. The selected information is pumped from the content server to make the selected information immediately available to clients associated with the content server on the network. The clients are preferably connected to proxy servers in the network. Clients request information from at least one of the proxy servers. The content server generates prefetch information for clients based on past data access patterns of the requested information by the clients. The content server comments the information requested with the prefetch instructions. One or more proxy servers may dynamically update the prefetch information based on dynamic usage statistics. The prefetch information is updated as the object passes through the proxy hierarchy object to reflect the prefetch operations performed, the capture status at the higher levels of the proxy hierarchy, and other local conditions, such as local reference patterns. The selection information may be pumped from the content server or from any of the proxy servers based on the pumping instructions and the requested information. Pre-pump instruction information may be assigned a pre-pump value based on the probability of link access and storage conditions. The selection information with the highest pumping values in the pumping information information list is cached first and potentially until the pumping cache is full.

- Lá v V v ** * v * * «« · · · · v ··· to totototo totototo ·· • to · ···· ···· to ··· ·· ···

BRIEF DESCRIPTION OF THE DRAWINGS

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram showing content servers (i.e.

web sites), network (ie internet), hierarchy of proxy servers and clients;

FIG. 2 is a further block diagram of the content server, client, and proxy server, in more detail than FIG. 1.

FIG. 3A is a block diagram illustrating a method of dynamically prefetching data from a content server through a hierarchy of proxy servers;

FIG. 3B illustrates an illustrative example of a statistical table;

FIG. 4 is a block diagram illustrating operation of a content server;

FIG. 5 is a block diagram illustrating an update of statistics;

FIG. 6 is a block diagram illustrating the generation of information with prefetch instructions;

FIG. 7 is a block diagram illustrating client operation;

FIG. 8 is a block diagram illustrating pre-pumping;

• 0 «* • 00 ···· 0 * • · · · · · · ·

FIG. 9 is a block diagram illustrating the operation of the client object request handler; FIG.

FIG. 10 is a block diagram illustrating operation of a proxy server;

FIG. 11 is a block diagram illustrating operation of a proxy object request handler;

FIG. 12 is a block diagram illustrating operation of a request handler for a pre-pumped object;

FIG. 13 is a block diagram illustrating a proxy object manipulator; and operation of FIG. 14 is a block diagram illustrating the operation of the update information routine with prefetch instructions.

DETAILED DESCRIPTION OF THE INVENTION

Giant. 1 shows a data processing system comprising clients 22, a proxy hierarchy of proxy servers 24, a network 25, and content servers 20.

Clients can request information in the form of parent objects, filial objects, required objects, selection objects, pages, requested information, and selection information. Parent objects are related to the child objects so that the parent objects can historically have the following requirements for one or more associated child objects. Required objects are analogous to parent objects, while selected objects are analogous to filial objects. objects. Required objects are objects that are actually requested by one or more clients. Meanwhile, the selection objects are grouped with or associated with the desired objects so that the selection objects can be subsequently requested for the desired objects. Required information includes required objects, parent objects, and other forms of data requested by clients. Selection information includes filial objects, selection objects, and other forms of data that can be prefetched.

The clients 22 may request information from the content servers 20 or from the proxy servers 24. However, the proxy servers 24 typically act as intermediaries for the clients 22 relative to the network 25 and the content servers 20. The proxy servers 24 may advantageously execute client requests for information without contacting the content servers 20 if the hierarchy of proxy servers contains the requested information or has the ability to complete the desired task. The data processing system of Fig. 1 can be applied to the Internet. For example, the content server 20 may constitute a website, while the network 25 may constitute the Internet.

Giant. 1 illustrates logical connections 26, as opposed to physical connections, between elements of a data processing system. The logical connections 26 represent the information flow of objects and requests in the data processing system. Logical connections 26 typically do not represent physical connections between proxy servers 24. Logical connections 26 may vary due to workload and / or physical events such as node or communication link failure. Different object types can track different logical transmission paths to reach clients 22.

• φ · φ · · · · · • · φ · • ·

Ι * Φ · ΦΦ · ·· ΦΦ ΦΦ

While in practice any number of clients 22 and proxy servers 24 can be used, the illustrative example of Figure 1 is characterized by four clients 22 and four hierarchical levels of proxy servers 24. In practice, any number of levels in the hierarchy of proxy servers is allowed and clients 22 can be logically connected to any level of the proxy server hierarchy. For example, the hierarchy of proxy servers 24 could be a single proxy server. The present invention can be implemented with only one client 22 and one proxy server 24.

As can be seen, the top-level proxy server is designed as a zero-level proxy server 30. Level zero is a loose designation that only defines the state of one proxy server relative to another proxy server in the illustrative example of FIG. 1. The top-level proxy server may be logically connected to the network 25. The higher-level proxy servers 21 are more logically connected to the network 25, than lower-level proxy servers 23. (Thus, it will be appreciated that in this terminology which considers a zero-level proxy server to be at the top of the proxy server hierarchy, the level is zero higher than level one, which in turn is higher than level two, and so on).

The first level one proxy server 35 and the second level one proxy server 37 are logically connected to the zero level proxy server 30. The first level one proxy server 35 is connected to the first level two proxy server 40 and to the second level two proxy server 43. The first level two proxy server 40 is logically connected to the first level three proxy server 50 and the second level three proxy server 55.

Clients 22 include a first client 600, a second

The client 603, the third client 700 and the fourth client 7 03. The first client 600 and the second client 603 are logically connected to the first level three proxy server 50. The third client 700 and the fourth client 703 are logically connected to the second level three proxy server 55.

The data processing system is now described from the perspective of the second client 603. The second client 603 is connected to its proxy at an immediately higher level. As shown, the immediately higher level proxy is the first level 50 proxy. The second client 603 is then connected to the first level two proxy server 40, the first level one proxy server 35, and the zero level proxy server 30, respectively. The second client 603 can access different network content servers 20. Although the typical communication path for the second client 603 is through an immediately higher level proxy (i.e., the first proxy server 50 at level three), the second client 603 or the lower level proxy server may communicate directly with other higher level proxy servers 24 or with network 25. The second client 603 may even have its own client proxy server to perform interception.

From the perspective of the second client 603, certain proxy servers are not part of its proxy hierarchy. For example, the second proxy server 55 at level three and the second proxy server 43 at level two and the second proxy server 37 at level one are not part of the hierarchy of proxy servers of the second client.

Clients 22 may include, but are not limited to, personal computers, workstations, set top boxes, and the like.

The network 25 may include, but is not limited to, the Internet, www, intranet, local area network (LAN), and the like.

0 0 0 0 0 0 0 * 0 0000 0000 0

90 0090 0000

9000 00 0 · 00 · 00 00

The proxy servers 24 and the content server 20 may include various commercially available computers. For example, the proxy server 24 may be an Internet Connection Server (ICS) marketed by IBM Corporation. Similarly, the content server 20 may be embodied as a Lotus Go Web server, a Lotus Domino server, and the like (also available from IBM Corporation). The proxy server 24 or content server 20 can run on any computing node that includes, but is not limited to, products such as S / 390 SYSPLEX, SP2, or RS6000 (also available from IBM Corporation) workstations. Briefly, the proxy server 24 or content server 20 may include any generic computer and associated software that can provide clients 22 with access to the World Wide Web site, remote file transfer, e-mail support, and transaction support.

The data processing system of Fig. 1 may use the attributes of a conventional proxy hierarchy to maintain data transfer efficiency. For example, if the requested object is not available locally on a lower-level proxy, a request for an unavailable object is made to the next higher-level proxy. If a higher-level proxy has previously captured an object in its cache, the higher-level proxy will forward the requested object to the client through the lower-level proxy. Otherwise, the higher-level proxy server will try to get the object from its next-level proxy server. After obtaining the requested object, it is forwarded to the lower-level proxy or to the client requesting the object.

Giant. 2 shows a more detailed example of the data processing system shown in FIG. 1. The processing system • φ · t * «· ·

0 · 0 · 0 ··· 0 0 0 00 0400 0000

The data processing system comprises a proxy server 24, a content server 20, a network 25 and a client 22. The data processing system preferably includes a pre-pumping unit 250, a statistical table 261, a statistics update unit 252, a main cache 297 and a pre-pumping cache 298. .

Pre-pump unit 250 preferably includes a first pre-pump manipulator 248 in the proxy server 24 and a second pre-pump manipulator 241 in the client 22. Statistical tables 261 include a first statistical table 293 associated with the proxy server 24 and a second statistical table 267 associated with the content server 20. The statistics update unit 252 includes a first statistics update unit 264 for updating the first statistics table 293 and a second statistics update unit 269 for updating the second statistics table 267. The main caches 297 include the first main cache 294 in each proxy server 24 and the second main cache 246 in each client. The pre-pumping cache 298 includes a first pre-pumping cache 296 in the proxy server 24 and a second pre-pumping cache 249 in the client 22.

The proxy server 24 is a computing node that can handle requests from networks 25. The proxy server 24 includes a first processor 280, a first memory 290, and a first storage unit 281. The first memory 290 may include, for example, a direct access memory (RAM). For example, the first storage unit 281 may include a Direct Access Storage Device (DASD). The first memory 290 stores proxy server logic 295 that is executed as computer executable code. The proxy server logic 295 is loaded from the first storage unit 281 into the first memory 290 to be started by the first processor 280. Details of the operation of the proxy server logic 295 are shown in FIG. 10.

· F f ef ef ef ef ef ef ef ef ef ef ef ef ef · ef

Proxy server logic 295 includes proxy request handler 283, proxy object handler 284, first pumping handler 248, pumping object handler 285, pumping object request messages, pumping update resources 291, first statistics update routine 264, first statistics table 293, first major cache 294 and first pre-pumping cache 296.

The details of the operation of the proxy object request handler 283 are shown in FIG. 11. The operation details of the proxy object handler 284 are shown in FIG. 13. The operation of the pre-pumped object request handler 285 is shown in FIG. statistics (i.e., the first statistics update routines 264) are shown in Figure 5.

The operation of the pumping unit 250 (i.e., the first pumping manipulator 248) is shown in detail in FIG. 8. The operation of the pumping update unit 291 or information routing information routine is shown in FIG. 14. The proxy server logic 295 maintains the first main cache. 294 and the first pre-pumping cache 296.

The content server 20 is a computing node that can handle requests from networks 25. The content server 20 includes a second processor 260, a second memory 263, and a second storage unit 265. The second memory 263 may include, for example, a direct access memory (RAM). For example, the second storage unit 265 may include a Direct Access Storage Device (DASD). The second memory 263 stores server logic 268 containing fc · · • t · »

- 3U> * fc <

fcfcfcfcfcfcfcfcfcfcfc * 4 or content server software.

The operation of the content server logic 268 is shown in more detail below with reference to FIG. 4. The content server logic 268 is executed as computer executable code that is loaded from the second storage unit 265 to the second memory 263 for execution by the second processor 260. The table of contents includes a second statistical table 267, a second statistics update unit 269 for updating the second statistical table 267, and a generating unit 266 for generating information with prefetching instructions. The second statistical table 267 stores data according to potential information information with the requested information.

Statistical tables 261 contribute to the generation of information with prefetch instructions based on the actual behavior of the client references. Details of the statistical tables 261 are shown in Fig. 3B.

required clients and pre-pumping related

The operation of the second statistics update unit 269 is shown in more detail with reference to Fig. 5. The generating unit

266 generates information from the information in the second with instructions on prefetching the statistical table 267 and the required information. The generating unit 266 may be performed as a gererizing routine of information with prefetch instructions (PHI) as shown in Fig. 6.

The client 22 preferably comprises a third processor 240, a third memory 245, and a third storage unit 242. The third memory 245 may comprise, for example, a direct access memory. For example, the third storage unit 242 may include a Direct Access Storage Device (DASD). The third memory 245 stores client logic 244 or client software. Client logic activity 244 is • · «

0 '

0 «

0 * «

* ♦ *

0 0 · · ·

The client logic 244 is executed as a computer executable code that is loaded from the third storage means 242 to the third memory 245 for execution by the third processor 240.

Client logic 244 includes client object request handler 247, a second pre-pump handler 241, a second main cache 246, and a second pre-pump cache 249. The client object request handler 247 obtains requested objects for the client from the second main cache 246, the second pre-pump cache 249 24, or the content server 20. Details of the operation of the client object request handler 247 are shown in Figure 9.

Client logic 244 maintains a second main cache 246 and a second prefetch cache 249. The second main cache 246 is used to store frequently referenced objects, while the second prefetch cache 249 is used to store objects before actually referring to them. Pre-pumped objects are objects that have not been immediately or previously referenced in conjunction with referenced objects. In a preferred embodiment, the main caches 297 are managed by a conventional LRU algorithm (last used). Those skilled in the art will also appreciate that any other replacement strategy can be used to maintain the main caches 297.

The main cache 297 and the pre-pumping cache 298 may be logically separated. Logically separating the pumped objects from the actually requested objects in the main cache 297 is to prevent the pumped objects from occupying too much storage space. To achieve this, various alternatives are available for the logically separated pre-pumping cache and the main cache. For example, a single cache may have an upper limit applied to multiple pre-pumped objects and / or an upper limit applied to the space occupied by the pre-pumped objects. The main cache 297 and the pre-pumping cache 298 are designed to support various targets. The main cache 297 is intended to capture popular objects that tend to be repeatedly requested. The prefetch cache 298 is only used to support a particular browsing session by prefetching objects that are unlikely to be used next time in that session. In the preferred embodiment, if a downlevel node in the hierarchy issues an object pumping request to a higher level node pumping cache, the object is sent to the lower level node and marked as removable from the higher level node pumping cache 298 because the pumping target has been reached . Once the prefetched object is actually referenced, it can be moved to the main cache 297 according to the main cache management rules 297. In a preferred embodiment, using the LRU replacement rules, once the prefetched object used is moved to the main cache.

An alternative criterion for accepting an object from the pre-pumping cache 298 to the main cache 297 can be constructed. In Abrams et al., Caching Proxies: Limitations and Potentials, Proc. The 4th International World Wide Web Conference, 1996, describes some cached replacement principles that do not take into account the size of objects in the decision-making process. Other cached replacement principles are known to those of ordinary skill in the art.

Giant.

3A is a block diagram illustrating a method

Dynamic client data pumping from the content server 20 or the hierarchy of proxy servers. First, in block 100, the client requests information from the proxy server or the content server 20. Second, block 102 identifies access to historical data or data link patterns on content server 20 and proxy servers. In practice, the completion order of block 100 and block 102 may be reversed.

Third, in block 104, the content server 20 generates prefetch information (PHI) for related accesses to the requested information based on data reference patterns identified in block 102. Fourth, in block 1Q5, the prefetch information may comment on the requested information . For example, information with prefetch instructions may be transmitted as meta data packaged with the requested information (i.e., the object). Referring to the step of establishing or generating information with prefetching, the content servers 20 follow usage / referencing patterns from a large number of concurrently connected users or clients. In practice, the content servers 20 determine which group of objects relates to the requested information or the desired object. Content servers 20 generate and provide information with prefetching (PHI) instructions with the desired object. In the pre-pumping step or just before it, the proxy servers may interpret the PHI taking into account local conditions and decide which selected objects should be pumped.

Fifth, in block 106, information is updated with instructions for prefetching as required information passes through the hierarchy of proxy servers. Updating the block 106 reflects an operation state and prefetching are buffered at the higher levels hierarchy, and other local conditions, such that a ¹ ·· ·· · • a • s • ·· ♦ «* · it as local reference patterns. Proxy servers can modify PHI to reflect their prefetch decision and various local conditions before sending the object to another proxy (at a lower level) or to the client station. When passing through an object hierarchy of proxy servers, the sending node sets the initial PHI, while the receiving node can derive the final PHI from the initial PHI. Final PHIs define which selected objects are to be pumped based on the required objects. Operations and decisions on pre-pumping are initiated by the receiver, not the sender.

Finally, at block 108, the selection information is pre-pumped based on the pre-pumped information and the requested information. The proxy server or client decides whether to prefetch a subset of the objects specified in the PHI based on the PHI information in the received object, locally maintained link information (if available) and other local conditions such as the amount of available space, and access time.

Generating the prefetch information in block 104 preferably uses a PICS protocol or a PICS-compatible format (see below). The PHIs generated in block 104 are stored with each intercepted object in the cache as part of its meta data, so that once the intercepted object is requested, the object's PHI information can be examined to initiate appropriate pumping operations. PHI information can be provided by the PICS protocol. The PICS protocol provides information about the criticality of each PHI object and its properties such as the size and state of the cached intercept above in the hierarchy.

Update information with instructions on pre-pumping to • to ·· • to to * • to ·· ·· to ·· • this can be achieved through the proxy server hierarchy. Proxy servers can gather local information and distribute or decentralize downward pumping decisions in the hierarchy of proxy servers. In addition, information about which immediate proxy server has pumped the object could influence the decision to pumped down proxy servers and the client station to optimize storage usage and bandwidth.

Proxy servers in the proxy server hierarchy work together to ensure receiver-oriented pre-pumping decisions. The prefetch decision can be made in cooperation of each proxy and client. Information with prefetch instructions in the meta information format comments (ie complements) the required objects. Information with pre-pumping instructions provides information on potential pre-pumping candidates. Intermediate proxy servers may modify meta information or prefetch information based on local conditions and store meta information with the object as soon as it is captured so that prefetch can be triggered at a later reference to the object.

Giant. 3B illustrates the data format of the statistical table 261. The statistical table 261 should generally refer to either the first statistical table 293 or the second statistical table 267. One or more proxy servers 24 maintain the first statistical table 293. The content server 20 may maintain the second statistical table The formats for the first statistical table 293 and the second statistical table 267 are preferably substantially similar or the same in order to enforce the update of the statistical table 261 on other proxy servers in the proxy hierarchy. . :

• · · * server server server server server server..... Server. Server server server. Statistics Table 261 helps provide information with prefetch (PHI) instructions based on the current behavior of browser links from the perspective of the proxy or content server 20 associated with Statistics Table 261. Statistics Table 261 is able to track links of all communicating clients below it. hierarchy of proxy servers.

For example, in Fig. 1, the first statistic table 293 on the first level 50 proxy server 50 monitors the aggregate data access behavior of the first client 600 and the second client 603. Meanwhile, the first statistic table 293 on the second level three proxy server 55 monitors the aggregate data access behavior 700 and the fourth client 703. The first statistical table on the first level two proxy 40 tracks the aggregate behavior of the first client 600, the second client 603, the third client 700, and the fourth client 703. Although a lower-level proxy such as the first level 50 proxy three, it may be better able to track client interests 600, a lower-level proxy may not be able to get enough link statistics from a large enough sample of clients to provide meaningful information with prefetch instructions (PHI).

In a preferred embodiment, once an O object is requested from the content server 20, the server 20 provides initial information with instructions on PHI prefetch based on the information in its second statistical table 267. When passing through the object O of the hierarchy of proxy servers, any proxy server 24 Client 22 to modify the prefetch information (PHI) in the header of the object to adapt PHI to the local situation in the first statistics table 293 if there are enough local references to • • • • • • • • • • • • φ «• Φ 5

The first statistical table 293 may replace the second statistical table 267 based on factors such as: well-indexed interests or the strengths of a particular client by a downstream proxy.

In a preferred embodiment, the content server 20 maintains a second statistical table 267, which is a database of frequencies of access to client data 22 with respect to the requested information. The database could be extended to include data access frequencies of requesting proxy servers 24. Similarly, one or more proxy servers 24 maintain a first statistical table 293. For example, the statistical table 261 has a first field 383 with a first data structure 304 and a second data structure 306. it is shown that the first data structure 304 and the second data structure 306 are records; Each entry in the statistical table 261 consists of several fields containing parent object identifiers 301 (i.e., Objectld), first counts 302 (i.e., TCount), data pointers 303 to the access list (i.e., Alist).

The parent object identifier field 301 includes an object identifier. For example, the parent object identifier 301 includes an object URL for the Internet or related applications. The first count field 302 includes the number of times the parent object associated with the parent object identifier is requested according to the server observation. That is, the first count field 302 contains frequencies of actual requests for the requested objects. The first number 302 represents the frequency of accesses to the parent objects. The access list data pointer 303 includes the access list data pointer 370.

Statistical table 261 has a list of 370 accesses, which φ φ φ · · • φ · · · · · ·

For example, φ φφ includes a first access record 340, a second access record 350, a third access record 360, and a fourth access record 380. As shown, the parent object identifier associated with the first data structure 304 has an access list 370 that consists of a linked list of the first access record 340, the second access record 350 and the third access record 360. The next record data pointer field 313 includes a pointer to the next access record in the access list 370 associated with the identifier 301 of the particular parent object. The access list for the parent object identifier 301 associated with the second data structure 306 only includes a fourth access record 380.

Each record or data structure on the access list consists of several fields, including a child object identifier 310 (i.e., AObjectld), a second number 312 (i.e., RCount), and a data pointer 313 for the next record (i.e., Nxt). The data structures may be in the format of a general data structure, record, or field. As shown in FIG. 4, data structures are records that form a linked list in the access list 370.

In an alternative embodiment, the data format of the statistical table may include a primary field relating to a plurality of alternative secondary fields in the tree structure. The primary field would contain information related to the parent objects, and the secondary field would contain information about the child objects of the corresponding parent objects.

The filial object identifier field 310 contains the object object identifier (URL). Identifier 301 fefe fe

The fe feeder object is related to one or more identifiers 310 of the child objects on the access list. The filial object identifiers 310 identify potential prefetch candidates when actually referring to the parent object of the filial object. The second number 312 includes the number of times the child object is referred to by the parent object. In other words, the second count is the frequency with which the filial object is referenced immediately in time and subsequent to the prior reference to the associated parent object. The second number 312 represents the frequency of accesses to the filial objects.

The identifiers of the filial objects 310 in the access list 370 can be obtained dynamically by monitoring the actual behavior of the client references. For example, in HTML, an HTTP Web page may have links to other Web pages. These web pages marked with HTTP links are potential child objects for a (parent) web page containing HTTP links. When viewing a parent object, if the link (HTTP) contained in the parent object is clicked, the corresponding child object is requested. A child object can have more than one parent because the reference to the child object can be contained in more than one parent object. In the HTTP protocol, a request for a filial object contains a parent in its URL header as a reference object. Thus, the server can dynamically relate the following child object reference to its parent object (using the referencing object information in the child object header). If the client frequently clicks on the filial object or selects the filial object, the filial object may become a candidate for pumping or selection information.

0 ·

0 · · · · 0 0 • 4 * «« ·· • 0 0 0 0 • · 0 0

0 · 00

In addition, in addition to dynamically tracking browser behavior regarding links, static analysis or retrieving data from site logs can be performed periodically to derive object group information for statistic table 261. The retrieval algorithm identifies groups of objects referenced together to obtain potential candidates for pre-pumping for PHI. One way of obtaining data from web protocols to derive a link pattern is described in: SpeedTracer: A Web Usage Mining and Analysis Tool, by Kun-lung Wu et al., IBM Research Report 20895, May 1997 (see IBM Systems Journal. v37, nl, p.89105, 1998). The SpeedTracer algorithm provides information about frequently repeating groups of pages that are linked together in a user session and about frequent paths. The SpeedTracer algorithm is collecting detailed data that can reveal related links that are not immediately referenced together. It can also make better predictions of the next group of referenced objects based on the path to the object.

Other types of data retrieval algorithms can be used to determine data access patterns for statistical table 261. For example, other data retrieval algorithms include classification and grouping, which can also be used in web log analysis to retrieve link patterns. In addition, PHIs may also be supplied by the content provider based on its knowledge of object relationships. For example, PHIs may include, but are not limited to, fix packs and updates to download the required software, Java classes for the desired JAVA applet, and objects (such as GIFs) contained in the desired objects.

In a preferred embodiment, when collecting statistics, a distinction is made between the actual client request for the object

0 0 «0 ·

0 *

0

0 «0 0000 00

0

station from the request for pre-pumping the object. The first count 302 (i.e., TCount) and the second count 310 (i.e., RCount) in statistical table 261 represent actual references, not pre-pumping. The prefetch operation will not update the first statistical table 293 or the second statistical table 267, only the actual object references will be affected.

The prefetch information or prefetch information list may use different data structures to comment on the required information or objects. For example, prefetch information may be communicated between the requesting node and the server node using the included meta data. In an HTTP implementation, information exchange can be included as meta data in the object header using existing web protocols. PICS (Internet Content Selection Platform) determines how meta information is sent about electronic content. The PICS is useful for (a) commenting on required information, (b) pre-pumping selection information, pre-pumping candidates, or filial objects, and (c) confirming pre-pumping operations after pumping information.

PICS is known to ordinary experts as recommended by the Web Consortium Protocol. PICS was first used to send value-based classification labels such as the Exposure Rate associated with this content, but the format and meaning of meta information is quite general. In the PICS, meta information related to electronic content is grouped by the classification service or by the creator of the intended use of the information, and any number of categories or dimensions of information can be transmitted in one such group. Each category has a range of allowed values and for that to

this some of the content may have a single category or multiple values for a particular category. In addition, the meta information group (known as the PICS label) may contain expiration data. There are also means to allow the use of PICS labels on more than one part of the electronic content. Each PICS label for a specific piece of electronic content can be added or removed independently.

For example, an image file may be sent from a PICS label server whose classification service field indicates that it contains a value-based classification label according to the SafeSurf classification system. According to a preferred embodiment of the present invention, when passing through an enterprise proxy server, the image file may acquire a new updated category value for the PICS flag to reflect local classification service conditions. Therefore, the client computer will only see the value of the new PICS label category. The HTTP protocol has been extended so that its request and response headers support PICS. Technical institutions that define other common application protocols, such as NNTP, are now also considering adding PICS support. As part of these protocols, a list of the types of PICS labels required may be included in the request. The PICS also determines the query format for requesting PICS information from the central label server.

Here is a sample PICS label:

(PICS-1., 1 http: /the.rating.service labels for http: //the.content exp 1997.07.09T08: 15-0500 r (n4 with 3 in 2)) where n, sav are broadcast names for the different types of metainformation and the applicable values for this content are 4 (for η), 3 (for s) and 2 (for v). Only software that recognizes an http: //the.rating.service ID would know how to interpret these categories and values.

In a preferred embodiment, three different kinds of PICS labels are introduced. The first type of PICS label, referred to as the prefetch label (i.e., the P-label), uses the server node to provide a PHI. The second kind of PICS label, designated as the request label (i.e., the R-label), is used to request candidate objects for prefetch. A third type of PICS label, referred to as a reference label (i.e., an X-label), is used to provide feedback about pre-pumping efficiency based on which pre-pumped objects are actually referenced.

The prefetch label may include, but is not limited to, any combination of the following categories, including identifier category, probability category, size category, and caching category. The identifier category (ie, Category ID) has a value that carries the URL of the candidate for overdraft. The probability category (ie the PROB category) has a value that carries the expectations of the usefulness of the overdraft. In the preferred embodiment, the expected probability of reference is used. The probability of a reference indicates the probability of referencing the pre-drawn candidate object. The size category has a value that carries the size or memory requirements of the candidate for overdraft. The cached category has a value that carries information about any high-level proxy server that has a copy of the candidate prefetch object either in its first main cache 294 or in its first prefetch cache 296. In the preferred embodiment, only the closest identifier is identified. proxy north at a higher level.

The label requests may include, but are not limited to, the following categories, including the identifier category (i.e., the ID category). The identifier category value carries the URL of the object to be prefetched. In a preferred embodiment, if the (proxy or client) node wants to pump the proposed candidate prefetch object, the HTTP header is sent back to the proxy content server 20 using the required label to transmit the URL of the object to be prefetched. When the proxy server 24 receives a prefetch request from a node below in the hierarchy, it handles the request if the object is in its main or prefetch cache. Otherwise, it will forward the prefetch request to the next higher-level proxy in the hierarchy.

The link label may include, but is not limited to, the following categories, including the object identifier category (Object-ID category) and the referring object category (Referrer-ID category). The object identifier category has a value that carries the URL of the object being referenced. The Referral Object Identifier Category has a value that carries the URL of the object that contains in its PHI object specified by the Object Identifier Category value.

In a preferred embodiment, as soon as the prefetched object is actually referenced, an HTTP header request is sent back to the content containing server proxy hierarchy 20 using the link label to transmit the URL of the prefetched requested object and its requesting object. This type of request HTTP header is referred to below as a prefetched request message. As soon as the proxy server 24 receives the prefetched request message from the node below, it updates its first one in the hierarchy. statistics table 293 and forwards the request to the next higher-level proxy server.

Giant. 4 illustrates an example of server logic 268 that updates the second statistical table 267 on the content server 20. The update of the second statistical table 267 is triggered by the object request from the client 22. Preferably, the server 20 generates prefetch information for commenting or inserting into the object header before sending the requested object to the client 22.

Starting with block number 405, the content server 20 is waiting to enter. If a request for object O is received in decision block 410, the statistics update unit 252 is invoked or the second statistics update routine 269 in block number 415. In block number 420, a generating information generation unit 266 is called with instructions for prefetching or generating routine pre-pumping. A detailed example of a generating unit 266 or generating PHI routines will be further described with reference to FIG. 6. In block number 425, for example, PHIs are inserted in the object header of the desired object. The prefetch information may otherwise comment on the desired object or the required information in block 425. In the preferred embodiment, the PICS protocol may be used to comment on the desired object. The PHI is captured in the P-label where the category identifier value expresses the candidate's pre-pumping URL. At block 430, the requested object is returned to the requesting client or requesting proxy server. In decision block 435, if the received request message is a prefetched object (i.e., an HTTP request header with an X-label indicating that the prefetched object O is actually requested),

4b k e k * »*

I fi k k ****** The statistics update means 252 or the second statistics update routine 269 in the step 440 are invoked. For other input types that other than the scope of the present invention, such as an FTP (File Transfer Protocol) request, a corresponding other manipulator in block number 445 may be invoked.

Giant. 5 shows how the statistics update unit 252 updates one of said statistics tables 261. The statistics update unit 252 refers to the first statistics update routine 264 to update the first statistics table 293 or the second statistics update routine 269 to update the second statistics table 267, or how the first statistic table update routine 264, and the second statistic table update routine 269. The statistical table 261 refers to either the first statistical table 293 or the second statistical table 267, or both the first statistical table 293 and the second statistical table 267. The statistical update unit 252 first searches for information in the referencing object. The requested object is then placed on the access list or referral object's predefined list.

Beginning with block number 505, the statistical table 261 is updated to reflect that the object 0 is again requested by increasing the first number. In other words, in block 505, TCount (0) is incremented by one. If object O is not already in statistic table 261, the parent object identifier is inserted in statistic table 261, with TCount (0) initializing to one. The new parent object identifier replaces the most recently used entry in statistic table 261 if it is not in statistic table 261 if it is not in statistic table 261 no empty position available. In decision block 510, the referenced object information in the requested object is verified by, for example, verifying the object header of the desired object. For example, in the HTTP protocol, the referencing object is provided in the header to indicate which object contains the HTTP reference to the requested object. If a referencing object (R) is found in the header, a statistical table 261 is examined in step 520 to verify that object 0 is already on the access list of object R. If so, the second count is increased (i.e., RCount (0)) by one in block 530 for the desired object. Otherwise, in block 5Z5, the requested object (i.e., object O) is inserted into the access list of the parent object (i.e., object R) with a second count (i.e., RCount (O)) initialized to one.

Giant. 6 illustrates an example of a generating information generating unit 266 for prefetch information in the prefetch information list. The prefetch information list contains the identifiers of the child objects if the ratio of the second count to the first count exceeds the threshold of the instructions. The pre-pumping information list is a cleanup or filtered access list. That is, the generating unit 266 receives inputs from the statistical table 261 and filters the inputs to obtain an information list with instructions for pre-pumping.

The prefetch information generating unit 266 represents the prefetch information routine 266, starting at block 610. In block 610, the access list of the parent object (i.e., object 0) is checked to see if it is or is not. is not empty (ie whether Alist (O) is empty). If

4 »ί, ι i i <-‘

* F «'<*' ·» ^'11 * the access list is not empty, in block number 620, let Cj be another filial object (ie filial object identifier) found on the access list of the parent object (ie object 0).

In decision block 630, the probability of reference to the filial object Cj is compared to the threshold value of the instructions (i.e. ΤΗ), which is a predetermined threshold value (e.g. 0.75). In a preferred embodiment, the probability of reference Cj is defined as the ratio of the second count to the first count (ie, RCount (Cj) / TCount (0)). This ratio is the expectation of the probability that the child object (object Cj) will be referenced after it is referenced to the parent object (object O). If, in decision block 630, the probability of reference to Cj is greater than the instruction threshold (i.e. ΤΗ), then the identifier (Cj) of the filial object will be included in the PHI list at block number 640. In other words, if the ratio exceeds the instruction threshold , the son object identifier and associated information are placed on the list of information with prefetch instructions.

Generating unit 266 may require software subroutines or software components to perform comparison in block number 630. Generating unit 266 for generating prefetch information to the prefetch information list may include, in particular, computing means to calculate the probability of reference and probability comparison means link with threshold from the instructions.

In a preferred embodiment using the PICS protocol, the PHI information is stored in a P-flag where the URL is:

·.

The child object (Cj) takes the identifier category (i.e., the category ID value), its probability of reference and size are taken in the order of the probability value (i.e., PROB) and the value of the category size respectively.

In decision block 645, if the access list of object O has not yet been fully searched, block number 620 is executed again.

Various alternative criteria can be used to select pre-draw candidates from Statistical Table 261. For example, a moving average of the probability of reference over previous intervals can be used as a criterion. Furthermore, the procedure for selecting pre-withdrawal candidates can be performed recursively. If the child object (object Cj) is selected as a candidate for parental object prefetch (object O), any child object (object Cji) on the child object access list (object Cj) can be evaluated to determine whether it should be included in the prefetch the parent object list (object 0), if not already included. In decision block 630, the comparison unit or evaluation unit can now test whether the product RCount (Cj) / TCount (0) and RCount (Cji) / TCount (Cj) are greater than the threshold value of the instructions (TH).

Giant. 7 shows an example of operation of the client logic 244. Giant. 7 shows that after the object is requested, the client object request handler 247 is invoked. Otherwise, the pre-pump manipulator 241 can handle objects that are not required but must be stored in the second pre-pump cache 249 of the client 22.

Starting with block 710, client 22 waits for entry.

In decision block 720, if the received input is an object, the second pre-pump manipulator 241 is called in block * 730. In block 740, a call is made. the client object handler to return the object requesting the application to the client 22. If the object request is received in decision block 750, the client object request handler 247 is called at block 760. For other types of inputs that are not the main object of the invention (such as a enforceability request), a corresponding other manipulator may be invoked in block number 770.

Giant. 8 illustrates an exemplary operation of a pumping unit 250 comprising a first pumping manipulator 248 or a second pumping manipulator 241, or both the first pumping manipulator 248 and the second pumping manipulator 241. Briefly, the pumping unit 250 uses the pumping list generated by the generating unit 266 in FIG. to determine whether the infant objects referenced in the prefetch information list meet the storage conditions in one of the prefetch caches 298. The prefetch unit 250 calculates the prefetch value for each prefetch candidate or the identifier of the infant from the prefetch information list. The pumped value takes into account the probability of access to the filial object and the access cost of storing the filial object. The filial objects with the highest thresholds are captured first until the available space in one of the pre-pumping caches 298 is filled.

Starting with block number 805, let L be a list of PHI candidate prefetch objects. Candidate prefetch objects can be expressed based on the identifiers of the filial objects in the prefetch information list. Any pre-withdrawal candidate who “01 ···· ··

In the local cache (ie, the pre-pumping cache or the main cache) is removed from L. In block 810, the pre-pumping value (PV) of each object in the L. In a preferred embodiment, the value of PV is defined as the probability of reference multiplied by the access costs. Access costs are estimated based on the closest location capturing the candidate pre-pumping object or the filial object found in the PHI list. In practical terms, the filial objects are preferably identified in the PHI list by filial object identifiers rather than as whole filial objects in order to reduce storage requirements. The link probability optimally comes from the probability category value (PROB category), and the closest capture location in the cache comes from the capture category value in the PICS label. In block 820, a candidate pre-pumping object with the highest PV value is selected. In block number 830, the amount of available pre-pumping cache space to locate the candidate pre-pumping object (i.e., Oj) is determined, this space is either not being used or is occupied by objects with lower PV values that are only a fraction (eg one-half) of this pre-pumping candidate object being evaluated (ie Oj

Any storage occupied by an object marked as removable in one of the pre-pumping cache 298 is considered not currently in use. In decision block 840, one of the pre-pumping cache 298 is checked to see if there is enough space for the Oj. If so, in block number 850, the drawbar object is pumped to one of the pumping cache 298. At side 860, the drawbar is removed from the PHI list (i.e., L). In block number 870, if L is not empty, the step associated with block number 820 is restarted.

Although in the preferred embodiment, the individual are 4

4 · ♦ ··

0 0 0 0 0 • 0 0 0 · ·

4 0 0 · · · · 4 4 * · * objects pre-pumped one by one, more objects can be pumped together in one request. In block 850, the drawbar can be placed on a pre-pumping list. In block 870, if L is empty, then a prefetch request is issued with the entire prefetch list. Further, even if there is not enough storage space in the pre-pumping cache, a continuous pre-pumping list can be maintained, so that as soon as storage is free, further pre-pumping can be initiated.

Using the HTTP protocol, the communication session may remain open during pre-pumping to reduce communication overhead. There is no need to re-establish a session for each pre-pumping.

Giant. 9 shows an example of operation of the client object request handler 247. In short, the client object request handler 247 first searches for the second main cache 246 and secondly searches for the second prefetch cache 249. If the object is neither in the second main cache 246 nor in the second prefetch cache 249, an object request is sent to the server. If the object is in the second prefetch cache 249, the request for the prefetch object is sent to one of the servers to indicate that it is actually referenced to the prefetch object. Then, a second pumping manipulator 241 and a client object manipulator are used.

Beginning with decision block 905, if the desired object O is found in the second main cache 246, a second prefetch manipulator 241 is invoked at block number 925 to initiate appropriate preload operations based on the PHI associated with object 0. In block number 930, a client manipulator is invoked objects to return the requested object to the application on the client. . In decision block 910, if the requested object 0 is found in the second pumping cache 249, a request message is sent to the content server 20 in the content block at block 920 so that its second statistical table 267 can be updated to capture the actual referenced object. . In fact, when propagating a request for a prefetched object of the proxy server hierarchies to the content server 20, the second statistical table 267 at each intermediate proxy server is also updated. In block 910, if the object is not in the second pumping cache 249, the object request is sent to the proxy content server 20 in block number 915.

Request messages for pre-pumped objects can be batched. That is, the object pumping object list can be maintained, and a composite request message for the pumping object objects is sent at a higher level on a regular basis to confirm a reference to all objects in the pumping object request list.

Giant. 10 shows an example of operation of the proxy server logic 295. In short, the input is sorted by whether the input is an object request, an object transfer, or a reference to a pre-pumped object. Three different manipulators or software routines are available depending on the input: proxy object request handler 283, proxy object handler 284 and pre-puff object request handler 285.

Beginning with block number 1005, proxy server 24 waits for input. If a request for an object is received in decision block 1010, the request for object 0 verifies in the block

0

0

0 0

0000 ·· • «• 00 0 • 0« 0 ·· ··

1015 proxy server 24 whether there is already a pending request for this O object. A pending request may exist due to a request for this O object to be pumped out by this proxy server 24 or an earlier request for an O object originating on another proxy server node below servers. If there is no pending request for object O in block number 1015, the proxy object handler 283 is invoked in block 1020. In decision block 1025, if the input is an object (from a higher level proxy), the proxy handler 284 is invoked in Otherwise, at block 1040, if the prefetch object request message is received, the prefetch object message handler 285 is invoked at block 1045. For other types of inputs that are not the main object of the present invention (such as FTP request), a corresponding other manipulator in block 1060 may be invoked.

Giant. 11 shows an example of the operation of the proxy object handler 283. In short, if the objects are in the pumping cache, the object is returned or sent to the requesting client or requesting proxy server. Thereafter, if the requested object was a prefetch request, the requested object is marked as removable from the first prefetch cache 296 of the proxy server 24. If no prefetch request has been provided for the requested object, a prefetch object request message is sent to the content server 20. However, a request for a prefetched object is only sent if the requested object is sent from the first prefetch cache 296. If the requested object is not in either the first prefetch cache 296 or the first main cache 294, the request for the object is sent to another proxy. To server 24 or to server 20, or to server 24 or server 20 with content. The requested objects found in the first main cache 294 are returned or sent to the requesting client or proxy server 24, and the first statistics table 293 is updated if the request was not a prefetch request.

Starting with decision block 1105, if a desired O object is found in the prefetch cache, the O object is returned to the requesting node in block 1130. In decision block 1135, if it is a prefetch request, the O object in the first prefetch cache 296 is marked as removable. deleting objects from the first pre-pumping cache 296 creates space for future pre-pumping because pre-pumped object O has now been pre-pumped by some nodes below in the proxy server hierarchy 24. Otherwise, in block 1140, the cache manager is invoked to move the O object from to the first main cache 294 because the O object is actually referenced. At block 1160, a prefetched object request message is sent to the server 20 containing the content of the proxy server hierarchies. At block 1170, a statistics update routine is invoked to update the local first statistical table 293 to capture the actual reference to the pre-pumped O object. In decision block 1110, if the O object is not found in the first main cache 294, In decision block 1115, if the object request is not a prefetch request, the first statistics update routine 264 is invoked in block 1120 to update the local first statistics table 293 to capture the actual object reference. At block 1180, the O object is returned to the requesting node.

This to this to this to this to this to this to this

Giant. 12 shows an example of operation of a pre-pumped object request handler 285. The pre-pumped object request handler 285 first determines whether or not the object is in the first pumped cache 296. If the object is in the first prefetch cache 296, the cache manager routine is invoked before the prefetch object request message is forwarded. If the object is not in the first pumping cache 296, the request message for the pumped object is forwarded.

Starting at step 1205, the first statistics update routine 264 is called to update the local first statistical table 293 to capture the actual request for the prefetched object (0). In decision block 1210, if object 0 is in the first prefetch cache 296, the cache manager at block number 1215 is called to move object O from the first prefetch cache 296 to the first main cache 294 because the object was actually referenced. At block 1220, the prefetch object request message is forwarded to the next higher level proxy server.

Giant. 13 shows an example of operation of a proxy object manipulator 284. The proxy object handler 284 initially invokes the pre-pumping update unit 291 or the information refresh routine with instructions for pumping uniformly without exception. Requests for prefetched objects are treated differently depending on whether or not the prefetched object was requested by the downstream server. If the pre-pumped object was requested by the down-level server, the object returns to the down-level server; otherwise, the preload cache manager is invoked. If no pre-pumped object is required, the object returns to the requesting proxy server 24 or client and invokes the first update routine 264 · · • 0 0

0 0 ··

0 ·

0000 ··

0 00 · 0 invokes update

- 57 statistics.

Starting at block number 1305, the PHI routine or pre-pump update means 291 to update the PHI object O. In block number 1310, if the received object is not a pre-pumped object, the first pre-pump manipulator 248 is invoked at step 1315. in the hierarchy). In the preferred embodiment using the PICS protocol, the value of the capture category in the P-label is updated if the corresponding prefetch candidate (determined by the category identifier value) is prefetched by this proxy server 24. In block 1325, the Cache Manager is invoked to store the object in the main cache. In block number 1355, the statistics update routine is called. In block 1330, if the received pumped object is requested by a lower-level node in the hierarchy, the object returns to the requesting object in block number 1350. Otherwise, it is requested by the current node and the prefetch cache manager in block number 1340 is called to store the object in the prefetch cache that the necessary replacement is made to create space for the object.

Giant. 14 shows an example of update pumping means 291 or PHI update routines. The PHI update routine compares the local number of requested objects with a threshold number. If the required objects exceed the first minimum threshold, they are subjected to a second minimum threshold test. Threshold values can be set based on experimental results. If the local count is less than the first minimum threshold, the pre-pumped information information list is retained. If the local count is greater than the first threshold but is not greater than the second threshold, the prefetch information list is modified.

Starting with decision block 1405, if the local number (i.e., TCount) of the object (0) in the local first statistical table 293 is not greater than the first minimum threshold (i.e., CTM), the original PHI in the O header of the object is retained. due to the fact that there is not enough object references in the lower hierarchy of proxy servers 24 to guarantee any update. In decision block 1415, if the local number (i.e., TCount) of the object (0) in the local statistical table 261 is greater than the second minimum threshold (i.e., TCH), the original PHI in the object header is ignored and the generating PHI routine in block 1420 to generate PHI based on the local first statistical table 293. This happens because there are a sufficient number of object references below in the hierarchy of proxy servers 24 to generate PHI based on local behavior. Otherwise, the PHI modifier in block number 1425 is called to modify the probability category value by taking the average of the local link probability estimate and the header value (set by the higher level hierarchy) for each object in the PHI list.

The prefetch scheme also works if some of the proxy servers 24 do not maintain the first statistics table 293 and do not follow local link patterns. Non-following proxy servers only accept the probability, i.e., the category value (i.e., PROB) in the .PHI sent down from the top-level proxy or content server 20.

Scheme of pre-pumping environment of proxy servers, common proxy servers, servers, also work where some of which in proxy heterogeneous servers are not understand pre-pumping.

They are not participating in the cooperation. These common proxy servers neither interpret object headers to initiate pumping operations nor maintain the first statistical table 293. Common proxy servers only send meta data (eg, PICS header header) to the next-level proxy server object, or store meta data with the object if decides to capture the cached object locally.

Even without a proxy server hierarchy, the present invention can be applied to any network or client server environment. The sending node can follow the link patterns, derive a PHI, and include them in the object header. Further, the receiving node of the object may cache the PHI with the object in its cache. After referencing the object, prefetch operations can be initiated based on stored PHIs and local factors such as cache size and access costs as described above.

Saving the PHI with the captured object provides another opportunity for pre-pumping. Events such as making more free space available, occurring additional links, or accepting pre-pumped objects can be used to initiate further pre-pumping by examining the PHI of the captured objects in the cache. The prefetch operation is not limited to the moment when an object is requested from the server as in the sender initiated access.

In a preferred embodiment, the general principles of pre-pumping for web and proxy servers have been described, however, those skilled in the art will appreciate that the present invention is applicable to any kind of situation where objects to be pumped have similar features and is not necessarily limited to Internet use. on the website.

• φ * · · · ·

Further, while a preferred embodiment of the present invention is for cooperative pre-pumping between parent and son proxies in a hierarchy, it can easily be adapted to include collaboration between partner proxies. For example, if no proxy server in the hierarchy has detected the requested object or pre-pumping candidate above, the proxy can also query partner proxies.

Represented by:

Dr. Petr Kalenský v.r.

....----lawyer

120 00 Prague 2, Halkova 2

Claims (36)

PATENT CLAIMS A method for prefetching information from a content server (20) via a communication network (25), said communication network comprising one or more proxy servers (24) and one or more clients (22), the method comprising the steps of: requesting (100), on the client, information from the content server via at least one proxy server; establishing (102, 104), on the server, information with instructions for prefetching commentary information that is likely to be requested by the client following the requested information, based on past draws or accesses by said clients; commenting (105), on the server, the requested information, the instructions with prefetching and returning the requested information and information with prefetching together to the client via at least one proxy server; and prefetching (108), on the client or at least one proxy server, information based on prefetch information and requested information, thereby better accessing the prefetched information. The method of claim 1, wherein the requested information comprises the desired objects and wherein the pre-pumped information comprises candidate pre-pumped objects. Method according to claim 2, characterized in that the step of establishing information with instructions regarding pre-pumping 27 79 274 * 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 tracking data patterns of references of requested information associated with clients; organizing reference data patterns into object identifier groups, wherein the object identifier groups are organized according to the relationships between the requested objects and the candidate pre-pumping objects; identifying which of the groups have sufficient relationships between the pre-pumping candidate objects and the required objects to ensure the pre-pumping of the pre-pending candidate objects as pre-pumped information, The method of claim 3, wherein the steps of tracking and organizing reference data patterns include the steps of: establishing databases for storing reference data patterns in proxy servers; arranging fields in each of the databases, the fields comprising identifiers ^; objects and number of objects, wherein the object identifiers distinguish between the required objects; object counts indicate the number of times the requested objects were requested as observed by one of the proxy servers; and associating access lists to databases, each access list comprising one or more pre-pumping candidate objects associated with each desired object. The method of claim 3 or 4, wherein the steps of tracking and organizing data link patterns further comprise the steps of: establishing a database defining the relationship between the requested objects and the candidate prefetch objects; and fefefe fe · fe · * · «· fefe tracking in access statistics from the database to requested objects and candidate prefetch objects; wherein the access statistics include the frequency of accesses to the parent objects of the requested objects and the frequency of accesses to the filial objects of the candidate pre-pumping objects; the frequency of accesses to parent objects is the number of times a particular object is requested by at least one of the clients; the frequency of accesses to the filial objects is the number of times that one or more candidate objects are actually required to be pumped immediately after access to a desired object. 6. The method of claim 5, further comprising the step of selecting a pre-pumping list of candidate pre-pumping objects based on the ratio of the access rate to the filial objects to the access rate to the parental objects associated with the access frequency to the filial objects. pre-pumping objects with a ratio that exceeds the probability threshold. Method according to any one of claims 2 to 6, characterized in that the step of pumping information comprises the steps of: prefetching a subset of prefetch candidate objects received at one of the proxy servers or one of the clients; wherein the subset of pre-pumping candidate objects is selected based on the available storage space at one of the proxy servers. Method according to any one of claims 2 to 7, characterized in that the step of pumping the information is 0 0000 0000. 0 00 00 0 «00 00 contains the steps: prefetching a subset of prefetch candidate objects received at one of the proxy servers or one of the clients; wherein the subset of pre-pumping candidate objects is selected based on the access time at one of the proxy servers. The method of any one of the claims, wherein the pre-pumped desired object comprises referenced Internet data 2 to the object and where 8, a The object of interest is a link associated with a HTTP pre-pumped object with Internet data, wherein the server identifies the pre-puffed object-to-object relationship via the universal object locator HTTP protocol or URL stored in the object's object header. A method according to any one of claims 2 to 9, wherein the step of commenting on the requested information comprises the step of placing information with instructions about prefetching in a prefetching flag having an Internet Content Selection Platform (PICS) format or a flagging protocol compatible with PICS format. The method of claim 10, wherein the Internet content selection platform format (PICS) comprises an object identifier category for storing the identity of the pre-pumped object that is subsequently referenced and a reference object identifier category for storing the desired object associated with the pumped object, and the method further. includes the step of returning an object identifier category to the content server to identify all « to * to the candidate pre-pumping objects currently referenced. Method according to claim 1 or 2, characterized in that the step of establishing information with pre-pumping instructions comprises the steps of: identifying the pattern of client data references based on past draws or past accesses to the requested information; and defining information with instructions for prefetching from the data link pattern. The method of any one of the preceding claims, wherein there is a hierarchy of proxy servers, the hierarchy comprising at least one proxy server representing the sending node and at least one proxy server representing the receiving node, and the method further comprising the steps of: sending information with instructions about prefetching from the sending node to the receiving node; and adjusting the initial pumping information to final pumping information, wherein the initial pumping information is determined by the sending node; final information with instructions on pre-pumping is determined by the receiving node; final information with instructions on pre-pumping is used as a basis for the final decision on pre-pumping. The method of claim 13, wherein the step of pumping information is initiated by the receiving node. A method according to any one of claims 1 to 12, wherein: - OC · 4 ·· 0 * * 9 * «•« 0 0000 0 * 00 0000 0 »* 0 _M *» * «characterized by the steps of: organizing proxy servers into a hierarchy of servers, the hierarchy having multiple levels of proxy servers, the multiple levels being determined based on the proximity of each of the proxy servers to the network, the highest level being closest to the network; and interpreting and updating information with instructions regarding prefetching the transferred hierarchies from the proxy servers to the clients. The method of claim 15, wherein the proxy server updates the prefetch information when local references to the requested information exist and if the number of servers at the local level exceeds a minimum threshold number. The method of claim 15 or 16, wherein the prefetch information is updated based on the cached interception status in the hierarchy of proxy servers. A system for prefetching information from a content server (20) through a communication network (25), the communication network comprising one or more proxy servers (24) and one or more clients (22), the method of the system comprising: means for requesting (100), on the client, information from the content server through at least one proxy server; means for establishing (102, 104), on the server, information with prefetch instructions indicating a likely request for information by the client following the requested information, based on past draws or φ φ Φ φ φφ φ φ · φ φ φφ φφ client access; means for commenting (105), on the server, the requested information with instructions for prefetching and returning the requested information and information about prefetching together to the client via at least one proxy server; and means for prefetching (108), at the client or at least one proxy server, the server information based on the prefetch information and the requested information; thus making the pre-pumped information more accessible. The processing system of claim 18, wherein the requested information comprises the desired objects, and wherein the selection information comprises the candidate prefetch objects; and wherein each of said proxy servers and at least one of the clients has a memory having a logical and / or physical separation between the main cache and the prefetch cache, where the prefetched sample information is stored in the prefetch cache. The processing system of claim 19, wherein the pre-pumping means pre-pumping objects and stores the pre-pumped objects in a pre-pumping cache based on a priority scheme so as not to exceed the available pre-pumping cache memory. the pre-pumping value is based on the individual or aggregate probability of reference to the pre-pumped objects by one or more clients. The processing system of claim 20, wherein the pre-pumping value is * to · to • ♦ to * to - this is based on the expected likelihood of access for a particular client to access the pre-pledge object specified in the Pre-pumping Information and Object Access Cost based on the amount of storage required space for storing selected pre-pumping candidate objects. A processing system according to claim 20 or 21, wherein the pre-pumping means comprises a pre-pumping manipulator comprising computing means for calculating the pre-pumping value and evaluation means for evaluating the pre-pumping value calculated by the computing means; the computing means calculates a pre-pump value for each pre-pump object identifier in the pre-pump information list; the evaluating means evaluates the pre-pumping values of the multiple pre-pumping objects and prefers caching the pre-pumping candidate objects associated with the highest pumping values provided in the pre-pumping information. 23. The processing system of claim 22, wherein the pre-pump means comprises a first pre-pump manipulator on at least one of the proxy servers and a second pre-pump manipulator on at least one of the clients. The processing system of any one of claims 19 to 23, further comprising a client object request handler stored in the memory of one of the clients, wherein the client object request handler searches in the main cache and prefetch. Cache the requested object before requesting the desired object from the proxy server or from the network, with the client object request handler notifying the content server or proxy server if the object is located in the pumping cache by generating a request message for the pumping object of the server, indicating that the client is actually accessing the pumping object. The processing system of any one of claims 19 to 24, wherein at least one of said proxy servers comprises a pre-pumped object request message handler to forward the pre-pumped object request message after invoking the cache manager routine if the requested object is located in the pre-pumping cache. A content server or proxy server for use in a data processing system according to any one of claims 19 to 25, wherein the requested information comprises desired objects and wherein the prefetched information comprises candidate prefetch objects, the server comprising: a statistical table for tracking statistics of accesses to requested objects and candidate pre-pumping objects; the access statistics includes the frequency of accesses to the parent object of the requested objects and the frequency of accesses to the filial objects of the candidate pre-pumping objects; the frequency of accesses to the parent object is the number of times that at least one of said clients refers to a particular object; the frequency of accesses to the filial objects represents the number of times that one or more candidate objects were requested to be pumped immediately after access to a particular of the requested objects; and generating means for generating information with instructions for prefetching based on the information in the statistical table. 27. The server of claim 26, wherein the generating means selects a prefetch list of candidate prefetch objects based on the ratio of the access rate to the filial objects to the access rate to the parental objects in conjunction with the access frequency to the filial objects, the prefetch list containing only the candidate objects. pre-pumping objects with ratios exceeding the probability threshold. 28. The server of claim 26, wherein the generating means receives inputs of first counts, second counts, filial object identifiers, and parental object identifiers from the statistical table, the generating means comprising evaluation means for evaluating the access relationship between the parent objects and their associated objects. The filing means places the identifiers of the filed objects in the prefetch information list when referring to filed objects with adequate frequencies immediately and sequentially in front of the client references to the corresponding parent objects. The server of claim 28, wherein the generating means further comprises computing means for calculating reasonable frequencies based on the ratio of accesses to the filial objects to the accesses to the corresponding parent objects. F ··· ··· · · · fcfc ·· The server of any one of the claims, further comprising: statistics update means for statistical filial statistics 26 to 29, updating the required reference table means based on the actual object; wherein the update first searches for the identity of said parent objects, wherein the referring object or referrer is referenced before the filial object that is actually requested, wherein the actually requested filial object has its corresponding second count updated in the statistics table. 31. The server of claim 30, wherein the statistics update means updates the statistical table upon receipt of the pumping object request message from the pumping object request handler indicating that the pumping object has actually been referenced. The server of any one of claims 26 to 31, wherein the server is a proxy server and further comprises:. updating pre-pumping means for receiving and updating the information list with instructions for pre-pumping; the pre-pump update means compares the first counts with the first local threshold counts, the pre-pump update means generating generating resources for each of the filial object identifiers for which the first counts exceed the first local threshold counts, does not exceed the first local threshold counts. ··· ·· ryzna cnjια The server of claim 32, wherein the update pumping means compares the first counts with the first and second local threshold counts, and (i) maintains the original information list with instructions for prefetching if the first counts do not exceed the first local threshold counts; (ii) modifies the original pre-pumping information list when the first numbers exceed the first local threshold numbers but not the second local threshold numbers; and (iii) replace the original list of information with instructions for pre-pumping if the first counts exceed both the first and second threshold counts. 34. The server of claim 32 or 33, wherein the communication network comprises a hierarchy of proxy servers and the server further comprises a proxy object manipulator for returning the desired object to a lower level proxy server in the hierarchy or to the client that requested the desired object, the proxy object handler returns the requested object and updates the statistics table accordingly if the requested object is not a pumped object. 35. The server of claim 34, further comprising: a preload cache manager to manage the preload cache; wherein the proxy object handler returns the requested object from the pre-cache to the requesting client or proxy and marks the object as removable from the pre-cache if the object was requested based on the pre-draw request; the object proxy handler sends an object request to another server if the requested object is not in the main cache or in the preload cache, and the object proxy handler accordingly • 0 0000 updates the statistics table if the requested object is not associated with the prefetch request and the requested object is located in the pre-pumping cache or the main cache. A content server for operation in a communications network (25), wherein the communications network comprises one or more proxy servers (24) and one or more clients (22), the server comprising: means for receiving (100), from the client, a request for information via at least one proxy server; means for establishing (102, 104) information with prefetch instructions commenting on the information likely to be requested by the client following the requested information based on past withdrawals or client accesses; means for commenting (105) the requested information with instructions for prefetching and returning the requested information and information about prefetching together to the client via at least one proxy server; so that the client or at least one proxy is able to draw information to the server based on information with instructions about the draw and the requested information, thereby making the pre-drawn information faster available.