CA2216346C - Inter-cache protocol for improved web performance - Google Patents
Inter-cache protocol for improved web performance Download PDFInfo
- Publication number
- CA2216346C CA2216346C CA002216346A CA2216346A CA2216346C CA 2216346 C CA2216346 C CA 2216346C CA 002216346 A CA002216346 A CA 002216346A CA 2216346 A CA2216346 A CA 2216346A CA 2216346 C CA2216346 C CA 2216346C
- Authority
- CA
- Canada
- Prior art keywords
- web
- cache
- objects
- web cache
- caches
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Abstract
On the Internet, different caches may contain copies of objects that have been copied from originating servers when they were accessed by users. Interconnected caches may have different objects stored thereon that might at some time be requested by a client terminal that is connected to a cache other than the one on which the object is stored. Rather than awaiting a request for a particular object and then querying each neighbor cache to determine whether a copy of the requested object is stored thereon, and then downloading the requested object if it is found, information about the contents of the neighbor caches is exchanged between these caches so that when a request for an object is received, the object can be retrieved from the cache in which it is stored. In the alternative, the object may be retrieved from the originating server if, for example, the object stored in a cache is stale based on the date and time it was last modified in the cache.
Description
INTER-CACHE PROTOCOL FOR
IMPROVED WEB PERFORMANCE
Technical Field This invention relates to data communications and computer networking, and more particularly, to the transfer of digital information on packet data networks such as the Internet, between caches.
Background of the Invention In a transaction on the World Wide Web between a client terminal and a Web server in which the client terminal retrieves a Web object from a server connected on the Internet, the client terminal normally accesses the Internet through an Internet Access Service Provider (IASP). Such an object may be one or more pages of textual information, a picture, a sound clip, a video clip, a JAVA applet or other software, any combination or the former, or anything that is capable of being transmitted digitally over the Internet to a client terminal.
The term "object" will be used hereinafter to include all of the foregoing. A cache, located within the IASP network, functions as an intermediary in transactions involving the retrieval of such Web objects from servers by a client terminal. In particular, in its simplest form, a cache within the IASP saves a copy of a retrieved object for itself when the object is moved from the server to the requesting client terminal.
This caching operation is transparent to the user and, under normal circumstances, does not incur any significant delay due to the copying operation which is performed simultaneously as the object is retrieved from the server and delivered to the client terminal.
Advantageously, the cache within the IASP network can satisfy subsequent requests for those objects that are stored therein, thereby obviating the necessity of retrieving the object from the originating server on the Internet. This reduces the delay as perceived by the user to access the object and further, saves bandwidth on links that connect the IASP network to the Internet. FIG. 1 is a block diagram of a prior art network in which plural client terminals, such as 101 and 102, are connected to a cache 103 within IASP 104. Cache 103, in turn, is connected to a server 105 connected to the Internet 106. By storing an object from server 105 in cache 103 when it is first retrieved by client 101, subsequent requests for that same object by client 101, or any another client connected to cache 103 within IASP 104, such as client 102, can be satisfied directly from cache 103. IASP 104 likely also includes a second or more caches, such as cache 107, which serves other clients connected to that same IASP, such as 108 and 109. The objects stored in this second cache 107, or other caches within IASP 104, but not shown, could be used to serve the clients attached to the first cache 103, if the caches communicate with each other.
Generally, in the prior art when a request for an object is received, discovery of objects on other than the cache to which the requesting client is attached is done by explicit querying at the time when the request for a particular object is made. That is, whenever a request from a client cannot be satisfied by the cache to which the client is connected, a plurality of requests are sent out to neighboring caches asking them whether they have a copy of the desired object stored in their memory.
The steps of querying a plurality of caches, waiting for a reply, and then downloading a copy of the object from the cache that has the object or retrieving a copy of the object from the originating server of the object if the object cannot be found in a neighboring cache, may impart a delay to the retrieval process that is unacceptable to the requesting user.
Furthermore, the flooding of requests to all neighboring caches in response to each request for an object can be a wasteful use of network bandwidth, as well as draining the caches' computing resources. Even furthermore, the copy of an object as it exists on a neighboring cache may differ from the object as it then exists in the server from which it originated. This will result when the object in the server is modified after the initial request for the object was made and a copy of the object stored in the neighboring cache. Thus, the object available to a requesting cache from a responding cache may not be current and may be a stale or outdated version of the object as it currently exists in the server, and thus not suitable to be supplied to a client requesting that object.
Summary of the Invention In accordance with the present invention, a cache is provided information about what objects its neighboring cache carries, and other information about those objects in the neighboring cache, such as the times these objects were modified in the neighboring cache, the type of content of these objects, and the sizes of these objects. The latter information may be useful for planning disk space usage. This information gathering process is distinct from the actual retrieval of an object from a neighboring cache, or in the alternative, from the actual server carrying the most recent version of the object, and is performed asynchronous to a request from any client for the object.
Web caches update each other about Web objects in their cache through various mechanisms. In a first mechanism, a requesting cache queries a responding cache for information about all or a subset of objects in the responding cache that have been modified since a given date and time. "Modified" as used herein includes objects that may have been updated or created in that cache since the given time. In a second mechanism, a responding cache informs the requesting cache periodically about modifications to objects in which that the requesting cache had previously express interest. In third and fourth more intelligent mechanisms, neighboring caches maintain state-information on what objects the other caches have based on the messages previously sent to it. In particular, in the third mechanism each 5 cache maintains state-information on objects in every neighbor cache with which it communicates. The fourth mechanism is applicable to the case where numerous peering caches exist, and each of which is interested in each other cache's content. Information that a cache has collected about the content of other caches is then used in together with the content of its own cache for compiling the messages sent to any given cache.
In accordance with one aspect of the present invention there is provided in a system comprising at least a first and a second interconnected Web caches on a packet data network, which each stores Web objects that can be retrieved by a plurality of client terminals connected to either Web cache, the Web objects stored in the first and second Web caches being copies of Web objects received from Web servers connected on the packet data network, a method comprising the steps of: receiving a signal at the second Web cache from the first Web cache that is indicative of a request for information relating to Web objects stored in the second Web cache; and transmitting a signal from the second Web cache to the first Web cache that provides the requested information relating to Web objects stored in the second Web cache.
Brief Description of the Drawinus FIG. 1 is a block diagram of a prior art network showing two caches connected within an Internet Access Service Provider, interconnecting client terminals and a server within the Internet;
FIG. 2 shows the interactions between a requesting cache and a responding cache along a time-line in accordance with a requesting cache-initiated notification mechanism of the present invention;
FIG. 3 shows the interactions between a requesting cache and a responding cache along a time-line in accordance with a responding cache-initiated notification mechanism of the present invention;
IMPROVED WEB PERFORMANCE
Technical Field This invention relates to data communications and computer networking, and more particularly, to the transfer of digital information on packet data networks such as the Internet, between caches.
Background of the Invention In a transaction on the World Wide Web between a client terminal and a Web server in which the client terminal retrieves a Web object from a server connected on the Internet, the client terminal normally accesses the Internet through an Internet Access Service Provider (IASP). Such an object may be one or more pages of textual information, a picture, a sound clip, a video clip, a JAVA applet or other software, any combination or the former, or anything that is capable of being transmitted digitally over the Internet to a client terminal.
The term "object" will be used hereinafter to include all of the foregoing. A cache, located within the IASP network, functions as an intermediary in transactions involving the retrieval of such Web objects from servers by a client terminal. In particular, in its simplest form, a cache within the IASP saves a copy of a retrieved object for itself when the object is moved from the server to the requesting client terminal.
This caching operation is transparent to the user and, under normal circumstances, does not incur any significant delay due to the copying operation which is performed simultaneously as the object is retrieved from the server and delivered to the client terminal.
Advantageously, the cache within the IASP network can satisfy subsequent requests for those objects that are stored therein, thereby obviating the necessity of retrieving the object from the originating server on the Internet. This reduces the delay as perceived by the user to access the object and further, saves bandwidth on links that connect the IASP network to the Internet. FIG. 1 is a block diagram of a prior art network in which plural client terminals, such as 101 and 102, are connected to a cache 103 within IASP 104. Cache 103, in turn, is connected to a server 105 connected to the Internet 106. By storing an object from server 105 in cache 103 when it is first retrieved by client 101, subsequent requests for that same object by client 101, or any another client connected to cache 103 within IASP 104, such as client 102, can be satisfied directly from cache 103. IASP 104 likely also includes a second or more caches, such as cache 107, which serves other clients connected to that same IASP, such as 108 and 109. The objects stored in this second cache 107, or other caches within IASP 104, but not shown, could be used to serve the clients attached to the first cache 103, if the caches communicate with each other.
Generally, in the prior art when a request for an object is received, discovery of objects on other than the cache to which the requesting client is attached is done by explicit querying at the time when the request for a particular object is made. That is, whenever a request from a client cannot be satisfied by the cache to which the client is connected, a plurality of requests are sent out to neighboring caches asking them whether they have a copy of the desired object stored in their memory.
The steps of querying a plurality of caches, waiting for a reply, and then downloading a copy of the object from the cache that has the object or retrieving a copy of the object from the originating server of the object if the object cannot be found in a neighboring cache, may impart a delay to the retrieval process that is unacceptable to the requesting user.
Furthermore, the flooding of requests to all neighboring caches in response to each request for an object can be a wasteful use of network bandwidth, as well as draining the caches' computing resources. Even furthermore, the copy of an object as it exists on a neighboring cache may differ from the object as it then exists in the server from which it originated. This will result when the object in the server is modified after the initial request for the object was made and a copy of the object stored in the neighboring cache. Thus, the object available to a requesting cache from a responding cache may not be current and may be a stale or outdated version of the object as it currently exists in the server, and thus not suitable to be supplied to a client requesting that object.
Summary of the Invention In accordance with the present invention, a cache is provided information about what objects its neighboring cache carries, and other information about those objects in the neighboring cache, such as the times these objects were modified in the neighboring cache, the type of content of these objects, and the sizes of these objects. The latter information may be useful for planning disk space usage. This information gathering process is distinct from the actual retrieval of an object from a neighboring cache, or in the alternative, from the actual server carrying the most recent version of the object, and is performed asynchronous to a request from any client for the object.
Web caches update each other about Web objects in their cache through various mechanisms. In a first mechanism, a requesting cache queries a responding cache for information about all or a subset of objects in the responding cache that have been modified since a given date and time. "Modified" as used herein includes objects that may have been updated or created in that cache since the given time. In a second mechanism, a responding cache informs the requesting cache periodically about modifications to objects in which that the requesting cache had previously express interest. In third and fourth more intelligent mechanisms, neighboring caches maintain state-information on what objects the other caches have based on the messages previously sent to it. In particular, in the third mechanism each 5 cache maintains state-information on objects in every neighbor cache with which it communicates. The fourth mechanism is applicable to the case where numerous peering caches exist, and each of which is interested in each other cache's content. Information that a cache has collected about the content of other caches is then used in together with the content of its own cache for compiling the messages sent to any given cache.
In accordance with one aspect of the present invention there is provided in a system comprising at least a first and a second interconnected Web caches on a packet data network, which each stores Web objects that can be retrieved by a plurality of client terminals connected to either Web cache, the Web objects stored in the first and second Web caches being copies of Web objects received from Web servers connected on the packet data network, a method comprising the steps of: receiving a signal at the second Web cache from the first Web cache that is indicative of a request for information relating to Web objects stored in the second Web cache; and transmitting a signal from the second Web cache to the first Web cache that provides the requested information relating to Web objects stored in the second Web cache.
Brief Description of the Drawinus FIG. 1 is a block diagram of a prior art network showing two caches connected within an Internet Access Service Provider, interconnecting client terminals and a server within the Internet;
FIG. 2 shows the interactions between a requesting cache and a responding cache along a time-line in accordance with a requesting cache-initiated notification mechanism of the present invention;
FIG. 3 shows the interactions between a requesting cache and a responding cache along a time-line in accordance with a responding cache-initiated notification mechanism of the present invention;
FIG. 4 shows the interaction between two caches in which each cache maintains separate state-information for each of the other neighbor caches with which it communicates;
FIG. 5 shows the interaction between two caches in which each cache maintains single-state information for the entire caching system;
and FIG. 6 shows the message interaction between a requesting cache and a responding cache for a specific implementation of a requesting cache-initiated mechanism in accordance with the present invention.
Detailed Description As noted, the present invention is a mechanism by which Web caches update each other about what Web objects are in their cache.
Update notification is distinct from actually sending the modified Web objects. The notification typically involves information from which the receiving cache can determine what Web objects are stored in the neighboring cache, but also information such as the time when the object in the neighboring cache was last modified. Optionally, the notification may contain other information that might be useful to the requesting cache such as the size, in bytes, of the object to enable the requesting cache to plan its disk space usage, and the type of contents of the object.
To distinguish between the two caches involved in the transfer of information about the objects stored in each, the cache that desires information about the contents of its neighbor cache is referred to hereinafter at the Requesting Cache (RQC), and the neighbor cache that sends out information about what it stores is referred to as the Responding Cache (RSC). The mechanism of the present invention is operable in an environment where some caches may only act as RQCs and others only as RSCs. Specifically in a hierarchical topology, a situation can be envisioned where caches lower in the hierarchy only request information, and those higher up in the hierarchy only respond.
"Higher" is used in the sense, that the link to the Internet is at the highest level, and the Web clients or browsers are at the lowest level. Most popular commercial browsers, have caches co-located. Such a client-cache would typically always be a RQC. It may also function as an RSC, if neighboring browsers have the permission to "look" at the private caches of other browsers.
FIG. 2 illustrates the mechanism for a RQC-initiated notification. In this mechanism the RQC 201 initiates a request 202 to the RSC 203 to inform it about all or a subset of objects that are stored in RSC 203 and have been updated within RSC 203 since a given date and time or are new to RSC 203. As previously noted, the term "modified since a given date and time" as applied to objects shall be used to mean those objects that are new to the RSC since that time and date, as well as those objects that have been updated since that time and date. The address list of URLs in the request may include objects with individual URLs, or a plurality of objects within a range of URLs using a wildcard symbol to represent all those objects whose URLs share address commonality. As noted, this request may include a request for information about both updates to existing objects previously stored in RSC 203 as well as objects that have been newly added in RSC 203. The request 202 includes an "if modified since" (IMS) date, thereby indicating to the RSC
that information about objects is requested only if the object has been modified in the cache or newly added to the cache since that IMS date.
In response to request 202, RSC 203 checks those listed URLs to determine whether the object has in fact been modified in the cache since the IMS date. The response 204 thereto is a list of those URLs that in fact have been modified in the RSC since the IMS date, together with the times at which those URLs were modified. This information may also include the size of the requested URL object, as well as other information about the object, such as the type of content of the object. The RQC 201 then parses the response and decides, using the retrieved information about those requested URLs, specifically which URLs it desires to download to itself. This downloading can in fact be done on its own, based on its own set of rules, or may be done at a later time in response to an actual request for that object by a user who is connected to RQC
201. If, either on its own, or in response to a request from a user, RQC
decides to retrieve the object with URL url, it makes a request 205 to GET the object with URL url using the HyperText Transfer Protocol (HTTP), which is the predominant World Wide Web Internet protocol. The RSC 203, in reply to that GET request, sends a response 206 back to RQC 201 that includes a copy of the body of the object with URL url that is has stored.
FIG. 3 illustrates a mechanism for an RSC-initiated scheme in which the RSC tells the RQC every so often about changes to objects in which the RSC had previously expressed interest. In a first mode, information about objects that have been modified is transmitted to the RSC on a periodic basis. In a second mode, information is sent whenever a requested object in fact is updated or created in the RQC. Both modes can co-exist. In the second mode, the RQC 301 first registers a request 302 with RSC 303 for update events for a range of URLs. The RSC 303 then registers those requests and transmits an acknowledgment 304 back to RQC 301. After registration, RSC 303 transmits an update message back to RQC 301 whenever one of those registered URLs is modified.
Thus, when URL url1 is modified, a message 305 containing information about the object is transmitted to the RQC 301. In response thereto, RQC
301 may decide to make a request 306 to GET urll using the HTTP/1.0 protocol. Alternatively, in response to an information message that a particular URL has been modified, the RQC 301 may decide not to download it. Thus, as noted in FIG. 3, when URL uri2 is modified and an update message 307 on URL url2 is transmitted to RQC 301, the RQC
1~
decides not to make a request to download the modified url2. In a similar manner, when URL url3 is modified and a message transmitted to RQC
301, the RQC makes a request to download the modified object.
The motivation of the present invention for simply sending notification messages instead of the Web objects themselves is twofold.
Firstly, it enables a sense of cache coherency even if the RQC may not have space left on its system to copy the Web object itself. Since this is done asynchronous to user requests, and not as a consequence to a request, caches know ahead of time what other caches carry, and therefore can save delay as .perceived by the user (by preventing fruitless queries to neighbor caches), as well as network and cache resources.
Secondly, the invention permits a logical separation between information regarding the modification time of an object, and the content of the object itself. A cache can therefore choose what objects it would like to refresh or cache, before it downloads them. Since the information carried can include other aspects of the object, such as the size in bytes, the cache is better prepared before downloading the object. For example, the size of a particular object may be very large and the cache may choose not to download it due to insufficient storage capacity.
Following the exchange of information about the Web objects stored in neighboring caches, the new or modified Web objects can be retrieved either individually or as a batch using multipart messages, Keep-Alive connections, or compression, or any other scheme.
As previously noted, documents that have been updated at a cache since a given date and time are with respect to activities at the cache, not at the server from which the object originates. Thus, a document that has been modified at a cache after time t1, might well have been modified at the server at a time t2 < t1.
In the previously described RSC-initiated mechanism of FIG. 3, every so often the RSC sends to the RQC information on all objects it has in its cache that have been modified or created at the cache since the last message it had sent to the RQC in the previous epoch. This mechanism is extended so that the RQC automatically responds by sending back to the RSC another message which has a list of all objects it has it its cache that have been modified since the last interaction it had with the RSC in the previous epoch. This combined mechanism is similar to the mechanism of FIG. 3, but is one in which both neighbor caches become both requesting and responding caches. In this mechanism, the request becomes implicit in every response. Since the difference between a "request" and a "response" is now blurred, the term "message" will be used instead.
A more intelligent scenario can be considered. Here, caches maintain state-information on what other caches have, partly based on the messages sent to it. Once this state-information is available, messages sent back and forth can be further streamlined. Specifically, it is useless to send messages about updated objects at one's cache to a neighbor for which is known, from the neighbor's previous message, has a more recent or equally recent version of the object. This third mechanism, shown in FIG. 4, is only viable between caches that can act as both RQCs and RSCs. This mechanism is particularly designed for use for the case when peering caches within an IASP are interested in knowing about all the modified objects on all the caches. While this mechanism requires each cache to maintain some state information about what is on its neighbors' caches, it significantly reduces communication overhead, especially when the number of objects in each cache is large.
in the mechanism of FIG. 4, cache 401 sends neighbor cache 402 a message 403 containing information about a set of URLs. When cache 402 receives that message, it updates the state-information it has accumulated on its neighbor cache 401. Cache 402 then, based on the state-information that cache 402 has on cache 401, sends a message 404 that contains information about a set of modified URLs that is newer than what cache 401 has. When message 404 is received by cache 401, the state-information cache 401 has on cache 402 is updated and, based on that state information, information about URLs that is newer than what cache 402 has is sent to cache 402 in message 405. This algorithm is repeated at caches 401 and 402 in response to each received message from the other.
In this mechanism, each cache maintains state-information (as a table) on every neighbor cache with which it communicates. Each table is essentially a list of URLs with their modification times at the cache. Each item in the list is thus a 2-tuple of the form: (url; , t;) where t; is the modified time of the object identified by URL url; . It should be noted that there may exist a document at the original server/site that is newer than what the cache has, with a modification time later than t; . However, the table simply lists the most recent document that the neighboring cache has based on knowledge built up from messages that the neighboring cache has issued.
The table is updated as follows. Every message from the neighboring cache comprises a lists of URLs with associated modification times. For each item (url, t) the following operation is used. Let (url; , t;
) be an entry in the table. If url = url; : replace (url; , f; ) by (url, t) in the table.
If a URL that the neighbor has been purged from the cache, that URL is also sent, with t set to a negative value (indicating that it has been purged). Let the list of new URLs (since one's last response to the neighboring cache) stored in one's own cache consist of a set of 2-tuples in the form (urlX, tx). Each of these is sent in the response message unless urlX = url; and tX <= t;. In other words, this means, send (urlX, tX), unless the table for cache i, represented by (url; , t; ) suggests that cache i has an equally or more recent version of the document.
The previously described mechanism of FIG. 4 can be further streamlined ;or the case of an IASP where numerous peering caches exits, each of which are interested in every other cache's content. In this mechanism, illustrated in FIG. 5, information that a cache has collected about content on other caches is also used in addition to the content on its own cache in compiling messages to any given cache. This mechanism further reduces overhead because each cache does not have to directly exchange messages with all other caches. It also needs to only maintain a single state for the entire caching system instead of separately maintaining the state for each peering cache; the sum of state information on all caches being much larger than the state of the entire caching system. Theoretically, as long as the set of caches have direct or indirect connections, this mechanism will be able to diffuse information on all caches correctly. In graph-theoretic terms, as long as the inter-cache communication channels link up the caches in a "tree", this mechanism will work. To prevent against failure of caches and communication channels, and to reduce end-to-end communication delays, a "2-connected" or "3-connected" tree might be more appropriated, where a "k-connected" tree is one where, if any (k-1) of its links are destroyed, the set of nodes still remains connected.
Since this mechanism diffuses information on other caches in its messages, the messages transmitted between caches need to be expanded from the 2-tuples of the previously described mechanism, to a 3-tuple of the form (url; , t; , c; ), where c; is the cache which actually has stored the object referenced by url; , and where, as before, t; is the modified time of the object urJ; . In those cases where multiple caches have equally recent objects, the last item in the 3-tuple is itself a set of caches. In FIG. 5, every time a message (503 or 504) from either cache 501 or 502 arrives at the other consisting of a list of items of the form (url, t, c), if url =url; and t>t;, replace (url;, t;, c;) by (url, t, c) in the state table. However, if url=url;
and t=t;, 5 append c to the set c; as well, if c is not already present in the set c;.
Let the list of new URLs (since one's last response to the neighboring cache) one knows about consist of a set of 3-tuples of the form (urlX, tX, Cx). Each of these are sent in the response message unless CxecX. Thus, as noted in FIG. 5, the message sent to a neighbor cache in response to receiving a set of modified URLs from that 10 neighbor cache is a list of URLs that are new on the caching system unless the neighbor to which the response is directed has the most recent version of the URL.
The above-described mechanisms can be implemented in various ways. A
possible implementation of the RQC-initiated mechanism is described below.
This 15 mechanism is realized by defining a new method called CONTENTS to the HyperText Transfer Protocol (HTTP). Alternate designs are possible, that may use a separate protocol suite, outside of HTTP.
FIG. 6 illustrates the protocol mechanism for a RQC-initiated notification mode between RQC 601 and RSC 602. In the Request made to the RSC for information about specific URLs, the HTTP/1.0 syntax for the Request-Line is:
Request-Line = Method SP (space) Request-URL SP HTTP-Version CRLF (Carriage Return Line Feed) and the syntax for the Request-URL is:
Request-URL = "*" ~ absoluteURL ~ abs-path This does not permit expressing complete set of URLs. "*" is therefore chosen as the Request-URL, which fortuitously means that by default the request pertains to all of the contents of the serving cache or RSC. The Request-Line is thus:
Request-Line = "CONTENTS" SP "*" SP HTTP-Version CRLF
The If-Modified-Since field in the request header is used to specify that only those content changes that took place after the date specified by the If Modified-Since field are of interest. This field is a departure from the way this field is normally used in the GET method. In the latter, the IMS
field specifies that the document is of interest only if the actual modification time is more recent than the IMS field. Here, the IMS field is used to indicate interest in the document only if the document has been modified at the cache since the IMS time. The Range field is used to specify the URLs that are of interest. This is a field whose syntax has yet to be specified in HTTP/1.1, and it would desirable if all regular expressions can be expressed by this field. If this should be insufficient, a new field may need to be created to this purpose. What is desired here is that if a RQC is only interested in some select HTML pages, for example all the HTML pages of the New York Times except those from the Sports Section, and the JPEG images of the Louvre, it should be able to specify that union using the Range field. Finally, the Unless field is used to specify any other restriction the cache many want to apply on the URLs that interest it. The new application type termed application/www-contents is also defined to support the response that the responding cache returns.
In FIG. 6, in request 603, the request line is:
CONTENTS * HTTP/1.0 wherein CONTENTS is the method requesting is a list of URLs, the "*"
means that the method is controlled by protocol, and that HTTP/1.0 is that protocol. This line is followed by a CRLF. The next line is:
Accept: application/www-contents which means that if the RSC sends the RQC a response in accordance with that defined application, the RQC will be able to understand it. The next line is:
If Modified-Since: Sat, 29 Oct 1996 19:43:31 GMT
which means that only URLs that have changed since Saturday, 29 October 1996 at 19:43:31 GMT are of interest. The last line is:
Range: http://www.nytimes.com/*
This defines the range of URLs which are of interest, with "*" indicating that all "www.nytimes.com" objects are of interest.
The response to the RQC needs to follow a specific format.
Instead of defining this within the protocol, it is left to the RSC to specify the format, although the format definition itself needs to have a specific syntax. The format of the contents file contains a sequence of lines containing ASCII characters terminated by either the sequence LF (line feed) or CRLF. Content file generators should follow the line termination convention for the platform on which they are executed. Each line may contain either a directive or a (part of a) entry. Entries consist of a sequence of fields relating to a single HTTP object. If a field is unused in a particular entry, "=' marks the omitted field. Directives provide information about the version, as well as header fields of the objects that follow. Lines beginning with the # character contain directives. The following directives are defined:
~ Version: <integer>.<integer>
The version of the extended log file format used.
~ Syntax: [<specifier>...]
Specifies the fields recorded in the log. The strings SP and CRLF have special meaning.
~ Remark: <text>
Comment information. Data recorded in this field should be ignored by analysis tools.
The directives Version and Syntax are required. The Syntax directive may appear multiple times, with the understanding that all entries obey the Syntax directive that is above and closest to them. The Syntax directive specifies the data recorded in the fields of each entry.
In the response message 604, the line "201 O.K." indicates that the request was understood and that a valid response follows. Content-Type on the next line indicates that a special document with a certain syntax follows that is not just textual in nature. The directive #Version defines the type of syntax, specifically version 1Ø The directive #Syntax: Last-Modified CRLF URL SP
Content-Length indicates that what follows will have the format of the last modified date, on a next line, the URL that has been modified at the RSC 602, followed by a space and the size of the object in bytes. Thus the response 604 indicates that two objects matched the request 603. The first object has URL
http://www.nytimes.com/index.html, having been last modified in RSC 602 on Saturday, 29 Oct.1996 at 19:54:02 GMT, and having a length of 575 bytes. The second object has a URL of http://www.nytimes.com/info/textpath.html having been last modified in RSC 602 on Saturday, 29 Oct.1996 at 19:56:34 GMT, and having a length of 4096 bytes.
RQC 601, receives response 604 and chooses which objects to GET from RSC 602. Thus, as noted in FIG. 6, RQC 401 issues a request 605 to GET
http://www.nytimes.com/info/textpath.html HTTP/1.0, from RSC 602. RSC 602 subsequently fills that request by forwarding the body of that object back to RQC 601.
Although described in connection with neighboring caches within an IASP, the present invention could be used for exchanging information 5 about objects stored in caches on Web browsers, or between caches on Web browsers and caches within an IASP, or between caches that can communicate with each within any locations or between any locations.
The above-described embodiments are illustrative of the principles of the present invention. Other embodiments may be devised by those 10 skilled in the art without departing from the spirit and scope of the present invention.
FIG. 5 shows the interaction between two caches in which each cache maintains single-state information for the entire caching system;
and FIG. 6 shows the message interaction between a requesting cache and a responding cache for a specific implementation of a requesting cache-initiated mechanism in accordance with the present invention.
Detailed Description As noted, the present invention is a mechanism by which Web caches update each other about what Web objects are in their cache.
Update notification is distinct from actually sending the modified Web objects. The notification typically involves information from which the receiving cache can determine what Web objects are stored in the neighboring cache, but also information such as the time when the object in the neighboring cache was last modified. Optionally, the notification may contain other information that might be useful to the requesting cache such as the size, in bytes, of the object to enable the requesting cache to plan its disk space usage, and the type of contents of the object.
To distinguish between the two caches involved in the transfer of information about the objects stored in each, the cache that desires information about the contents of its neighbor cache is referred to hereinafter at the Requesting Cache (RQC), and the neighbor cache that sends out information about what it stores is referred to as the Responding Cache (RSC). The mechanism of the present invention is operable in an environment where some caches may only act as RQCs and others only as RSCs. Specifically in a hierarchical topology, a situation can be envisioned where caches lower in the hierarchy only request information, and those higher up in the hierarchy only respond.
"Higher" is used in the sense, that the link to the Internet is at the highest level, and the Web clients or browsers are at the lowest level. Most popular commercial browsers, have caches co-located. Such a client-cache would typically always be a RQC. It may also function as an RSC, if neighboring browsers have the permission to "look" at the private caches of other browsers.
FIG. 2 illustrates the mechanism for a RQC-initiated notification. In this mechanism the RQC 201 initiates a request 202 to the RSC 203 to inform it about all or a subset of objects that are stored in RSC 203 and have been updated within RSC 203 since a given date and time or are new to RSC 203. As previously noted, the term "modified since a given date and time" as applied to objects shall be used to mean those objects that are new to the RSC since that time and date, as well as those objects that have been updated since that time and date. The address list of URLs in the request may include objects with individual URLs, or a plurality of objects within a range of URLs using a wildcard symbol to represent all those objects whose URLs share address commonality. As noted, this request may include a request for information about both updates to existing objects previously stored in RSC 203 as well as objects that have been newly added in RSC 203. The request 202 includes an "if modified since" (IMS) date, thereby indicating to the RSC
that information about objects is requested only if the object has been modified in the cache or newly added to the cache since that IMS date.
In response to request 202, RSC 203 checks those listed URLs to determine whether the object has in fact been modified in the cache since the IMS date. The response 204 thereto is a list of those URLs that in fact have been modified in the RSC since the IMS date, together with the times at which those URLs were modified. This information may also include the size of the requested URL object, as well as other information about the object, such as the type of content of the object. The RQC 201 then parses the response and decides, using the retrieved information about those requested URLs, specifically which URLs it desires to download to itself. This downloading can in fact be done on its own, based on its own set of rules, or may be done at a later time in response to an actual request for that object by a user who is connected to RQC
201. If, either on its own, or in response to a request from a user, RQC
decides to retrieve the object with URL url, it makes a request 205 to GET the object with URL url using the HyperText Transfer Protocol (HTTP), which is the predominant World Wide Web Internet protocol. The RSC 203, in reply to that GET request, sends a response 206 back to RQC 201 that includes a copy of the body of the object with URL url that is has stored.
FIG. 3 illustrates a mechanism for an RSC-initiated scheme in which the RSC tells the RQC every so often about changes to objects in which the RSC had previously expressed interest. In a first mode, information about objects that have been modified is transmitted to the RSC on a periodic basis. In a second mode, information is sent whenever a requested object in fact is updated or created in the RQC. Both modes can co-exist. In the second mode, the RQC 301 first registers a request 302 with RSC 303 for update events for a range of URLs. The RSC 303 then registers those requests and transmits an acknowledgment 304 back to RQC 301. After registration, RSC 303 transmits an update message back to RQC 301 whenever one of those registered URLs is modified.
Thus, when URL url1 is modified, a message 305 containing information about the object is transmitted to the RQC 301. In response thereto, RQC
301 may decide to make a request 306 to GET urll using the HTTP/1.0 protocol. Alternatively, in response to an information message that a particular URL has been modified, the RQC 301 may decide not to download it. Thus, as noted in FIG. 3, when URL uri2 is modified and an update message 307 on URL url2 is transmitted to RQC 301, the RQC
1~
decides not to make a request to download the modified url2. In a similar manner, when URL url3 is modified and a message transmitted to RQC
301, the RQC makes a request to download the modified object.
The motivation of the present invention for simply sending notification messages instead of the Web objects themselves is twofold.
Firstly, it enables a sense of cache coherency even if the RQC may not have space left on its system to copy the Web object itself. Since this is done asynchronous to user requests, and not as a consequence to a request, caches know ahead of time what other caches carry, and therefore can save delay as .perceived by the user (by preventing fruitless queries to neighbor caches), as well as network and cache resources.
Secondly, the invention permits a logical separation between information regarding the modification time of an object, and the content of the object itself. A cache can therefore choose what objects it would like to refresh or cache, before it downloads them. Since the information carried can include other aspects of the object, such as the size in bytes, the cache is better prepared before downloading the object. For example, the size of a particular object may be very large and the cache may choose not to download it due to insufficient storage capacity.
Following the exchange of information about the Web objects stored in neighboring caches, the new or modified Web objects can be retrieved either individually or as a batch using multipart messages, Keep-Alive connections, or compression, or any other scheme.
As previously noted, documents that have been updated at a cache since a given date and time are with respect to activities at the cache, not at the server from which the object originates. Thus, a document that has been modified at a cache after time t1, might well have been modified at the server at a time t2 < t1.
In the previously described RSC-initiated mechanism of FIG. 3, every so often the RSC sends to the RQC information on all objects it has in its cache that have been modified or created at the cache since the last message it had sent to the RQC in the previous epoch. This mechanism is extended so that the RQC automatically responds by sending back to the RSC another message which has a list of all objects it has it its cache that have been modified since the last interaction it had with the RSC in the previous epoch. This combined mechanism is similar to the mechanism of FIG. 3, but is one in which both neighbor caches become both requesting and responding caches. In this mechanism, the request becomes implicit in every response. Since the difference between a "request" and a "response" is now blurred, the term "message" will be used instead.
A more intelligent scenario can be considered. Here, caches maintain state-information on what other caches have, partly based on the messages sent to it. Once this state-information is available, messages sent back and forth can be further streamlined. Specifically, it is useless to send messages about updated objects at one's cache to a neighbor for which is known, from the neighbor's previous message, has a more recent or equally recent version of the object. This third mechanism, shown in FIG. 4, is only viable between caches that can act as both RQCs and RSCs. This mechanism is particularly designed for use for the case when peering caches within an IASP are interested in knowing about all the modified objects on all the caches. While this mechanism requires each cache to maintain some state information about what is on its neighbors' caches, it significantly reduces communication overhead, especially when the number of objects in each cache is large.
in the mechanism of FIG. 4, cache 401 sends neighbor cache 402 a message 403 containing information about a set of URLs. When cache 402 receives that message, it updates the state-information it has accumulated on its neighbor cache 401. Cache 402 then, based on the state-information that cache 402 has on cache 401, sends a message 404 that contains information about a set of modified URLs that is newer than what cache 401 has. When message 404 is received by cache 401, the state-information cache 401 has on cache 402 is updated and, based on that state information, information about URLs that is newer than what cache 402 has is sent to cache 402 in message 405. This algorithm is repeated at caches 401 and 402 in response to each received message from the other.
In this mechanism, each cache maintains state-information (as a table) on every neighbor cache with which it communicates. Each table is essentially a list of URLs with their modification times at the cache. Each item in the list is thus a 2-tuple of the form: (url; , t;) where t; is the modified time of the object identified by URL url; . It should be noted that there may exist a document at the original server/site that is newer than what the cache has, with a modification time later than t; . However, the table simply lists the most recent document that the neighboring cache has based on knowledge built up from messages that the neighboring cache has issued.
The table is updated as follows. Every message from the neighboring cache comprises a lists of URLs with associated modification times. For each item (url, t) the following operation is used. Let (url; , t;
) be an entry in the table. If url = url; : replace (url; , f; ) by (url, t) in the table.
If a URL that the neighbor has been purged from the cache, that URL is also sent, with t set to a negative value (indicating that it has been purged). Let the list of new URLs (since one's last response to the neighboring cache) stored in one's own cache consist of a set of 2-tuples in the form (urlX, tx). Each of these is sent in the response message unless urlX = url; and tX <= t;. In other words, this means, send (urlX, tX), unless the table for cache i, represented by (url; , t; ) suggests that cache i has an equally or more recent version of the document.
The previously described mechanism of FIG. 4 can be further streamlined ;or the case of an IASP where numerous peering caches exits, each of which are interested in every other cache's content. In this mechanism, illustrated in FIG. 5, information that a cache has collected about content on other caches is also used in addition to the content on its own cache in compiling messages to any given cache. This mechanism further reduces overhead because each cache does not have to directly exchange messages with all other caches. It also needs to only maintain a single state for the entire caching system instead of separately maintaining the state for each peering cache; the sum of state information on all caches being much larger than the state of the entire caching system. Theoretically, as long as the set of caches have direct or indirect connections, this mechanism will be able to diffuse information on all caches correctly. In graph-theoretic terms, as long as the inter-cache communication channels link up the caches in a "tree", this mechanism will work. To prevent against failure of caches and communication channels, and to reduce end-to-end communication delays, a "2-connected" or "3-connected" tree might be more appropriated, where a "k-connected" tree is one where, if any (k-1) of its links are destroyed, the set of nodes still remains connected.
Since this mechanism diffuses information on other caches in its messages, the messages transmitted between caches need to be expanded from the 2-tuples of the previously described mechanism, to a 3-tuple of the form (url; , t; , c; ), where c; is the cache which actually has stored the object referenced by url; , and where, as before, t; is the modified time of the object urJ; . In those cases where multiple caches have equally recent objects, the last item in the 3-tuple is itself a set of caches. In FIG. 5, every time a message (503 or 504) from either cache 501 or 502 arrives at the other consisting of a list of items of the form (url, t, c), if url =url; and t>t;, replace (url;, t;, c;) by (url, t, c) in the state table. However, if url=url;
and t=t;, 5 append c to the set c; as well, if c is not already present in the set c;.
Let the list of new URLs (since one's last response to the neighboring cache) one knows about consist of a set of 3-tuples of the form (urlX, tX, Cx). Each of these are sent in the response message unless CxecX. Thus, as noted in FIG. 5, the message sent to a neighbor cache in response to receiving a set of modified URLs from that 10 neighbor cache is a list of URLs that are new on the caching system unless the neighbor to which the response is directed has the most recent version of the URL.
The above-described mechanisms can be implemented in various ways. A
possible implementation of the RQC-initiated mechanism is described below.
This 15 mechanism is realized by defining a new method called CONTENTS to the HyperText Transfer Protocol (HTTP). Alternate designs are possible, that may use a separate protocol suite, outside of HTTP.
FIG. 6 illustrates the protocol mechanism for a RQC-initiated notification mode between RQC 601 and RSC 602. In the Request made to the RSC for information about specific URLs, the HTTP/1.0 syntax for the Request-Line is:
Request-Line = Method SP (space) Request-URL SP HTTP-Version CRLF (Carriage Return Line Feed) and the syntax for the Request-URL is:
Request-URL = "*" ~ absoluteURL ~ abs-path This does not permit expressing complete set of URLs. "*" is therefore chosen as the Request-URL, which fortuitously means that by default the request pertains to all of the contents of the serving cache or RSC. The Request-Line is thus:
Request-Line = "CONTENTS" SP "*" SP HTTP-Version CRLF
The If-Modified-Since field in the request header is used to specify that only those content changes that took place after the date specified by the If Modified-Since field are of interest. This field is a departure from the way this field is normally used in the GET method. In the latter, the IMS
field specifies that the document is of interest only if the actual modification time is more recent than the IMS field. Here, the IMS field is used to indicate interest in the document only if the document has been modified at the cache since the IMS time. The Range field is used to specify the URLs that are of interest. This is a field whose syntax has yet to be specified in HTTP/1.1, and it would desirable if all regular expressions can be expressed by this field. If this should be insufficient, a new field may need to be created to this purpose. What is desired here is that if a RQC is only interested in some select HTML pages, for example all the HTML pages of the New York Times except those from the Sports Section, and the JPEG images of the Louvre, it should be able to specify that union using the Range field. Finally, the Unless field is used to specify any other restriction the cache many want to apply on the URLs that interest it. The new application type termed application/www-contents is also defined to support the response that the responding cache returns.
In FIG. 6, in request 603, the request line is:
CONTENTS * HTTP/1.0 wherein CONTENTS is the method requesting is a list of URLs, the "*"
means that the method is controlled by protocol, and that HTTP/1.0 is that protocol. This line is followed by a CRLF. The next line is:
Accept: application/www-contents which means that if the RSC sends the RQC a response in accordance with that defined application, the RQC will be able to understand it. The next line is:
If Modified-Since: Sat, 29 Oct 1996 19:43:31 GMT
which means that only URLs that have changed since Saturday, 29 October 1996 at 19:43:31 GMT are of interest. The last line is:
Range: http://www.nytimes.com/*
This defines the range of URLs which are of interest, with "*" indicating that all "www.nytimes.com" objects are of interest.
The response to the RQC needs to follow a specific format.
Instead of defining this within the protocol, it is left to the RSC to specify the format, although the format definition itself needs to have a specific syntax. The format of the contents file contains a sequence of lines containing ASCII characters terminated by either the sequence LF (line feed) or CRLF. Content file generators should follow the line termination convention for the platform on which they are executed. Each line may contain either a directive or a (part of a) entry. Entries consist of a sequence of fields relating to a single HTTP object. If a field is unused in a particular entry, "=' marks the omitted field. Directives provide information about the version, as well as header fields of the objects that follow. Lines beginning with the # character contain directives. The following directives are defined:
~ Version: <integer>.<integer>
The version of the extended log file format used.
~ Syntax: [<specifier>...]
Specifies the fields recorded in the log. The strings SP and CRLF have special meaning.
~ Remark: <text>
Comment information. Data recorded in this field should be ignored by analysis tools.
The directives Version and Syntax are required. The Syntax directive may appear multiple times, with the understanding that all entries obey the Syntax directive that is above and closest to them. The Syntax directive specifies the data recorded in the fields of each entry.
In the response message 604, the line "201 O.K." indicates that the request was understood and that a valid response follows. Content-Type on the next line indicates that a special document with a certain syntax follows that is not just textual in nature. The directive #Version defines the type of syntax, specifically version 1Ø The directive #Syntax: Last-Modified CRLF URL SP
Content-Length indicates that what follows will have the format of the last modified date, on a next line, the URL that has been modified at the RSC 602, followed by a space and the size of the object in bytes. Thus the response 604 indicates that two objects matched the request 603. The first object has URL
http://www.nytimes.com/index.html, having been last modified in RSC 602 on Saturday, 29 Oct.1996 at 19:54:02 GMT, and having a length of 575 bytes. The second object has a URL of http://www.nytimes.com/info/textpath.html having been last modified in RSC 602 on Saturday, 29 Oct.1996 at 19:56:34 GMT, and having a length of 4096 bytes.
RQC 601, receives response 604 and chooses which objects to GET from RSC 602. Thus, as noted in FIG. 6, RQC 401 issues a request 605 to GET
http://www.nytimes.com/info/textpath.html HTTP/1.0, from RSC 602. RSC 602 subsequently fills that request by forwarding the body of that object back to RQC 601.
Although described in connection with neighboring caches within an IASP, the present invention could be used for exchanging information 5 about objects stored in caches on Web browsers, or between caches on Web browsers and caches within an IASP, or between caches that can communicate with each within any locations or between any locations.
The above-described embodiments are illustrative of the principles of the present invention. Other embodiments may be devised by those 10 skilled in the art without departing from the spirit and scope of the present invention.
Claims (12)
1. In a system comprising at least a first and a second interconnected Web caches on a packet data network, which each stores Web objects that can be retrieved by a plurality of client terminals connected to either Web cache, the Web objects stored in the first and second Web caches being copies of Web objects received from Web servers connected on the packet data network, a method comprising the steps of:
receiving a signal at the second Web cache from the first Web cache that is indicative of a request for information relating to Web objects stored in the second Web cache; and transmitting asynchronously a signal from the second Web cache to the first Web cache that provides the requested information relating to Web objects stored in the second Web cache.
receiving a signal at the second Web cache from the first Web cache that is indicative of a request for information relating to Web objects stored in the second Web cache; and transmitting asynchronously a signal from the second Web cache to the first Web cache that provides the requested information relating to Web objects stored in the second Web cache.
2. The method of claim 1 further comprising the steps of:
receiving a request for a copy of a Web object stored in the second Web cache from the first Web cache in response to receiving the information relating to Web objects stored in the second Web cache; and providing a copy of the requested Web object to the first Web cache in response to the request for a copy of the Web object in the second Web cache.
receiving a request for a copy of a Web object stored in the second Web cache from the first Web cache in response to receiving the information relating to Web objects stored in the second Web cache; and providing a copy of the requested Web object to the first Web cache in response to the request for a copy of the Web object in the second Web cache.
3. The method of claim 1 wherein the signal requesting information relating to Web objects stored in the second Web cache is received asynchronous with a request for a copy of a Web object by a client terminal connected to either the first or second Web cache.
4. The method of claim 1 wherein the requested information relating to Web objects stored in the second Web cache comprises information relating to what Web objects are stored in the second Web cache.
5. The method of claim 1 wherein the requested information relating to Web objects stored in the second Web cache comprises information relating to the time a Web object was modified in the second Web cache.
6. The method of claim 5 wherein the requested information relating to Web objects stored in the second Web cache further comprises information relating to the size of a Web object in the second Web cache.
7. The method of claim 1 wherein the step of receiving a signal at the second Web cache from the first Web cache that is indicative of a request for information relating to Web objects stored in the second Web cache comprises the step of receiving a registration request for information relating to when Web objects are modified in the second Web cache.
8. The method of claim 7 wherein the signal transmitted from the second Web cache to the first Web cache that provides the requested information relating to Web objects stored in the second Web cache is transmitted when a Web object is modified in the second Web cache.
9. The method of claim 7 wherein the signal transmitted from the second Web cache to the first Web cache that provides the requested information relating to Web objects stored in the second Web cache is transmitted on a periodic basis.
10. The method of claim 1 wherein the signal received at the second Web cache from the first Web cache that is indicative of a request for information relating to Web objects stored in the second Web cache comprises information on a set of Web objects that have been modified in the first Web cache, and the signal from the second Web cache to the first Web cache that provides the requested information relating to Web objects stored in the second Web cache comprises information on a set of Web objects that have been modified in the second Web cache.
11. In a system comprising at least a first and a second interconnected Web caches on a packet data network, which each stores Web objects that can be retrieved by a plurality of client terminals connected to either Web cache, the objects stored in the first and second Web caches being copies of Web objects received from Web servers connected on the packet data network, a method comprising the steps of:
receiving at the second Web cache from the first Web cache information relating to Web objects that have been modified in the first Web cache;
updating state-information stored at the second Web cache relating to Web objects stored in the first Web cache in response to the information received from the first Web cache relating to Web objects that have been modified in the first Web cache; and transmitting asynchronously information to the first Web cache from the second Web cache relating to those Web objects in the second Web cache that have been modified in the second Web cache after those Web objects have been modified in the first Web cache in accordance with the updated state information relating to Web objects stored ins the first Web cache.
receiving at the second Web cache from the first Web cache information relating to Web objects that have been modified in the first Web cache;
updating state-information stored at the second Web cache relating to Web objects stored in the first Web cache in response to the information received from the first Web cache relating to Web objects that have been modified in the first Web cache; and transmitting asynchronously information to the first Web cache from the second Web cache relating to those Web objects in the second Web cache that have been modified in the second Web cache after those Web objects have been modified in the first Web cache in accordance with the updated state information relating to Web objects stored ins the first Web cache.
12. In a system comprising a first Web cache, a second Web cache and at least one other Web cache, the first, second and at least one other Web cache being interconnected on a packet data network, each Web cache storing Web objects that can be retrieved by a plurality of client terminals connected to any Web cache, the Web objects stored in the first, second and the at least one other Web caches being copies of Web objects received from Web servers connected on the packet data network, a method comprising the steps of:
receiving at the second Web cache from the first Web cache information relating to Web objects that have been modified in the first Web cache and information that the first Web cache has on Web objects that have been modified in all other Web caches in the system;
updating state-information stored at the second Web cache relating to Web objects stored in the first Web cache and all other Web caches in the system in response to the information received from the first Web cache relating to Web objects that have been modified in the first Web cache and information that the first Web cache has on Web objects that have been modified in all other Web caches in the system; and transmitting asynchronously to the first Web cache from the second Web cache, information relating to those Web objects in the second Web cache that have been modified in the second Web cache and information that the second Web cache has relating to Web objects that have been modified in all other Web caches, in accordance with the updated state-information stored at the Web second cache relating to Web objects stored on all Web caches.
receiving at the second Web cache from the first Web cache information relating to Web objects that have been modified in the first Web cache and information that the first Web cache has on Web objects that have been modified in all other Web caches in the system;
updating state-information stored at the second Web cache relating to Web objects stored in the first Web cache and all other Web caches in the system in response to the information received from the first Web cache relating to Web objects that have been modified in the first Web cache and information that the first Web cache has on Web objects that have been modified in all other Web caches in the system; and transmitting asynchronously to the first Web cache from the second Web cache, information relating to those Web objects in the second Web cache that have been modified in the second Web cache and information that the second Web cache has relating to Web objects that have been modified in all other Web caches, in accordance with the updated state-information stored at the Web second cache relating to Web objects stored on all Web caches.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US733,485 | 1996-10-18 | ||
| US08/733,485 US5787470A (en) | 1996-10-18 | 1996-10-18 | Inter-cache protocol for improved WEB performance |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2216346A1 CA2216346A1 (en) | 1998-04-18 |
| CA2216346C true CA2216346C (en) | 2002-01-15 |
Family
ID=24947798
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002216346A Expired - Fee Related CA2216346C (en) | 1996-10-18 | 1997-09-24 | Inter-cache protocol for improved web performance |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US5787470A (en) |
| EP (1) | EP0837584B1 (en) |
| JP (1) | JP3968119B2 (en) |
| CA (1) | CA2216346C (en) |
| DE (1) | DE69727438T2 (en) |
Families Citing this family (183)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5935207A (en) * | 1996-06-03 | 1999-08-10 | Webtv Networks, Inc. | Method and apparatus for providing remote site administrators with user hits on mirrored web sites |
| GB2316200A (en) * | 1996-08-08 | 1998-02-18 | Ibm | Accessing information about executable code |
| US6584498B2 (en) * | 1996-09-13 | 2003-06-24 | Planet Web, Inc. | Dynamic preloading of web pages |
| US6377978B1 (en) | 1996-09-13 | 2002-04-23 | Planetweb, Inc. | Dynamic downloading of hypertext electronic mail messages |
| SE9603753L (en) * | 1996-10-14 | 1998-04-06 | Mirror Image Internet Ab | Procedure and apparatus for information transmission on the Internet |
| US6138141A (en) * | 1996-10-18 | 2000-10-24 | At&T Corp | Server to client cache protocol for improved web performance |
| US5884316A (en) * | 1996-11-19 | 1999-03-16 | Microsoft Corporation | Implicit session context system with object state cache |
| US5961602A (en) * | 1997-02-10 | 1999-10-05 | International Business Machines Corporation | Method for optimizing off-peak caching of web data |
| SE9700622D0 (en) | 1997-02-21 | 1997-02-21 | Ericsson Telefon Ab L M | Device and method for data networks |
| US7529856B2 (en) * | 1997-03-05 | 2009-05-05 | At Home Corporation | Delivering multimedia services |
| US6370571B1 (en) | 1997-03-05 | 2002-04-09 | At Home Corporation | System and method for delivering high-performance online multimedia services |
| US5948066A (en) * | 1997-03-13 | 1999-09-07 | Motorola, Inc. | System and method for delivery of information over narrow-band communications links |
| JP3139408B2 (en) * | 1997-03-17 | 2001-02-26 | カシオ計算機株式会社 | Homepage update notification device |
| US5933849A (en) * | 1997-04-10 | 1999-08-03 | At&T Corp | Scalable distributed caching system and method |
| US6061714A (en) * | 1997-05-07 | 2000-05-09 | International Business Machines Corporation | Persistent cache synchronization and start up system |
| US5907678A (en) * | 1997-05-07 | 1999-05-25 | International Business Machines Corporation | Client/server system in which protocol caches for multiple sessions are selectively copied into a common checkpoint cache upon receiving a checkpoint request |
| US6209036B1 (en) * | 1997-06-06 | 2001-03-27 | International Business Machines Corporation | Management of and access to information and other material via the world wide web in an LDAP environment |
| US7103794B2 (en) | 1998-06-08 | 2006-09-05 | Cacheflow, Inc. | Network object cache engine |
| US5892919A (en) * | 1997-06-23 | 1999-04-06 | Sun Microsystems, Inc. | Spell checking universal resource locator (URL) by comparing the URL against a cache containing entries relating incorrect URLs submitted by users to corresponding correct URLs |
| US6026413A (en) * | 1997-08-01 | 2000-02-15 | International Business Machines Corporation | Determining how changes to underlying data affect cached objects |
| US6256712B1 (en) * | 1997-08-01 | 2001-07-03 | International Business Machines Corporation | Scaleable method for maintaining and making consistent updates to caches |
| US6564250B1 (en) | 1997-08-21 | 2003-05-13 | Planetweb, Inc. | Miniclient for internet appliance |
| US6542923B2 (en) | 1997-08-21 | 2003-04-01 | Planet Web, Inc. | Active electronic mail |
| US7325077B1 (en) * | 1997-08-21 | 2008-01-29 | Beryl Technical Assays Llc | Miniclient for internet appliance |
| US6032150A (en) * | 1997-08-25 | 2000-02-29 | Planetweb, Inc. | Secure graphical objects in web documents with a program applet placed to present further information upon selected conditions |
| US6035324A (en) * | 1997-08-28 | 2000-03-07 | International Business Machines Corporation | Client-side asynchronous form management |
| US6240461B1 (en) | 1997-09-25 | 2001-05-29 | Cisco Technology, Inc. | Methods and apparatus for caching network data traffic |
| US6621505B1 (en) * | 1997-09-30 | 2003-09-16 | Journee Software Corp. | Dynamic process-based enterprise computing system and method |
| US6014667A (en) * | 1997-10-01 | 2000-01-11 | Novell, Inc. | System and method for caching identification and location information in a computer network |
| US6845102B1 (en) * | 1997-10-09 | 2005-01-18 | Cisco Technology, Inc. | Method and system for network access over a low bandwidth link |
| US6035336A (en) * | 1997-10-17 | 2000-03-07 | International Business Machines Corporation | Audio ticker system and method for presenting push information including pre-recorded audio |
| US6393526B1 (en) * | 1997-10-28 | 2002-05-21 | Cache Plan, Inc. | Shared cache parsing and pre-fetch |
| US6128701A (en) * | 1997-10-28 | 2000-10-03 | Cache Flow, Inc. | Adaptive and predictive cache refresh policy |
| US6185617B1 (en) * | 1997-11-26 | 2001-02-06 | International Business Machines Corporation | Construction and usage of a pre-warmed cache for client-server emulator |
| US6366947B1 (en) * | 1998-01-20 | 2002-04-02 | Redmond Venture, Inc. | System and method for accelerating network interaction |
| US6205481B1 (en) * | 1998-03-17 | 2001-03-20 | Infolibria, Inc. | Protocol for distributing fresh content among networked cache servers |
| US6816892B1 (en) * | 1998-03-18 | 2004-11-09 | Ncr Corporation | Web-on-cd |
| US6684211B1 (en) | 1998-04-01 | 2004-01-27 | Planetweb, Inc. | Multimedia communication and presentation |
| US6272593B1 (en) | 1998-04-10 | 2001-08-07 | Microsoft Corporation | Dynamic network cache directories |
| US6119153A (en) * | 1998-04-27 | 2000-09-12 | Microsoft Corporation | Accessing content via installable data sources |
| AU3874899A (en) * | 1998-05-01 | 1999-11-23 | Citizen 1 Software, Inc. | Method and apparatus for simultaneously accessing a plurality of dispersed databases |
| US6314432B1 (en) * | 1998-05-13 | 2001-11-06 | International Business Machines Corporation | System and method for retrieval, saving and printing of using hyperlinks |
| US6591288B1 (en) | 1998-05-19 | 2003-07-08 | Nortel Networks Limited | Data network accelerated access system |
| US6341311B1 (en) | 1998-05-29 | 2002-01-22 | Microsoft Corporation | Directing data object access requests in a distributed cache |
| US6311216B1 (en) | 1998-05-29 | 2001-10-30 | Microsoft Corporation | Method, computer program product, and system for client-side deterministic routing and URL lookup into a distributed cache of URLS |
| US6377991B1 (en) * | 1998-05-29 | 2002-04-23 | Microsoft Corporation | Method, computer program product, and system for migrating URLs within a dynamically changing distributed cache of URLs |
| US6745243B2 (en) * | 1998-06-30 | 2004-06-01 | Nortel Networks Limited | Method and apparatus for network caching and load balancing |
| US6199107B1 (en) | 1998-07-22 | 2001-03-06 | Microsoft Corporation | Partial file caching and read range resume system and method |
| US6427187B2 (en) | 1998-07-31 | 2002-07-30 | Cache Flow, Inc. | Multiple cache communication |
| SE514376C2 (en) * | 1998-09-24 | 2001-02-19 | Mirror Image Internet Inc | An internet caching system as well as a procedure and device in such a system |
| US6535509B2 (en) | 1998-09-28 | 2003-03-18 | Infolibria, Inc. | Tagging for demultiplexing in a network traffic server |
| EP0993163A1 (en) * | 1998-10-05 | 2000-04-12 | Backweb Technologies Ltd. | Distributed client-based data caching system and method |
| US6438652B1 (en) * | 1998-10-09 | 2002-08-20 | International Business Machines Corporation | Load balancing cooperating cache servers by shifting forwarded request |
| US6751777B2 (en) | 1998-10-19 | 2004-06-15 | International Business Machines Corporation | Multi-target links for navigating between hypertext documents and the like |
| US6411986B1 (en) * | 1998-11-10 | 2002-06-25 | Netscaler, Inc. | Internet client-server multiplexer |
| US6279041B1 (en) | 1998-11-13 | 2001-08-21 | International Business Machines Corporation | Methods, systems and computer program products for differencing data communications using a message queue |
| US6553376B1 (en) * | 1998-11-18 | 2003-04-22 | Infolibria, Inc. | Efficient content server using request redirection |
| SE521773C2 (en) | 1998-11-20 | 2003-12-02 | Ericsson Telefon Ab L M | System and method for providing distributed cashing of response objects within a packet data network. |
| US7765179B2 (en) * | 1998-12-01 | 2010-07-27 | Alcatel-Lucent Usa Inc. | Method and apparatus for resolving domain names of persistent web resources |
| US6233606B1 (en) | 1998-12-01 | 2001-05-15 | Microsoft Corporation | Automatic cache synchronization |
| US6453342B1 (en) | 1998-12-03 | 2002-09-17 | International Business Machines Corporation | Method and apparatus for selective caching and cleaning of history pages for web browsers |
| US6526448B1 (en) | 1998-12-22 | 2003-02-25 | At&T Corp. | Pseudo proxy server providing instant overflow capacity to computer networks |
| EP1018689A3 (en) * | 1999-01-08 | 2001-01-24 | Lucent Technologies Inc. | Methods and apparatus for enabling shared web-based interaction in stateful servers |
| US6374288B1 (en) | 1999-01-19 | 2002-04-16 | At&T Corp | Digital subscriber line server system and method for dynamically changing bit rates in response to user requests and to message types |
| US6351767B1 (en) * | 1999-01-25 | 2002-02-26 | International Business Machines Corporation | Method and system for automatically caching dynamic content based on a cacheability determination |
| US6408360B1 (en) * | 1999-01-25 | 2002-06-18 | International Business Machines Corporation | Cache override control in an apparatus for caching dynamic content |
| US6463509B1 (en) | 1999-01-26 | 2002-10-08 | Motive Power, Inc. | Preloading data in a cache memory according to user-specified preload criteria |
| US6370614B1 (en) | 1999-01-26 | 2002-04-09 | Motive Power, Inc. | I/O cache with user configurable preload |
| KR100729288B1 (en) * | 1999-01-28 | 2007-06-18 | 웹스펙티브 소프트웨어, 인크. | Web server content replication |
| US6219676B1 (en) | 1999-03-29 | 2001-04-17 | Novell, Inc. | Methodology for cache coherency of web server data |
| US6560777B2 (en) * | 1999-04-07 | 2003-05-06 | Webtv Networks, Inc. | Broadcast enhancement trigger addressed to multiple uniquely addressed information resources |
| US6513062B1 (en) | 1999-05-25 | 2003-01-28 | Grischa Corporation | Method, apparatus, and computer program product for efficient server response generation using intermediate state caching |
| US6542964B1 (en) * | 1999-06-02 | 2003-04-01 | Blue Coat Systems | Cost-based optimization for content distribution using dynamic protocol selection and query resolution for cache server |
| US6275470B1 (en) | 1999-06-18 | 2001-08-14 | Digital Island, Inc. | On-demand overlay routing for computer-based communication networks |
| US6751191B1 (en) | 1999-06-29 | 2004-06-15 | Cisco Technology, Inc. | Load sharing and redundancy scheme |
| US6553409B1 (en) | 1999-07-09 | 2003-04-22 | Microsoft Corporation | Background cache synchronization |
| US6427172B1 (en) * | 1999-07-20 | 2002-07-30 | Cyberstar, L.P. | Method and apparatus for internet cache content delivery via a data distribution system |
| US7349902B1 (en) * | 1999-08-04 | 2008-03-25 | Hewlett-Packard Development Company, L.P. | Content consistency in a data access network system |
| US6579365B1 (en) * | 1999-11-22 | 2003-06-17 | Glatt Air Techniques, Inc. | Apparatus for coating tablets |
| US7349979B1 (en) * | 1999-12-02 | 2008-03-25 | Cisco Technology, Inc. | Method and apparatus for redirecting network traffic |
| US7188147B2 (en) * | 1999-12-08 | 2007-03-06 | Axis Ab | I/O method and apparatus for optical storage media |
| US6839829B1 (en) | 2000-01-18 | 2005-01-04 | Cisco Technology, Inc. | Routing protocol based redundancy design for shared-access networks |
| US7058007B1 (en) | 2000-01-18 | 2006-06-06 | Cisco Technology, Inc. | Method for a cable modem to rapidly switch to a backup CMTS |
| US6725272B1 (en) | 2000-02-18 | 2004-04-20 | Netscaler, Inc. | Apparatus, method and computer program product for guaranteed content delivery incorporating putting a client on-hold based on response time |
| US20050021862A1 (en) * | 2000-03-31 | 2005-01-27 | Dickens Coal Llc | Automatic selection of content-delivery provider using link mapping database |
| US6654766B1 (en) * | 2000-04-04 | 2003-11-25 | International Business Machines Corporation | System and method for caching sets of objects |
| US6457047B1 (en) * | 2000-05-08 | 2002-09-24 | Verity, Inc. | Application caching system and method |
| US6742044B1 (en) | 2000-05-10 | 2004-05-25 | Cisco Technology, Inc. | Distributed network traffic load balancing technique implemented without gateway router |
| US6990526B1 (en) * | 2000-05-22 | 2006-01-24 | Pointred Technologies, Inc. | Method and apparatus for web caching |
| US6839809B1 (en) | 2000-05-31 | 2005-01-04 | Cisco Technology, Inc. | Methods and apparatus for improving content quality in web caching systems |
| US6879998B1 (en) | 2000-06-01 | 2005-04-12 | Aerocast.Com, Inc. | Viewer object proxy |
| US7213062B1 (en) | 2000-06-01 | 2007-05-01 | General Instrument Corporation | Self-publishing network directory |
| US6836806B1 (en) | 2000-06-01 | 2004-12-28 | Aerocast, Inc. | System for network addressing |
| US6904460B1 (en) | 2000-06-01 | 2005-06-07 | Aerocast.Com, Inc. | Reverse content harvester |
| US7395348B1 (en) * | 2000-06-05 | 2008-07-01 | Cisco Technology, Inc. | Network cache-based content routing |
| US7058691B1 (en) * | 2000-06-12 | 2006-06-06 | Trustees Of Princeton University | System for wireless push and pull based services |
| US6698015B1 (en) | 2000-06-13 | 2004-02-24 | Cisco Technology, Inc. | Apparatus and method for improving performance of critical code execution |
| JP4638120B2 (en) * | 2000-06-19 | 2011-02-23 | アールイー − フレーズ・ビー．ブイ． | A selection from a web page and a method for sending the web page to another user by the server |
| US7072979B1 (en) | 2000-06-28 | 2006-07-04 | Cisco Technology, Inc. | Wide area load balancing of web traffic |
| AU2001279030A1 (en) * | 2000-07-27 | 2002-02-13 | Escene Networks, Inc. | Propagation of state and content over a distributed electronic network |
| US6985963B1 (en) * | 2000-08-23 | 2006-01-10 | At Home Corporation | Sharing IP network resources |
| US6801933B1 (en) * | 2000-08-23 | 2004-10-05 | Nokia Internet Communications, Inc. | System and method for proactive caching employing graphical usage description |
| US6804819B1 (en) | 2000-09-18 | 2004-10-12 | Hewlett-Packard Development Company, L.P. | Method, system, and computer program product for a data propagation platform and applications of same |
| US7386610B1 (en) | 2000-09-18 | 2008-06-10 | Hewlett-Packard Development Company, L.P. | Internet protocol data mirroring |
| US6977927B1 (en) | 2000-09-18 | 2005-12-20 | Hewlett-Packard Development Company, L.P. | Method and system of allocating storage resources in a storage area network |
| US6832365B1 (en) * | 2000-10-11 | 2004-12-14 | Microsoft Corporation | System and method for interacting with computer programming languages at semantic level |
| US7801978B1 (en) | 2000-10-18 | 2010-09-21 | Citrix Systems, Inc. | Apparatus, method and computer program product for efficiently pooling connections between clients and servers |
| US6970939B2 (en) * | 2000-10-26 | 2005-11-29 | Intel Corporation | Method and apparatus for large payload distribution in a network |
| US7065568B2 (en) * | 2000-11-30 | 2006-06-20 | Microsoft Corporation | System and method for managing states and user context over stateless protocols |
| US6470426B2 (en) * | 2000-12-15 | 2002-10-22 | International Business Machines Corporation | Method and apparatus for loading a cache with data with a subsequent purge of stale cache information |
| US20020087624A1 (en) * | 2000-12-28 | 2002-07-04 | Gateway, Inc. | Method and device for temporarily storing data |
| US6606690B2 (en) | 2001-02-20 | 2003-08-12 | Hewlett-Packard Development Company, L.P. | System and method for accessing a storage area network as network attached storage |
| US6910066B1 (en) * | 2001-03-05 | 2005-06-21 | Principal Financial Services, Inc. | System, method, and apparatus for applet caching |
| US20020133537A1 (en) * | 2001-03-12 | 2002-09-19 | Whizz Technology Ltd. | Server cluster and server-side cooperative caching method for use with same |
| US6993050B2 (en) | 2001-03-14 | 2006-01-31 | At&T Corp. | Transmit and receive system for cable data service |
| DE10113902A1 (en) * | 2001-03-21 | 2002-09-26 | Matthias Jaekle | Processing program of events dates involves downloading pages from Internet, searching downloaded pages for event information, storing event information found in result table or database |
| US20020147849A1 (en) * | 2001-04-05 | 2002-10-10 | Chung-Kei Wong | Delta encoding using canonical reference files |
| US6996674B2 (en) * | 2001-05-07 | 2006-02-07 | International Business Machines Corporation | Method and apparatus for a global cache directory in a storage cluster |
| GB0113763D0 (en) * | 2001-06-06 | 2001-07-25 | Nokia Corp | A communication system |
| US7881208B1 (en) | 2001-06-18 | 2011-02-01 | Cisco Technology, Inc. | Gateway load balancing protocol |
| KR100436431B1 (en) * | 2001-06-21 | 2004-06-16 | (주)와이즈피어 | Collaborative Information exchanging system on the Peer to Peer network |
| US8041814B2 (en) | 2001-06-28 | 2011-10-18 | International Business Machines Corporation | Method, system and computer program product for hierarchical load balancing |
| US7774492B2 (en) * | 2001-07-26 | 2010-08-10 | Citrix Systems, Inc. | System, method and computer program product to maximize server throughput while avoiding server overload by controlling the rate of establishing server-side net work connections |
| US7099957B2 (en) * | 2001-08-23 | 2006-08-29 | The Directtv Group, Inc. | Domain name system resolution |
| EP1423972A1 (en) * | 2001-08-27 | 2004-06-02 | Koninklijke Philips Electronics N.V. | Cache method |
| KR20010109499A (en) * | 2001-10-11 | 2001-12-10 | 온스그래픽(주) | Internet caching system and method |
| US6799186B2 (en) | 2001-10-11 | 2004-09-28 | International Business Machines Corporation | SLA monitor calendar buffering |
| US7672249B2 (en) * | 2001-12-13 | 2010-03-02 | Cisco Technology, Inc. | Configurable network appliance |
| US7720997B1 (en) | 2001-12-19 | 2010-05-18 | Cisco Technology, Inc. | Path selection system |
| US20030158958A1 (en) * | 2002-02-20 | 2003-08-21 | Koninklijke Philips Electronics N.V. | Distributed storage network architecture using user devices |
| JP5018849B2 (en) * | 2002-06-12 | 2012-09-05 | 株式会社日立製作所 | Authentication infrastructure system with CRL issue notification function |
| US20040143670A1 (en) * | 2002-07-02 | 2004-07-22 | Pratik Roychowdhury | System, method and computer program product to avoid server overload by controlling HTTP denial of service (DOS) attacks |
| US7058773B1 (en) * | 2003-01-16 | 2006-06-06 | Cisco Technology, Inc. | System and method for managing data in a distributed system |
| US7143145B2 (en) * | 2003-03-04 | 2006-11-28 | International Business Machines Corporation | Selective clearing of entries in a web browser cache |
| US7593346B2 (en) | 2003-07-31 | 2009-09-22 | Cisco Technology, Inc. | Distributing and balancing traffic flow in a virtual gateway |
| US7978716B2 (en) | 2003-11-24 | 2011-07-12 | Citrix Systems, Inc. | Systems and methods for providing a VPN solution |
| US8495305B2 (en) * | 2004-06-30 | 2013-07-23 | Citrix Systems, Inc. | Method and device for performing caching of dynamically generated objects in a data communication network |
| US8739274B2 (en) | 2004-06-30 | 2014-05-27 | Citrix Systems, Inc. | Method and device for performing integrated caching in a data communication network |
| US7757074B2 (en) | 2004-06-30 | 2010-07-13 | Citrix Application Networking, Llc | System and method for establishing a virtual private network |
| AU2005266943C1 (en) | 2004-07-23 | 2011-01-06 | Citrix Systems, Inc. | Systems and methods for optimizing communications between network nodes |
| EP2264956B1 (en) | 2004-07-23 | 2017-06-14 | Citrix Systems, Inc. | Method for securing remote access to private networks |
| US8706877B2 (en) | 2004-12-30 | 2014-04-22 | Citrix Systems, Inc. | Systems and methods for providing client-side dynamic redirection to bypass an intermediary |
| US7810089B2 (en) * | 2004-12-30 | 2010-10-05 | Citrix Systems, Inc. | Systems and methods for automatic installation and execution of a client-side acceleration program |
| US8549149B2 (en) | 2004-12-30 | 2013-10-01 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP multiplexing |
| US8954595B2 (en) | 2004-12-30 | 2015-02-10 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP buffering |
| US8700695B2 (en) | 2004-12-30 | 2014-04-15 | Citrix Systems, Inc. | Systems and methods for providing client-side accelerated access to remote applications via TCP pooling |
| WO2006081032A2 (en) | 2005-01-24 | 2006-08-03 | Citrix Systems, Inc. | Systems and methods for performing caching of dynamically generated objects in a network |
| US8255456B2 (en) | 2005-12-30 | 2012-08-28 | Citrix Systems, Inc. | System and method for performing flash caching of dynamically generated objects in a data communication network |
| JP4550648B2 (en) * | 2005-04-08 | 2010-09-22 | 株式会社日立製作所 | Computer system |
| US8312074B2 (en) * | 2005-05-26 | 2012-11-13 | Bytemobile, Inc. | Method for multipart encoding |
| JP2007128371A (en) * | 2005-11-04 | 2007-05-24 | Fujitsu Ltd | Content retrieval system |
| US20070112938A1 (en) * | 2005-11-17 | 2007-05-17 | Nokia Corporation | Intermediary, source and methods for sharing content |
| US8301839B2 (en) | 2005-12-30 | 2012-10-30 | Citrix Systems, Inc. | System and method for performing granular invalidation of cached dynamically generated objects in a data communication network |
| US7921184B2 (en) | 2005-12-30 | 2011-04-05 | Citrix Systems, Inc. | System and method for performing flash crowd caching of dynamically generated objects in a data communication network |
| US8300798B1 (en) | 2006-04-03 | 2012-10-30 | Wai Wu | Intelligent communication routing system and method |
| US7444388B1 (en) | 2006-04-13 | 2008-10-28 | Concert Technology Corporation | System and method for obtaining media content for a portable media player |
| US7526486B2 (en) | 2006-05-22 | 2009-04-28 | Initiate Systems, Inc. | Method and system for indexing information about entities with respect to hierarchies |
| EP2030134A4 (en) | 2006-06-02 | 2010-06-23 | Initiate Systems Inc | A system and method for automatic weight generation for probabilistic matching |
| US7685093B1 (en) | 2006-09-15 | 2010-03-23 | Initiate Systems, Inc. | Method and system for comparing attributes such as business names |
| US7698268B1 (en) | 2006-09-15 | 2010-04-13 | Initiate Systems, Inc. | Method and system for filtering false positives |
| US8356009B2 (en) | 2006-09-15 | 2013-01-15 | International Business Machines Corporation | Implementation defined segments for relational database systems |
| US7860491B2 (en) * | 2006-12-11 | 2010-12-28 | International Business Machines Corporation | System and methods for on-demand document provisioning using ad hoc networking |
| US8621092B2 (en) * | 2006-12-19 | 2013-12-31 | International Business Machines Corporation | Remote portlet consumer with enhanced resource URL processing |
| US8359339B2 (en) | 2007-02-05 | 2013-01-22 | International Business Machines Corporation | Graphical user interface for configuration of an algorithm for the matching of data records |
| US8307092B2 (en) * | 2007-02-21 | 2012-11-06 | Napo Enterprises, Llc | Method and system for collecting information about a user's media collections from multiple login points |
| US8515926B2 (en) * | 2007-03-22 | 2013-08-20 | International Business Machines Corporation | Processing related data from information sources |
| WO2008121170A1 (en) * | 2007-03-29 | 2008-10-09 | Initiate Systems, Inc. | Method and system for parsing languages |
| US8423514B2 (en) | 2007-03-29 | 2013-04-16 | International Business Machines Corporation | Service provisioning |
| US8370355B2 (en) | 2007-03-29 | 2013-02-05 | International Business Machines Corporation | Managing entities within a database |
| WO2008121824A1 (en) | 2007-03-29 | 2008-10-09 | Initiate Systems, Inc. | Method and system for data exchange among data sources |
| US8417702B2 (en) | 2007-09-28 | 2013-04-09 | International Business Machines Corporation | Associating data records in multiple languages |
| US8713434B2 (en) | 2007-09-28 | 2014-04-29 | International Business Machines Corporation | Indexing, relating and managing information about entities |
| EP2193415A4 (en) | 2007-09-28 | 2013-08-28 | Ibm | Method and system for analysis of a system for matching data records |
| US8667175B2 (en) * | 2008-03-13 | 2014-03-04 | Cisco Technology, Inc. | Server selection for routing content to a client using application layer redirection |
| US7725535B2 (en) * | 2008-05-27 | 2010-05-25 | International Business Machines Corporation | Client-side storage and distribution of asynchronous includes in an application server environment |
| US9253536B2 (en) * | 2009-03-18 | 2016-02-02 | Microsoft Technology Licensing, Llc | Updating data-consuming entities |
| US9135091B2 (en) | 2009-04-03 | 2015-09-15 | Microsoft Technology Licensing, Llc | Communicating events or data between application components |
| US9253278B2 (en) | 2012-01-30 | 2016-02-02 | International Business Machines Corporation | Using entity tags (ETags) in a hierarchical HTTP proxy cache to reduce network traffic |
| US9055118B2 (en) * | 2012-07-13 | 2015-06-09 | International Business Machines Corporation | Edge caching using HTTP headers |
| US9860332B2 (en) | 2013-05-08 | 2018-01-02 | Samsung Electronics Co., Ltd. | Caching architecture for packet-form in-memory object caching |
| CN108829837A (en) * | 2018-06-19 | 2018-11-16 | 北京五八信息技术有限公司 | A kind of information query method, device, equipment and computer readable storage medium |
| CN110933168B (en) * | 2019-11-28 | 2022-03-11 | 广东好太太智能家居有限公司 | Message reporting method and device for multiple Internet of things devices and storage medium |
| US11748263B2 (en) | 2021-11-15 | 2023-09-05 | Akamai Technologies, Inc. | Internet caches with object hints |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4959777A (en) * | 1987-07-27 | 1990-09-25 | Motorola Computer X | Write-shared cache circuit for multiprocessor system |
| JPH0680499B2 (en) * | 1989-01-13 | 1994-10-12 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Cache control system and method for multiprocessor system |
| US5222224A (en) * | 1989-02-03 | 1993-06-22 | Digital Equipment Corporation | Scheme for insuring data consistency between a plurality of cache memories and the main memory in a multi-processor system |
| US5611049A (en) * | 1992-06-03 | 1997-03-11 | Pitts; William M. | System for accessing distributed data cache channel at each network node to pass requests and data |
| DE69327643T2 (en) * | 1992-12-18 | 2000-08-31 | Advanced Micro Devices Inc | Cache storage systems |
| US5452447A (en) * | 1992-12-21 | 1995-09-19 | Sun Microsystems, Inc. | Method and apparatus for a caching file server |
| US5511208A (en) * | 1993-03-23 | 1996-04-23 | International Business Machines Corporation | Locating resources in computer networks having cache server nodes |
| US5604882A (en) * | 1993-08-27 | 1997-02-18 | International Business Machines Corporation | System and method for empty notification from peer cache units to global storage control unit in a multiprocessor data processing system |
| US5510934A (en) * | 1993-12-15 | 1996-04-23 | Silicon Graphics, Inc. | Memory system including local and global caches for storing floating point and integer data |
| US5623656A (en) * | 1994-12-15 | 1997-04-22 | Lucent Technologies Inc. | Script-based data communication system and method utilizing state memory |
-
1996
- 1996-10-18 US US08/733,485 patent/US5787470A/en not_active Expired - Lifetime
-
1997
- 1997-09-24 CA CA002216346A patent/CA2216346C/en not_active Expired - Fee Related
- 1997-10-13 DE DE69727438T patent/DE69727438T2/en not_active Expired - Lifetime
- 1997-10-13 EP EP97308074A patent/EP0837584B1/en not_active Expired - Lifetime
- 1997-10-20 JP JP28666497A patent/JP3968119B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP0837584B1 (en) | 2004-02-04 |
| DE69727438T2 (en) | 2004-12-02 |
| JPH10254753A (en) | 1998-09-25 |
| EP0837584A1 (en) | 1998-04-22 |
| DE69727438D1 (en) | 2004-03-11 |
| US5787470A (en) | 1998-07-28 |
| JP3968119B2 (en) | 2007-08-29 |
| CA2216346A1 (en) | 1998-04-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2216346C (en) | Inter-cache protocol for improved web performance | |
| US6112231A (en) | Server to cache protocol for improved web performance | |
| CA2369108C (en) | Handling a request for information provided by a network site | |
| US7523173B2 (en) | System and method for web page acquisition | |
| JP2893019B2 (en) | Dynamic push filtering method with staging / buffering in proxy hierarchy | |
| US6912591B2 (en) | System and method for patch enabled data transmissions | |
| US6701415B1 (en) | Selecting a cache for a request for information | |
| US6182111B1 (en) | Method and system for managing distributed data | |
| US6081840A (en) | Two-level content distribution system | |
| US6963914B1 (en) | Method and apparatus for retrieving a network file using a logical reference | |
| US6457047B1 (en) | Application caching system and method | |
| US7555561B2 (en) | Cooperative adaptive web caching routing and forwarding web content data broadcasting method | |
| US6826593B1 (en) | Computer implemented method and apparatus for fulfilling a request for information content with a user-selectable version of a file containing that information content | |
| US20030004998A1 (en) | Proxy-based acceleration of dynamically generated content | |
| US6349326B1 (en) | Computer network read-ahead caching method | |
| US20020133570A1 (en) | Cooperative adaptive web caching routing and forwarding web content data requesting method | |
| PL192676B1 (en) | Method of and system for preliminary acquiring information | |
| US20030009563A1 (en) | Method for client-side inclusion of data elements | |
| CZ289563B6 (en) | Server computer connectable to a network and operation method thereof | |
| US6868453B1 (en) | Internet home page data acquisition method | |
| WO1989002631A1 (en) | Naming service for networked digital data processing system | |
| CA2487822A1 (en) | Methods and system for using caches | |
| WO2002089000A1 (en) | A system for caching data during peer-to-peer data transfer | |
| JPH10228408A (en) | Cache data finding method and cache server |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |