|Publication number||US20020026560 A1|
|Application number||US 09/169,223|
|Publication date||Feb 28, 2002|
|Filing date||Oct 9, 1998|
|Priority date||Oct 9, 1998|
|Also published as||CA2343802A1, CA2343802C, CN1255728C, CN1322315A, EP1119808A1, US6438652, WO2000022526A1|
|Publication number||09169223, 169223, US 2002/0026560 A1, US 2002/026560 A1, US 20020026560 A1, US 20020026560A1, US 2002026560 A1, US 2002026560A1, US-A1-20020026560, US-A1-2002026560, US2002/0026560A1, US2002/026560A1, US20020026560 A1, US20020026560A1, US2002026560 A1, US2002026560A1|
|Inventors||Kevin Michael Jordan, Kun-Lung Wu, Philip Shi-lung Yu|
|Original Assignee||Kevin Michael Jordan, Kun-Lung Wu, Yu Philip Shi-Lung|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (5), Referenced by (63), Classifications (10), Legal Events (6)|
|External Links: USPTO, USPTO Assignment, Espacenet|
 The present invention is related to load balancing among cooperating cache servers and in particular to load balancing based on load conditions and a frequency that requests are forwarded from cooperating cache servers.
 The growth in the usage of the World Wide Web has been increasing exponentially. As a result, response times for accessing web objects can become unsatisfactorily slow. One approach to improving web access time is to employ one or more proxy cache servers between browsers and the originating web servers. Examples of proxy cache servers include a cluster of PC servers running Microsoft's Windows NT™, such as the NETFINITY™ servers from IBM; and workstation servers running IBM's AIX™ operating system, such as the IBM RS/6000™ or SP/2™. In fact, more and more organizations, such as Internet Service Providers (ISPs) and corporations, are using a collection of cooperating proxy cache servers to help improve response time as well as reduce traffic to the Internet. A collection of cooperating cache servers have distinct advantages over a single cache server in terms of reliability and performance. If one fails, requests can still be serviced by other cooperating cache servers. Requests can be distributed among the servers, thus increasing scalability. Finally, the aggregate cache size is much larger so that it is more likely that a requested object will be found in one of the cache servers.
 With cooperating cache servers, a request that cannot be serviced locally due to a cache miss can be forwarded to another cache server storing the requested object. As a result, there are two kinds of requests that can come to a cache server: direct requests and forwarded requests. Direct requests are those that are received directly from clients. Forwarded requests are those that come from other cooperating cache servers on behalf of their clients due to cache misses on the cache servers. With requests forwarded among the cache servers, a cache server can easily become overloaded if it happens to contain in-demand (or“hot”) objects that most clients are currently interested in, creating uneven workloads among the cache servers. Uneven workloads can create a performance bottleneck, as many of the cache servers are waiting for the same overloaded cache server to respond to requests forwarded to it. Therefore, there is a need for a way to perform dynamic load balancing among a collection of proxy cache servers. The present invention addresses such a need.
 Load balancing is traditionally done by a front-end scheduler which“evenly distributes” incoming direct requests among the cache servers. For example, load balancing can be done at the DNS level by manipulating a mapping table, such as is done by the NETRA™ proxy cache by Sun Microsystems (“Proxy Cache Server, Product Overview”, white paper, Sun Microsystems, http://www.sun.com/). Load balancing among a cluster of servers can also be done with a front-end router, such as the NETDISPATCHER™ offered by IBM (see e.g., G. Goldszmidt and G. Hunt,“NetDispatcher: A TCP Connection Router,” IBM Research Report, RC 20853, May 1997). Here, incoming requests are distributed by the NETDISPATCHER™ to the least loaded server in the cluster. However, these traditional approaches distribute only“direct requests” and do not address a load imbalance problem resulting from too many requests for hot objects being simultaneously forwarded to the same proxy server. The present invention addresses such a need.
 Cooperative caching, or remote caching, has been used in distributed file systems to improve system performance (see“Cooperative caching: Using Remote Client Memory to Improve File System Performance,” by M. D. Dahlin et al., Proc. of 1st Symp. on Operating Systems Design and Implementation, pp. 1-14, 1994). Here, the file caches of a collection of workstations distributed on a LAN are coordinated to form a more effective overall file cache. Each workstation caches not only objects referenced by local requests but also objects that may be referenced by requests from a remote workstation. Upon a local cache miss, a local request can be sent to other client workstations where a copy can be obtained, if found. Otherwise, the object is obtained from the object server. The emphasis here is mainly how to maintain cache coherency in the face of updates and how to maintain cache hit ratios by moving a locally replaced object to the cache memory of another workstation. There is no dynamic load balancing.
 Cooperative caching is also used in collective proxy cache servers to reduce the access time. Upon a cache miss, instead of going directly to the originating web server potentially through a WAN, a cache server may forward the request to obtain the object from a cooperating cache server in a LAN or a regional area network. For example, upon a local cache miss in the SQUID system, a cache server multicasts a request (using the Internet Cache Protocol (ICP)) to a set of other cache servers ( see“Squid Internet Object Cache”, by D. Wessels et al., http://squid.nlanr.net/). If their caches contain the requested object, these cooperating cache servers reply with a message indicating such. The requested object is then obtained from the cooperating cache server which responded first to the request, instead of from the original web server on the Internet. However, if none replies after a time-out period, then the requested object will be fetched from the originating web server. Load imbalances can occur at a cache server due to forwarded requests.
 Instead of multicasting, the CRISP system uses a logical central directory to locate an object cached on another proxy server (see“Directory Structures for Scaleable Internet Caches”, S. Gadde et al., Technical Report CS-1997-18, Dept. of Computer Science, Duke University, 1997). Here, upon a cache miss, a cache server asks the directory server for the obj ect. With central knowledge of the caches object storage, the directory server sends such a request to the server whose cache includes the object. If found, the object is then sent to the requesting server while the original server continues to cache the object. If no cache has a copy of the requested object, the requesting server obtains the object from the originating web server through the Internet (potentially through a WAN). Again, this can create a load imbalance at the cache server due to subsequent requests forwarded to this cache server.
 Yet another way to locate an object on a cooperating cache server is through a hash function. An example is the Cache Array Routing Protocol (CARP) (see V. Valloppillil and K. W. Ross, “Cache Array Routing Protocol v 1.0,” Internet Draft, http://ircache.nlanr.net/Cache/ICP/draft-vinod-carp-v1-03.txt, February 1998). In CARP, the entire object space is partitioned among the cooperating cache servers, with one partition for each cache server. When a request is received by a cache server from a configured client browser, a hash function is applied to a key from the request, such as the URL or the destination IP address, to identify the partition. If the hash partition is the assigned to requesting cache server, then the request is serviced locally. Otherwise, it is forwarded to the proper cache server in the identified partition.
 SQUID, CRISP and CARP use the caches of other proxy servers to reduce the possibility of having to go through the WAN for a missed object. They differ in the mechanism for locating a cooperating cache server whose cache may contain a copy of the requested object. Each cache server services two kinds of requests: direct requests and forwarded requests. Direct requests are those made directly from the browsers connected to the proxy server. Forwarded requests are those made by cooperating cache servers whose caches do not have the requested objects. In any event, depending on the types of objects a proxy server caches at a given moment, its CPU could be overloaded because it is busy serving both direct and forwarded requests.
 In accordance with the aforementioned needs, the present invention is directed to a method and system for balancing the load across a collection of cache servers that process both direct and forwarded requests by shifting some or all forwarded requests to a less loaded cache server.
 For example, in a system including a collection of cooperating proxy cache servers, a request can be forwarded to another cooperating server if the requested object cannot be found locally. Instead of fetching the object from the originating web server through the Internet, a cache server can obtain a copy from a cooperating cache server in a local area network or an intranet. The average response time for access to an object can be significantly improved by the cooperating cache server. However, due to reference skew, some objects can be in high demand by all the clients. As a result, the proxy cache servers that contain those hot objects can become overloaded by forwarded requests coming from other proxy cache servers, creating a performance bottleneck. According to the present invention, we propose a load balancing method for a collection of cooperating proxy cache servers by shifting some or all of the forwarded requests from an overloaded cache server to a less loaded one.
 An example of a cache server load balancing method in accordance with the present invention includes the steps of: receiving forwarded requests from a cooperating cache server in response to a cache miss for an object on the cooperating cache server; and shifting one or more of the forwarded requests for the object between cooperating cache servers based on a load condition and a forwarding frequency for the object.
 The present invention also includes features for periodically monitoring the load condition on and the forwarding frequency to the owning cache server; and proactively shifting one or more subsequent forwarded requests for the cached object from the owning cache server to one or more of the cooperating cache servers, in response to the monitoring. Alternatively, the shifting step further includes the step of checking the load condition and forwarding frequency, in response to the receipt of a forwarded request. In one example, the load condition of the cooperating cache server is a weighted sum of a count of said forwarded requests, and a count of direct requests to said cooperating cache server. In another example, the cache information is maintained at: each object level; or a partition of objects level.
 The present invention also includes various implementations for performing the load balancing, including both centralized and distributed environments and various hybrids thereof. For example, a distributed load monitor can be used for monitoring and maintaining a local load condition, the forwarding frequency and ownership information for cached objects on each cooperating cache server. The cooperating cache servers can periodically exchange and maintain one or more of: the load condition information; the forwarding frequency; and the ownership information. For example, the cooperating cache servers can exchange information by piggybacking one or more of: the load condition information; the forwarding frequency; and the ownership information, with one or more of the forwarded requests and responses.
 In another example, an overloaded cooperating cache server can identify a less loaded cooperating cache server; and communicate a shift request and a copy of the cached object to the less loaded cooperating cache server (which then caches the object), so that subsequent requests for the object will not be forwarded. Alternatively, an overloaded cooperating cache server can communicate the shift request to the less loaded cooperating cache server, which then obtains a copy of the object from an originating object server, in response to the shift request. In yet another alternative, the owning cache server can multicast the shift request message to one or more of the other cooperating cache servers so that subsequent forward requests will be shifted.
 In a fully distributed implementation of the present invention, the cooperating cache servers can each include a distributed load monitor for monitoring and locally maintaining load conditions, and also can maintain the forwarding frequency and ownership information in a local copy of a caching table or by means of a hashing function. The cooperating cache servers can modify the ownership information by means of the local copy of the caching table or the hash function.
 The present invention includes still other features for modifying the ownership for the object to a shared ownership between at least two of the cooperating cache servers and forwarding subsequent object requests to one or more less loaded shared owners of the object. If a decrease in the load condition for a shared object is detected, the shared ownership can be merged, in response to the decrease in the load condition.
 In yet another example, the shifting of one or more of the forwarded requests based on the load conditon an the forwarding frequency can be accomplished by communicating a copy of the object from the owning cache server to one or more of the cooperating cache servers, so that subsequent requests will not be forwarded (as long as the object remains in the recipient's cache).
 An example of a centralized environment in accordance with the present invention includes: a centralized logical load monitor for maintaining the forwarding frequency and the load condition for the cooperating cache servers. The load monitor can include a logical directory server for maintaining a load table for monitoring the load on the cache servers and a caching table (or hash function) for monitoring the forwarding frequency and locating objects. The directory server receives requests for object locations in other cache servers for a locally missed object and forwards requests for locally missed objects. The directory server load balances requests among the cooperating cache servers by manipulating the caching table based on the load and the forwarding frequency for a given object, in response to the requests for object locations.
 These and other features, aspects, and advantages of the present invention will become better understood with reference to the following description, appended claims, and accompanying drawings wherein:
FIG. 1a shows an example of a system in a block diagram form employing a collection of proxy cache servers, wherein a centralized load balancing logic according to the present invention can be applied;
FIG. 1b shows another example of a system in a block diagram form employing a collection of proxy cache servers, where a distributed load balancing logic according to the present invention can be applied;
FIGS. 2a-b show examples of data formats for two tables that can be maintained by the load monitor depicted in FIGS. 1a-b;
FIG. 3 shows an example of a logic flow for the load monitor in response to a request from a cache server because of a cache miss; and
FIG. 4 shows an example of a logic flow for a cache server in response to a request for an object.
 Examples of the load balancing logic of the present invention will be described for both centralized and distributed architectures. FIG. 1a shows an example of a block diagram of a system employing a collection of proxy cache servers, where a centralized load balancing logic proposed in this invention can be applied. As depicted, the system includes a collection of proxy cache servers 150. Although only a single level of cache server is depicted, there could be a hierarchy of cache servers 150. As is conventional, these proxy cache servers are connected with each other through a local area network (LAN) or a regional area network or intranet 140. Each cache server 150 is also connected to a wide area network (WAN) or the Internet 110. Through the WAN, these proxy cache servers can reach 115 the originating web servers for objects that cannot be found locally on their own caches.
 According to the present invention a logical load monitor 120 includes a load balancing logic 130 for monitoring the load conditions and forwarding frequency (FIG. 2a) of the cooperating cache servers 150 and provides load balancing for them. As will be described below, various load monitor 120 features can: reside in one or more of the cache servers; be duplicated and distributed among the cache servers; or reside in another dedicated system such as a personal computer (PC) server or workstation. In a centralized system configuration, the load monitor 120 can perform a central directory function in directing forwarded requests 125 to the cache servers. One or more browsers 160 can be configured to connect to each cache server 150. Direct requests 155 are sent from the clients such as computers running conventional browsers 160 to the configured cache server 150. If the requested object can be found locally, then it is returned to the browser. Otherwise, the cache server 150 communicates a message to the load monitor 120. Various example implementations of the load monitor 120 will be described in more detail below. If no load imbalance condition or trend exits, the load monitor 120 then forwards the request 125 to the cache server 150 that owns the requested object. The owning cache server then sends the requested object to the requesting cache server, e.g., via the LAN 140.
 If an actual load imbalance is identified, or predicted based on a loading trend, the load monitor 120 initiates a shifting of forwarded requests from the overloaded cache server to one or more underloaded (or less loaded) servers. As will be described in more detail below, the shifting of ownership can be based on the load condition of the servers 150 and the forwarding frequency, as well as other factors.
FIGS. 2a-b shows examples of data formats of two tables maintained by the load monitor. As depicted, the tables include a load table 102, and a caching table 101. One skilled in the art will appreciate that a single table, or various other data structures could alternatively or equivalently be used. The load table 102 includes the load condition 1021 of each (A,B,C . . . 1022) cache server 150 so that overloaded and underloaded servers can be identified. As is conventional, load conditions 1021 can be updated periodically by probing each cache server. The load of a cache server can be a weighted sum of the number of forwarded requests and the number of direct requests. An overloaded cache server 150 can be identified by any conventional techniques, e.g., the load monitor can compute the mean load of all proxy cache servers in past intervals. Overloaded cache servers can be those with loads exceeding a threshold above the mean load. According to the present invention, load balancing takes into account the amount of overloading as well as the load due to the forwarding frequency 1011 of the cached objects. This way, the load monitor can decide whether or not to continue shifting some or all forwarded requests from an overloaded cache server C 10213 to an underloaded server A 10211. The caching table 1010 includes the forwarding frequency 1011 and ownership 1012 information of an object or a partition of objects. As will be discussed below, the ownership can be single as in A 10122, or shared 10121, 10123 among two or more cooperating cache servers. The forwarding frequency 1011 represents the number of times a request for an object has been forwarded through the load monitor. In addition to the forwarding frequency 1011, the caching table 101 can also maintain a timestamp 1013, indicating the most recent time a request for an object was forwarded. Further, the caching information for an object or a partition 1010 can include a forwarding frequency over a given time period (count/time) for the object ID or partition ID 1010 through the load monitor 120. Object partitions 1010 can alternatively be based on a hash function on object identifiers, or can be based on the directory structures that objects are organized by on the web servers. In the case of a partition, any object belonging to a partition will be forwarded by the load monitor. The shifting of ownership can be based on the load condition of the servers, the forwarding frequency 1011 and other information such as the time stamp information.
FIG. 3 shows an example of a logic flow for steps taken by the load monitor 120 in response to a request 125 from a cache server 150 because of a cache miss. As depicted, in step 201, it checks to see if the requested object/partition can be found in the caching table. If not, in step 202, a new entry is created for the object/partition and a cache server is assigned as its owner. After the entry is located in the caching table, in step 203, the forwarding frequency 1011 is updated, e.g., incremented by 1. The load monitor then examines the load table 102 to see if the owner is currently overloaded (and that the forwarding frequency 1011 is a significant contributor thereto), in step 204. If yes, in step 205, the load monitor finds an underloaded (or less loaded) cache server and assign it as the new 10122 (or shared) owner 10122 of the requested object. The ownership information 1012 for the object in the caching table 101 is updated accordingly. Those skilled in the art will appreciate that the logic flow could comprise a shared 10123 or hierarchical ownership 1012 in the caching table 101 or other data structure employed. The request (possibly with a copy of the requested object) can then be forwarded 125 to a new sole 10122 (or shared 10123) owner, in step 206. Alternatively, the new owner can be requested to obtain 115 an object copy from the originating object server, e.g., via the Internet 110. Those skilled in the art will appreciate that the load checking step 204 can be performed proactively, i.e., periodically or in response to an identified overload or overload trend 1021—due at least in part to a high forwarding frequency 1011—for a given object id/partition id 1010 and cache server (ownership 1012). If so, then in step 205, the load monitor finds an underloaded (or less loaded) cache server, assigns it as the new (or shared) owner of the requested object, and possibly sends a copy of the object to the new (or shared) owner as above. Conversely, if a shared ownership model is used, in step 208, when the load condition 10211 and forwarding frequency 10111 for a shared ownership object (p 10101) drops below a predetermined threshold, in step 209, the shared ownership (B, A 10121) can be merged to a single ownership and one of the copies purged from one of the cache servers A 10121, e.g., to make room for another hot object.
FIG. 4 shows an example of a logic flow for a cache server when a request for an object is received, either directly 155 from a browser 160 or forwarded 125 from the load monitor 120. As depicted, in step 301, it first checks to see if the requested object can be found locally in its cache. If yes, in step 302, it returns the object and the process ends, in step 306. Otherwise, in step 303, it checks to see if the request is a direct request or a forwarded request. If it is a direct request, in step 304, the request is sent to the load monitor and the process ends, in step 306. On the other hand, if the request is a forwarded request, in step 305, the cache server will fetch the object from the originating web server and return the object. The process then ends, in step 306.
 Referring now to FIGs. 1a and 2 a-b, assume for example, a browser 160 connecting to a cache server C 10223 requests 155 an object p 10101. From the caching table 101, it can be seen that object p 10101 is not cached on server C, but it is cached on (“owned” by) cache server B (assuming B, A 10121 is initially only solely designated by B). In response to a cache miss on object p, server C 10223 sends a request to the load monitor 120 for object p. Depending on the load condition 10212 and forwarding frequency 1011 of requests for p 10101 on server B, the load monitor may forward the request to server B, asking it to send a copy of object p to server C. Or, if server B is currently overloaded or is trending as such, the load monitor might shift the forwarded request by finding an underloaded (or less loaded) server to serve as a new (or shared as in B, A 10121) owner of object p. The request is then forwarded to the new (or shared e.g., A) owning server for the object. Note that even after the transfer of ownership, a copy of object p is still on server B's cache and can still serve direct requests coming to server B. However, in this example, all future forwarded requests for object p (or perhaps some, in the case of a shared ownership) will be shifted to server A. Alternatively, in the case of shared ownership B, A 10121, future forwarded requests for object p 10101 can be sent to the less loaded server.
 Now that a load balancing method according to the present invention has been described for a collection of proxy cache servers where a logical central directory is used for locating an object, various alternatives will be considered. The present invention can be adapted to achieve load balancing for these systems as well.
 For example, the present invention can be configured to perform load balancing for a collection of cooperating proxy cache servers where each cache server 150 multicasts to a list of cooperating cache servers to locate a copy of a locally missed object. In this case, no specific ownership information need be maintained anywhere in the system. However, there is also no guarantee of finding an object from the cooperating cache servers, either. Assume that a logical load monitor 120 is used to maintain the load conditions 1021 of all proxy cache servers and share this information with each cache server 150. The load balancing can be achieved by excluding overloaded servers from the list of cooperating servers to which a cache server multicasts its request (also called a shift request). As a result, only less loaded cache servers will receive forwarded requests 125.
 Another alternative is a load balancing method for a collection of cooperating proxy cache servers where a hash function is used to locate a copy of a locally missed object. In this case, the object space can be partitioned among the cooperating proxy cache servers 150, with one partition for each cache server. In order to achieve load balancing by shifting forwarded requests, one can change the hash function so that forwarded requests will not go to overloaded servers. One preferred approach is to hash the object space into a large number of buckets, much larger than the total number of proxy cache servers. These hash buckets are then assigned to the cache servers, with the goal of balancing the loads among them. Periodically, one can move one or more hash buckets from one overloaded server to an underloaded server, effectively changing the hash function.
 In either case, the load condition of the cooperating cache server can factor in the forwarding frequency directly into the calculated load condition. For example, the load condition can be a weighted sum of a count of said forwarded requests, and a count of direct requests to said cooperating cache server. Alternatively, the load monitor could separately maintain the overal forwarding frequency for each cooperating cache server.
 Referring now to FIGS. 1b and 2 a-b, yet another alternative is a load monitor 120 that is distributed, i.e., wherein some or all the load monitor is duplicated across the cache servers 150. In one example, the distributed load monitor includes local load condition information 1021 (and as described below, possibly the load conditions of all (A,B,C, . . . 1022)) of the cooperating cache servers 150. The distributed load monitor 120′ preferably also includes the caching table 101 with the forwarding frequency 1011 and ownership 1012 information for each object id/partition id 1010. Alternatively, a hashing function, for example as described above, could be distributed and stored in the cache servers. Load condition information 1021 and/or caching information 101: can be exchanged periodically; when there is a change in status (ownership or significant change in load condition); or piggybacked with cache forwarding requests and responses. Load condition 1021 information could also have a time stamp (not shown) associated with it for tracking or other purposes.
 Here, if a cache server 150 has a cache miss, the local load monitor 120′ looks up the ownership of the requested object in its local caching table 101 and forwards the request, to the owning cache server. Alternatively, the hash function could be applied to a key from the request, such as the URL or the destination IP address, to identify the partition and the request then forwarded to the correct cache server. When the forwarded request (i.e., from a cache server who had a cache miss) is received, the owning cache server identifies it as a forwarded request (e.g., by identifying it as from another cache server as opposed to a client) and updates its forwarding frequency 1011 information as applicable (FIG. 3, step 203). If an overload trend or condition is indicated (step 204), the owning cache server can respond to the requesting cache server with a shift request and a copy of the cached object. Alternatively, the requesting cache server can obtain a copy from the originating object server via an intranet, WAN or Internet 110. In either case, when the forwarding server caches a copy of the object, this server will no longer issue forward requests (steps 301, 302) as long as it remains in the cache, thus proportionally reducing the load on the owning server. In addition, the owning cache server can multicast a shift request message to one or more of the other cooperating cache servers 150 so that subsequent forward requests will be shifted, e.g., by updating their local copy of the caching table or modifying the hash function (step 205). At this point, other cache servers can forward their requests to the new owner (or to the least loaded owner of two or more cache servers 150 if ownership is shared) as indicated in their local copy of the caching table 101. When the original cache owner's load has decreased to an acceptable level (step 204), e.g., as indicated by a threshold, the shared ownership information can be merged to its original state (e.g., B,A 10121-->B).
 In the case that the load condition information 1021 for all cache servers ( A,B,C . . . 1022) is fully distributed, the requesting cache server could proactively check the load condition (and associated time stamp) of the owning server (step 204), i.e., before forwarding the request. If overloaded, the requesting server could request a copy of the object from the owning server (or from the originating server via the intranet or Internet 110) and possibly a load condition confirmation. The owning cache server could update its caching table 101 or modify the hash function to indicate the new shared ownership (step 205). The requesting server (or the owning server) could then multicast a message to all other cache servers 150 indicating the new shared ownership of the object and possibly include an updated load condition. At this point, other cache servers would update their caching tables 101 or modify the hash function to indicate the new shared ownership (step 202), and can forward their requests (step 206) to the least loaded owner of two or more cache servers 150 sharing ownership as indicated in their local copy of the caching table 101. When a shared cache owner's load has decreased to an acceptable level (steps 204 and 208), e.g., as indicated by a threshold, the ownership information can be merged to its original state, in step 209.
 A preferred embodiment of the present invention includes features that can be implemented as software tangibly embodied on a computer program product or program storage device for execution on a processor (not shown) provided with cache server 150 or other computer embodying the load monitor 120, such as in the centralized model described. For example, software implemented in a popular object-oriented computer executable code such as JAVA provides portability across different platforms. Those skilled in the art will appreciate that many other compiled or interpreted, procedure-oriented and/or object-oriented (OO) programming environments, including but not limited to REXX, C, C++ and Smalltalk can also be employed.
 Those skilled in the art will also appreciate that methods of the present invention may be the software may be embodied on a magnetic, electrical, optical, or other persistent program and/or data storage device, including but not limited to: magnetic disks, Direct Access Storage Devices (DASD), bubble memory; tape; optical disk formats such as CD-ROMs and DVD; and other persistent (also called nonvolatile) storage devices such as core, ROM, PROM, flash memory, or battery backed RAM. Those skilled in the art will appreciate that within the spirit and scope of the present invention, one or more of the components instantiated in the memory of the server 120′ could be accessed and maintained directly via disk (not shown), the network, another server, or could be distributed across a plurality of servers.
 While we have described our preferred embodiments of our invention with alternatives, it will be understood that those skilled in the art, both now and in the future, may make various improvements and enhancements which fall within the scope of the claims which follow. These claims should be construed to maintain the proper protection for the invention first disclosed.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US2151733||May 4, 1936||Mar 28, 1939||American Box Board Co||Container|
|CH283612A *||Title not available|
|FR1392029A *||Title not available|
|FR2166276A1 *||Title not available|
|GB533718A||Title not available|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US6490615 *||Nov 20, 1998||Dec 3, 2002||International Business Machines Corporation||Scalable cache|
|US6760765 *||Oct 20, 2000||Jul 6, 2004||Matsushita Electric Industrial Co., Ltd.||Cluster server apparatus|
|US6785707 *||Jun 21, 2001||Aug 31, 2004||Bitfone Corp.||Enhanced multimedia mobile content delivery and message system using cache management|
|US6973536 *||Aug 31, 2001||Dec 6, 2005||Oracle Corporation||Self-adaptive hybrid cache|
|US6980533 *||Aug 29, 2000||Dec 27, 2005||Lucent Technologies Inc.||Load balancing technique for a wireless internet access system|
|US7062570||Aug 3, 2001||Jun 13, 2006||Avaya Technology, Corp.||High performance server farm with tagging and pipelining|
|US7171469||Sep 16, 2002||Jan 30, 2007||Network Appliance, Inc.||Apparatus and method for storing data in a proxy cache in a network|
|US7177945||Aug 3, 2001||Feb 13, 2007||Avaya Technology Corp.||Non-intrusive multiplexed transaction persistency in secure commerce environments|
|US7188145 *||Jan 12, 2001||Mar 6, 2007||Epicrealm Licensing Llc||Method and system for dynamic distributed data caching|
|US7191290||Apr 25, 2003||Mar 13, 2007||Network Appliance, Inc.||Apparatus and method for tandem operation in a storage network|
|US7193968 *||Feb 8, 2001||Mar 20, 2007||Cisco Technology, Inc.||Sample netflow for network traffic data collection|
|US7228350 *||Aug 3, 2001||Jun 5, 2007||Avaya Technology Corp.||Intelligent demand driven recognition of URL objects in connection oriented transactions|
|US7263549 *||Apr 3, 2003||Aug 28, 2007||Hitachi, Ltd.||Web system using proxy server monitoring server and storage server for efficiently providing web access service to users within passenger transportation environment|
|US7284030||Sep 16, 2002||Oct 16, 2007||Network Appliance, Inc.||Apparatus and method for processing data in a network|
|US7373644 *||Oct 2, 2001||May 13, 2008||Level 3 Communications, Llc||Automated server replication|
|US7552223||Apr 25, 2003||Jun 23, 2009||Netapp, Inc.||Apparatus and method for data consistency in a proxy cache|
|US7624168||Feb 2, 2006||Nov 24, 2009||Hostway Corporation||Multi-layer system for scalable hosting platform|
|US7631078||Jan 16, 2007||Dec 8, 2009||Netapp, Inc.||Network caching device including translation mechanism to provide indirection between client-side object handles and server-side object handles|
|US7650376||Nov 20, 2000||Jan 19, 2010||Blumenau Trevor I||Content distribution system for distributing content over a network, with particular applicability to distributing high-bandwidth content|
|US7769823 *||Sep 28, 2001||Aug 3, 2010||F5 Networks, Inc.||Method and system for distributing requests for content|
|US7890701||Feb 15, 2011||Parallel Networks, Llc||Method and system for dynamic distributed data caching|
|US7958200 *||Aug 14, 2007||Jun 7, 2011||International Business Machines Corporation||Methods, computer program products, and apparatuses for providing remote client access to exported file systems|
|US7975032||Mar 29, 2010||Jul 5, 2011||Parallel Networks, Llc||Method and system for community data caching|
|US7996421||Jan 3, 2007||Aug 9, 2011||International Business Machines Corporation||Method, computer program product, and system for coordinating access to locally and remotely exported file systems|
|US8086674 *||Dec 27, 2011||Research In Motion Limited||Attachment server network for viewing attachments on a portable electronic device|
|US8103746||Jun 21, 2010||Jan 24, 2012||F5 Networks, Inc.||Method and system for distributing requests for content|
|US8135812||Jul 5, 2011||Mar 13, 2012||Parallel Networks, Llc||Method and system for community data caching|
|US8205044||Jun 19, 2012||Parallel Networks, Llc||Method and system for dynamic distributed data caching|
|US8217951 *||Mar 20, 2008||Jul 10, 2012||Lg Electronics Inc.||Graphic data processing apparatus and method|
|US8271628||Mar 13, 2012||Sep 18, 2012||Parallel Networks, Llc||Method and system for community data caching|
|US8352597||Dec 30, 2011||Jan 8, 2013||F5 Networks, Inc.||Method and system for distributing requests for content|
|US8504663||Sep 13, 2012||Aug 6, 2013||Parallel Networks, Llc||Method and system for community data caching|
|US8516081 *||Mar 12, 2010||Aug 20, 2013||Sony Corporation||Delivery server, content delivery method in delivery server and multicast server, content delivery method in multicast server|
|US8572326||Jun 18, 2012||Oct 29, 2013||Parallel Networks, Llc||Method and system for dynamic distributed data caching when a source of data is not available|
|US8595239||Jan 3, 2012||Nov 26, 2013||Google Inc.||Minimally disruptive hash table|
|US8676223||Mar 20, 2008||Mar 18, 2014||Qualcomm Incorporated||Backhaul communication for interference management|
|US8700759 *||Jan 19, 2007||Apr 15, 2014||International Business Machines Corporation||Autonomic optimization of presence server performance|
|US8756130 *||Mar 26, 2009||Jun 17, 2014||Scottrade, Inc.||System and method for the automated brokerage of financial instruments|
|US8768979 *||May 25, 2011||Jul 1, 2014||International Business Machines Corporation||In-memory data grid hash scheme optimization|
|US8775483 *||Mar 5, 2012||Jul 8, 2014||International Business Machines Corporation||In-memory data grid hash scheme optimization|
|US8825807 *||Oct 24, 2008||Sep 2, 2014||Sony Corporation||Delivery server, content delivery method of delivery server, booster server, content delivery method of booster server|
|US8862814||Aug 10, 2011||Oct 14, 2014||International Business Machines Corporation||Video object placement for cooperative caching|
|US8984048||Apr 18, 2011||Mar 17, 2015||Viasat, Inc.||Selective prefetch scanning|
|US9043385 *||Apr 18, 2011||May 26, 2015||Viasat, Inc.||Static tracker|
|US9083710 *||Jan 3, 2012||Jul 14, 2015||Google Inc.||Server load balancing using minimally disruptive hash tables|
|US9110606||Jan 4, 2007||Aug 18, 2015||Samsung Electronics Co., Ltd.||Method and apparatus for accessing home storage or internet storage|
|US20020062372 *||Aug 3, 2001||May 23, 2002||Jack Hong||High performance server farm with tagging and pipelining|
|US20020073232 *||Aug 3, 2001||Jun 13, 2002||Jack Hong||Non-intrusive multiplexed transaction persistency in secure commerce environments|
|US20040215703 *||Feb 4, 2004||Oct 28, 2004||Xiping Song||System supporting concurrent operation of multiple executable application operation sessions|
|US20060123217 *||Dec 7, 2004||Jun 8, 2006||International Business Machines Corporation||Utilization zones for automated resource management|
|US20080172451 *||Oct 22, 2007||Jul 17, 2008||Samsung Electronics Co., Ltd.||Meta data information providing server, client apparatus, method of providing meta data information, and method of providing content|
|US20090187502 *||Mar 26, 2009||Jul 23, 2009||Scottrade, Inc.||System and Method for the Automated Brokerage of Financial Instruments|
|US20100257257 *||Mar 12, 2010||Oct 7, 2010||Sony Corporation||Delivery server, content delivery method in delivery server and multicast server, content delivery method in multicast server|
|US20110040893 *||Jan 29, 2010||Feb 17, 2011||Broadcom Corporation||Distributed Internet caching via multiple node caching management|
|US20110225373 *||Nov 16, 2010||Sep 15, 2011||Hitachi, Ltd.||Computer system and method of data cache management|
|US20120054440 *||Aug 31, 2010||Mar 1, 2012||Toby Doig||Systems and methods for providing a hierarchy of cache layers of different types for intext advertising|
|US20120303634 *||May 25, 2011||Nov 29, 2012||International Business Machines Corporation||In-Memory Data Grid Hash Scheme Optimization|
|US20120303675 *||Mar 5, 2012||Nov 29, 2012||International Business Machines Corporation||In-Memory Data Grid Hash Scheme Optimization|
|US20150188758 *||Dec 31, 2013||Jul 2, 2015||Sonic Ip, Inc.||Flexible network configuration in a content distribution network|
|CN102118433A *||Dec 27, 2010||Jul 6, 2011||网宿科技股份有限公司||Multiple-tier distributed cluster system|
|EP1279108A1 *||Mar 27, 2001||Jan 29, 2003||Trevor I. Blumenau||Content distribution system for distributing content over a network, with particular applicability to distributing high-bandwidth content|
|WO2004025429A3 *||Sep 16, 2003||Jul 1, 2004||Network Appliance Inc||Apparatus and method for proxy cache|
|WO2007092140A1 *||Jan 17, 2007||Aug 16, 2007||Hostway Corp||Multi-layer system for scalable hosting platform|
|U.S. Classification||711/120, 711/147, 709/203, 711/130, 711/144|
|International Classification||G06F13/00, G06F9/50, G06F12/00|
|Oct 9, 1998||AS||Assignment|
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:JORDAN, KEVIN MICHAEL;WU, KUN-LUNG;YU, PHILIP SHI-LUNG;REEL/FRAME:009517/0848;SIGNING DATES FROM 19981008 TO 19981009
|Nov 18, 2005||FPAY||Fee payment|
Year of fee payment: 4
|Jan 21, 2010||FPAY||Fee payment|
Year of fee payment: 8
|Mar 28, 2014||REMI||Maintenance fee reminder mailed|
|Jul 11, 2014||FPAY||Fee payment|
Year of fee payment: 12
|Jul 11, 2014||SULP||Surcharge for late payment|
Year of fee payment: 11