Managed object replication and delivery

Abstract
A method, system and computer program product for managed object replication and delivery redirects, directly or indirectly, a client's request for an object that is not available at a best or optimal handling edge server of a network to a parent server that has the requested object. So, where the requested object is not available at the handling edge server, the client's request is redirected directly to the parent server that can provide the requested object to the client or indirectly via one or more parent servers to a parent server that can provide the requested object to the client. The method, system and computer program product further intelligently replicates the object to the edge server if the object is popular enough. Likewise, an object is removed from an edge server when it is no longer popular. All redirection and replication operations are preferably transparent to the end-user and do not degrade the quality of service.
Description
BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the invention are illustrated in the accompanying drawings in which like references indicate similar or corresponding elements and in which:



FIG. 1 is a high-level block diagram of a topology of the managed object replication and delivery method and system according to embodiments of the invention;



FIG. 2 is a high-level block diagram illustrating the data flows of managed object replication and delivery method according to embodiments of the invention;



FIGS. 3(a), 3(b) and 3(c) are a flow chart of the managed object replication and delivery method and the object purging method according to embodiments of the invention;



FIG. 4 is a flow chart of a popularity computation according to embodiments of the invention;



FIG. 5 is a flow chart of a replication scheme according to embodiments of the invention;



FIG. 6 is a flow chart of a purge scheme according to embodiments of the invention; and



FIG. 7 is a block diagram of the managed object replication and delivery system according to embodiments of the invention.







DETAILED DESCRIPTION

A typical content delivery network (CDN) operator deploys one or more parent servers, hosting a plurality of objects, in a network and one or more edge servers at the edge of the network to facilitate more cost-effective and efficient delivery of such objects to an end-user (client). End-users or client proxies that access customers' objects are called clients. Content provider companies, organizations, etc. that subscribe to the CDN service are referred to as customers. As used herein, an object includes, without limitation, an audio file (such as, e.g., an MP3 (Motion Picture Experts Group-1 Layer 3) file and a RealNetworks, Inc. Real format file), a video file (such as an MPEG file), an image file (such as, e.g., a BMP (bitmap) file or JPEG (Joint Photographic Experts) file) and any other software or data file or object. It is typically desirable to serve objects from edge servers because the edge servers are typically closer (by various measures of distance) to end-users. For example, streaming content data from edge servers saves parent-to-edge bandwidth. Furthermore, the less the distance objects must travel can also mean reduced network congestion and packet losses, which can lead to a better experience for the end-user through faster response times and better quality of service.


It is typically not feasible to store all objects on the edge servers. The main difficulty is due to the fact that many such objects are very large (typically on the order of 10 MB (10,000,000 bytes)—in the neighborhood of 500 MB for movies). The storage and rack space required to accommodate often large and sometimes rarely requested objects at every edge server can be cost prohibitive as the number of customers grows and the number of their objects increases. It may not even be possible to store a good working set of objects, for example a set of objects thought to be requested often and/or better suited to be served from an edge server, because of the size and changing demand for objects in the working set.


One obvious solution is to pre-populate edge servers with objects for which there will likely be a significant or high demand. However, it is difficult to predict popularity and difficult to manage pre-populating. A related solution is to associate objects with two or more domains depending on popularity of the object, e.g., one domain for popular objects (served from edge servers) and another domain for less popular objects (served from parent servers). However, this requires some way to pre-determine what objects are popular and what objects are less popular statically, and build that popularity into the domain name of the object. As with pre-populating, it is difficult to predict popularity and to manage assignment of domains based on such popularity determinations.


Other solutions fetch objects on demand. In such schemes, when a requested object is not available on a handling edge server, a connection is made between a parent server having the requested object and the handling edge server to fetch the requested object from the parent server. Such fetching suffers however from having to go through the parent path (the network path between the handling edge server and the parent server with the object) whenever a client requests an object that is not already at the particular edge server.


Fetching a large object to the handling edge server through a parent path can be slow. For example, there may be limited available bandwidth from the parent server to the handling edge server, i.e., sometimes the parent path has less bandwidth than even the network path from the edge server to the client (e.g., the “last mile” in a broadband network). If a parent server uses too much bandwidth copying an object to an edge server, this can create congestion at that parent server. If storage fill bandwidth is matched to client bandwidth, it is difficult to handle a second, faster client and if fetch is done using a streaming protocol (for instance, the Real-Time Streaming Protocol (RTSP) and Real-Time Transport Protocol (RTP) standards), the quality of the copy made can be hurt due to lost packets (“thinning”).


Moreover, there may be an unreliable end-to-end parent path due to network congestion. And, if a parent server has to preprocess an object (e.g., to generate an image at a specific bit rate) or is otherwise busy with other tasks, this may further slow its ability to serve the request for the object fast enough. For example, if a client requests a bit rate higher than the parent-to-edge bit rate, delays will likely occur. Under such conditions, the parent server may fail, for example, to stream the object in time or to maintain the stream of an object at a requested bit rate thereby causing a thinned object, i.e., an object with lower quality due to lost packets in its transmission, to be populated at the edge server and delivered to subsequent clients requesting the same object.


Thus, it would be advantageous to populate edge servers with the most popular objects yet somehow serve the rest from parent servers with a goal to maximize the amount of object bits served from edge servers of the network. It would also be advantageous to populate edge servers by, for example, storage fill on demand when an object is popular enough, without having to make the end-user wait for such population. Therefore, it would be advantageous to provide a method and system for managed object replication and delivery over a network.


According to embodiments of the invention, a method and system for managed object replication and delivery over a network redirects, directly or indirectly, a client's request for an object that is not available at a best or optimal handling edge server of the network to a parent server of the network that has the requested object. So, where the requested object is not available at the handling edge server, the client's request is redirected directly to the parent server that can provide the requested object to the client or indirectly via one or more parent servers to a parent server that can provide the requested object to the client. The method and system further intelligently replicates the object to the edge server if the object is popular enough. Likewise, an object is removed from an edge server when the object is no longer popular. All redirection and replication operations are preferably transparent to the end-user and do not degrade the quality of service. Other embodiments of the invention are possible and some are described hereafter.


So, for example, under the framework described herein, a request for a streaming object will be served by a handling edge server if that handling edge server has a copy of that object. Otherwise, the request is redirected, directly or indirectly, to a parent server for service of the requested streaming object to the client. If the requested streaming object is popular, the object is replicated from a parent server that has the requested streaming object to the handling edge server so that the handling edge server will serve the object from the edge of the network when the object is requested in the future. If a streaming object is no longer popular, the object is removed from an edge server.


As used herein, replication generally refers to the permanent and/or volatile storage of an object in a server, particularly an edge server and if applicable, a parent server. Accordingly, the term replication will be considered synonymous to storing, caching and copying. In typical embodiments, replication of an object will usually refer to temporary storage of the object in an edge server and/or a parent server for an undefined duration.


A typical network for the managed object replication and delivery method according to embodiments of the invention is illustrated in FIG. 1. The network 100 comprises one or more parent server sites 120 and one or more edge server sites 130. The network also optionally has access to one or more origin server sites 110. The origin server sites are typically owned and/or maintained by the network provider's customers for storing and serving one or more objects. Each customer (content provider) may have its own origin server site. Furthermore, one or more clients 140 access the network to request one or more objects. A parent server site (or simply parent site or parent server) may comprise one parent server or a cluster of parent servers. Likewise, an edge server site (or simply edge site or edge server) may comprise one edge server or a cluster of edge servers and an origin server site (or simply origin site or origin server) may comprise one origin server or a cluster of origin servers. Typically, the network 100 is configured such that servers in a cluster share a common storage. In any event, configuration details of the parent server site, edge server site, and the origin server site are not important to the present invention.


In the typical network, the parent servers and edge servers are maintained by a network provider, wherein the parent servers are primarily used for storing and managing one or more objects and edge servers are primarily used for serving objects to clients. In some embodiments, all the objects are retrieved from origin servers and stored over one or more parent servers before any end-users can access each such object as the object is stored on the parent servers. Accordingly, in these embodiments, the origin servers play no significant role in the managed object replication and delivery method except to supply new and/or updated objects for storage on the parent servers. Moreover, only the parent servers communicate with the origin servers. In other embodiments, each requested object is replicated from one or more origin servers to one or more parent servers (and/or one or more edge servers) when the requested object becomes popular (as described in more detail below). In these embodiments, the origin servers play a more significant role in the managed object replication and delivery method to supply objects to parent and/or edge servers when requested. So, in these embodiments, the origin servers and parent servers communicate between each other and the origin servers and clients may also communicate between each other. In all of these embodiments, the communications relationships between origin servers and parent servers may be one-to-one, one-to-many or many-to-many.


Further, as shown in FIG. 1, the parent servers and edge servers communicate between each other, edge servers and clients communicate between each other and parent servers and clients communicate between each other. While in embodiments, as shown in FIG. 1, the edge servers have a one-to-one or one-to-many communications relationship with parent servers, edge servers may also have many-to-many communications relationships with parent servers. As discussed in more detail below, the edge servers act as the primary source of serving objects but if a requested object is not available at the edge server a parent server that has the requested object will serve the requested object to the clients. Also, FIG. 1 shows a single layer or level of parent servers and origin servers. As will be apparent to those skilled in the art, more than one layer or level of parent servers and/or origin servers may be used.


According to embodiments of the invention and referring to FIGS. 2, 3(a), 3(b) and 3(c), the method of managed object replication and delivery and the method of object purging is depicted. FIG. 2 depicts embodiments of the method in relation to a portion of the network 100, an origin server 110 and a client 140 as shown in FIG. 1. FIGS. 3(a), 3(b) and 3(c) depict embodiments of the method in flowchart form.


Initially, the method of managed object replication and delivery directs (at 200, 300) a client, requesting one or more objects, to an edge server in the network, whether or not the edge server has the requested object(s). Preferably, the client is directed to an optimal edge server, e.g., based on network traffic conditions and server load. As will be apparent to those skilled in the art, any number of currently known or future developed mechanisms may be used to select a best or optimal edge server. Determination of a best or optimal edge server preferably includes selection of an edge server most suitable for delivery of one or more objects to the client according to any number of currently known or future developed algorithms. For example, determination of a best or optimal edge server may be performed based on the likelihood of a copy of the requested object(s) being available at the candidate edge server, on the bandwidth between a candidate edge server and the client, on a best repeater selector (for example, as described in U.S. Pat. No. 6,185,598) and/or on any number of other criteria.


The selected best or optimal edge server 130 determines (at 305) whether the edge server already has the requested object and, if so, serves (at 205, 310) the object to the requesting client 140. For example, the selected edge server 130 will check its storage to determine whether the requested object is available and if so, may serve the object to the requesting client 140.


If the selected edge server does not have the requested object, a check is initiated (at 315) for the edge server to determine whether the requested object is popular and if so, to replicate the popular requested object to the edge server. In embodiments, the method depicted in FIG. 3(b) and discussed in more detail below is employed to determine whether the requested object is popular and if so, to replicate the popular requested object to the edge server.


In embodiments, the checking of whether the requested object is popular and replicating the popular requested object to the edge server may be performed independently of one or more functions of the method of managed object replication and delivery, such as the checking if a server has the requested object and serving the requested object to the client if the server has the requested object or redirecting the client to a server that has the requested object (and serving the requested object to the client). Thus, in embodiments, the checking of whether the requested object is popular and replicating the popular object to the edge server may be performed in parallel with or before the performance of certain functions of the method of managed object replication and delivery such as the checking if a server has the requested object and serving the requested object to the client if the server has the requested object or redirecting the client to a server that has the requested object (and serving the requested object to the client). Advantageously, should the checking, redirecting and serving of the requested object fail, the checking of whether the requested object is popular and replicating the popular object to the edge server can manage the continued delivery of objects to clients from edge servers. Similarly, if the checking of whether the requested object is popular and replicating the popular object to the edge server should fail, the checking, redirecting and serving of the requested object can manage the continued delivery of objects from servers in the network.


Further, if the selected edge server does not have the requested object, the selected edge server directs (at 210, 320) the requesting client 140 to a parent server 120. Preferably the client 140 is redirected to a parent server that has the requested object and is able to serve (at 215, 345) the requested object to the client. If a parent server does not have (at 325) the requested object, a check is initiated (at 330) for the parent server to determine whether the requested object is popular and if so, to replicate the popular requested object to the parent server. In embodiments, the method depicted in FIG. 3(b) and discussed in more detail below is employed to determine whether the requested object is popular and if so, to replicate the popular requested object to the parent server. As with the check for the edge server, in embodiments, the checking of whether the requested object is popular and replicating the popular requested object to the parent server is performed independently of one or more functions of the method of managed object replication and delivery such as the checking if a server has the requested object and serving the requested object to the client if the server has the requested object or redirecting the client to a server that has the requested object (and serving the requested object to the client). Thus, in embodiments, the checking of whether the requested object is popular and replicating the popular requested object to the parent server may be performed in parallel with or before one or more functions of the method of managed object replication and delivery such as the checking if a server has the requested object and serving the requested object to the client if the server has the requested object or redirecting the client to a server that has the requested object (and serving the requested object to the client).


Further, if a parent server does not have the requested object, the parent server could itself use a redirection technique recursively (at 325, 335, 320) until a final parent server is reached that has the requested object. The parent server that has the requested object serves (at 215, 345) the object to the client. If the object is determined to be unavailable (at 335) (from all parent servers), an error message is returned (at 340) regarding the unavailability of the requested object.


As will be apparent to those skilled in the art, numerous methods are available to redirect a requesting client to another parent server, depending on the protocol(s) used to request the object. A handling edge server may request information from a database about to which parent server the client should be redirected. In an implementation, the edge server might have a local database, populated by pushes of redirection data from one or more servers in the network. The edge server may also simply query one or more servers in the network to identify one or more parent servers to which the client can be directed. When more than one parent server responds, the edge server may redirect the client to the parent server that responds to the query first, the edge server may redirect the client to the parent server that is topologically closest to the edge server in the network or the edge server may redirect the client to the parent server that represents the best or optimal candidate based on criteria such as network efficiency, bandwidth requirement and/or cost. Alternatively, an edge server may always go to default parent servers. Or, as discussed in relation to edge servers, a best or optimal parent server may be determined using any of the techniques outlined above. Redirection may be performed by simply sending the request onto a parent server or returning redirection information to the client for accessing the parent server. As will be apparent to those skilled in the art, any number of implementations may be used to provide the redirection information to the handling edge server.


In other embodiments, where the parent servers collectively are not populated with all of the objects and the network has access to the origin server of a requested object, the client may be redirected (at 225, 320) to the origin server if the requested object is not available on the parent servers. If the origin server has the requested object (at 325), the origin server would serve (at 230, 345) the object directly to the client (not shown in FIG. 1). Otherwise if the object is unavailable (at 335), an error message would be returned (at 340) regarding the unavailability of the requested object.


Referring to FIG. 3(b), when an edge and/or parent server determines (at 350) that a requested object is popular (by some measure of popularity) but the edge and/or parent server does not have a copy of the object, the edge and/or parent server initiates a pull of the object to the edge and/or parent server. So, for example, when the edge server determines (at 350) that a requested object is popular but the edge server does not have a copy of the requested object, the edge server initiates the replicating (at 220, 360) of the popular requested object to the edge server from a parent server that has the requested object. Similarly, for example, when a parent server 120 determines (at 350) that a requested object is popular but the parent server does not have a copy of the requested object, the parent server initiates the replicating (at 240, 360) of the popular requested object to the parent server from an origin server that has the requested object. Alternatively, a parent and/or origin server may receive information regarding object popularity, such as popularity determinations for objects or data about object popularity, from one or more edge and/or parent servers and may push popular objects to the edge and/or parent servers. So, for example, when the parent server determines (at 350) that a requested object is popular at an edge server but the edge server does not have a copy of the requested object, the parent server may initiate the replicating (at 220, 360) of the popular requested object to the edge server from the parent server. Similarly, for example, when the origin server determines (at 350) that a requested object is popular at a parent server but the parent server does not have a copy of the requested object, the origin server initiates the replicating (at 240, 360) of the popular requested object to the parent server from the origin server.


In some embodiments, if none of the parent servers has the requested object, the edge server initiates the replication (at 235, 360) of the popular requested object to the edge server from the origin server having the requested object (if the network has access to the origin server). Preferably, in each case, the replicated object is not served or further replicated until the object has been completely copied to the respective server. Optionally, such replicating may be utilized by and between the parent servers themselves to facilitate the reduction of the traffic to and from the origin server. Further, if the edge and/or parent server does not have adequate space for the popular requested object, one or more objects may be purged (at 355) from the edge and/or parent server to make space for the popular object. In embodiments, the method depicted in FIG. 3(c) and discussed in more detail below is employed to determine whether any object(s) in the edge and/or parent server is no longer popular and if so, to delete the no longer popular object(s) from the edge and/or parent server. Also, as will apparent to those skilled in the art, servers other than the edge and/or parent server for which an object is determined popular may perform the actual determination of whether an object is popular by using for example, popularity information provided by the handling edge and/or parent server. The popularity determinations can then be used to initiate replication (for example, pushing or pulling) of the object to the edge and/or parent server for the which the object is determined popular.


Referring to FIG. 3(c), if an object in a server's storage is no longer popular (at 365), the server may delete the object (at 370) from the storage. For example, an edge server may delete (at 245, 370) any objects from the edge server's storage that are no longer popular. Similarly, a parent server may delete (at 250, 370) any objects from the parent server's storage that are no longer popular. As will be apparent to those skilled in the art, the determining of whether any object(s) in the server's storage is no longer popular and if so, deleting the no longer popular object(s) from the server's storage may be performed independently of, for example in parallel with or before, one or more functions of the method of managed object replication and delivery. In embodiments, the no longer popular objects are removed from edge servers and, if the no longer popular objects are hosted on an origin server, from parent servers.


Determining Popularity


Any number of techniques may be used to determine the popularity of an object. Determining the popularity can be based on the number of requests. Popularity can also be based on the request rate. Popular objects typically have higher request rates or higher number of requests than unpopular objects. Popularity can also be determined by tracking the last X number of request times for an object and then use the difference between the current time and these request times to calculate a running average for how often the object is requested. Determining the popularity can also be gauged on the request rate for an object that is perhaps weighted for more recent requests for the object (which is a predictor that the object will be requested again). An exponential decay method and an artificial neural network could also be used to determine popularity of an object.


According to some embodiments of a popularity computation and referring to FIG. 4, the popularity of an object is based on the request rate of the object and computed over a sliding time window in a discrete manner. In these embodiments, the variable I denotes the time interval over which the popularity of an object is measured. The time interval is divided into N equal sub-intervals of duration I/N. As will be apparent, the time interval is not required to be equally divided and may instead be divided in other manners.


A linked list P of size N is created for each object. The value of N determines the quality of approximation. The smaller the value of N, the coarser the approximation. In some embodiments, the value of N is set to 5.


The first element P[1] of the list records the number of requests that arrived when the current time was within the first sub-interval, the second element P[2] records the number of requests that arrived when the current time was within the 2nd interval, and so on. When a new sub-interval arrives, the list is rotated such that P[I] becomes P[I+1] except for P[N] which becomes P[1], so, e.g., P[1] becomes P[2], P[2] becomes P[3], and P[N] becomes P[1]. After the rotation, the new P[1] is reset to zero. Accordingly, only the end time of the first sub-interval needs to be recorded and compared against the current time to check if the list should be rotated. For each new request within the sub-interval, P[1] is simply incremented by 1. In this way, the arrival time of each request need not be recorded.


In preferred embodiments, the popularity of an object is simply the sum of all numbers in the list. To make the computation more efficient, the sum of P[2]+P[3]+ . . . +P[N] is stored in a register M. The popularity can be then computed by adding P[1] to M. When a rotation occurs, the new value of M becomes M+=P[1]−P[N]. The popularity of an object may be queried constantly. So, to avoid the extra addition involved for each such inquiry, the value of P[1] can be set to M after the rotation. Then, the value of P[1] is the popularity of the object.


The popularity computation algorithm may be summarized as follows. The linked list P of size N for an object, wherein each of P[1] . . . P[N] represents a time sub-interval, is initialized (at 400). The popularity M is also initialized (at 410). If there is a request for the object while the current time is within the current time sub-interval (at 420), then the value of P[1] is incremented (at 430) by 1. If the current time is within a new time sub-interval (at 440), then the value of P[1] is decremented by the value of M, M+=P[1]−P[N], the list P is rotated and P[1] is set to the value of M (at 450). Then, provided the popularity computation is continued (at 460) e.g., the popularity computation is not terminated, the popularity computation algorithm repeats itself.


Initiating Replication


Furthermore, any number of techniques may be used to initiate replication of an object. An edge server and/or a parent server might replicate an object on the first request by a client for the object. Alternatively, the edge server and/or parent server may be tuned to wait until the edge server and/or parent server receives a specific number or range of requests for the object. In other implementations, the object may be pulled if the object is more popular (e.g., a higher request rate) than the least popular object currently in the storage. In yet another alternative, the replicating decision can be a function of the popularity of the object, the cost of storing the object, the cost of pulling the object from the network and any other relevant cost factors. However, the popularity of objects may change significantly with time. Initiating a pull decision of an object purely based on a fixed threshold does not capture this dynamic nature of popularity.


A replication policy that compares against the least popularity of replicated objects has its limitations, although the policy does not use a fixed threshold. Consider where the storage is only half full but all the replicated objects are extremely popular. Since only objects exceeding the least popularity of the replicated objects will be replicated under this replication policy, objects with moderate popularity will be rejected despite that there is plenty of storage space available and that the objects are reasonably popular.


Accordingly, a replication scheme should be able to automatically adjust the replication threshold by taking into consideration the dynamic nature of popularity and the fullness of the storage. If there are more popular objects than the storage capacity allows, the replication scheme should raise the threshold. If there is more available storage capacity, the replication scheme should decrease the threshold so that more objects can be stored.


According to embodiments of a replication scheme and referring to FIG. 5, an object is replicated (at 520) into storage when the popularity P of the object is greater (at 500) than the initial threshold P.sub.I and when there is enough space (at 510) in the storage to replicate the object. If there is not enough storage to replicate the requested object, a replacement algorithm is performed in which the popularity P of the object is compared (at 530) against the popularity P.sub.L of the least popular object in the storage. If P is greater than P.sub.L, the current least popular object is removed (at 540) from the storage to free up more storage space, the next least popular object is identified (at 540), the value of the least popularity is updated (at 550), and a new iteration begins by checking if there is enough storage space to store the requested object (at 510). The storage space freeing iteration is terminated when either 1) enough storage space has been freed up to accommodate the requested object or 2) the requested object is not as popular as the least popular object in the storage. In embodiments, the least popular objects are removed from edge servers and, if there are origin servers with a copy of the least popular objects, from parent servers. Where no origin servers exist with a copy of the least popular objects, least popular objects are not removed from parent servers in order to keep a copy of the least popular objects in the network.


Purging


In some embodiments, the managed object replication and delivery method and system records the time on which an object was last requested. A purge scheme is invoked to clean up the storage of servers, for example, on a regular time interval basis or when a popular object is replicated to an edge and/or parent server but there is inadequate space at the edge and/or parent server. Referring to FIG. 6, in the purge scheme, all stale objects are removed from the storage (at 600), the remaining objects are sorted based on popularity (at 610), and the new values of P.sub.L and P.sub.I are determined (at 620, 630). An object is stale if its age (that is the time since the object was last requested) is over a pre-defined value, typically set to the duration of the sliding window used to measure the popularity multiplied by an adjustable factor. As will be apparent to those skilled in the art, the value may vary and indeed other staleness algorithms may be used. The popularity of the least popular object in the storage after purging is assigned as the new P.sub.L. The new P.sub.I is determined by using the sorted popularity and is set to the popularity of the last object that can fit into the storage if more popular objects are replicated first. Typically, P.sub.L should be greater than or equal to P.sub.I. If not, the value of P.sub.L is assigned to be the new P.sub.L. In some embodiments, the purge process is implemented as a separate thread in a multi-thread system. In embodiments, the stale objects are removed from edge servers and, if there are origin servers with a copy of the stale objects, from parent servers. Where no origin servers exist with a copy of the stale objects, stale objects are not removed from parent servers in order to keep a copy of the stale objects in the network.


At the outset when the system starts and there is no popularity data available yet, the initial values of both P.sub.L and P.sub.I can be set to zero. This forces the replication scheme to store the objects on their first request, but the purge scheme that is run on a regular basis will adjust the values of P.sub.L and P.sub.I automatically. The initial values of P.sub.L and P.sub.I can also be set to other values. Indeed, the initial values of P.sub.L and P.sub.I can be determined by taking into consideration the cost of storage, the cost of fetching, and the cost difference in deliveries from different servers. In any case, the system allows the specification of minimum P.sub.L and P.sub.I. If a computed P.sub.L or P.sub.I is smaller than the minimum specification, P.sub.L or P.sub.I is set to the minimum specification.


In some embodiments, to avoid or minimize stream thinning and other quality problems, storage fill is separated from data delivery. In this way, the data transfer between multiple sets of storages can tolerate a slower connection, and a server never streams an object unless the object is entirely in the storage. As will be apparent to those skilled in the art, it is possible to start streaming an object when there is enough data in the storage and that replication need not be completed before serving the object. Further, storage fill may be staged by copying to a separate location, then moving the copied data to a servable location when the data is complete.


Further, if an object is changed at an origin server, there may be a need to broadcast a message to remove the object at one or more parent servers and/or one or more edge servers. Similarly, if an object is changed at the parent server(s), there may be a need to broadcast a message to remove the object at one or more edge servers. In each case, future requests for the removed object would be handled as in the normal case where a requested object is not available at an edge server and/or a parent server.


Hardware and Software


In embodiments of the invention, referring to FIGS. 1 and 7, the system of managed object replication and delivery comprises one or more servers in a network designated as parent servers and one or more servers in the network designated as edge servers. In some embodiments, referring to FIG. 1, parent servers 120 have large storage capacity (on the order of 5 terabytes (TB)) while edge servers 130 have smaller storage space (ranging from 1 TB to 500 GB). One or more redirectors for implementing the method of managed object replication and delivery are installed on each edge server cluster. In some embodiments, one or more objects are replicated to one or more of the parent servers from the origin servers and then pulled from the parent servers to the edge servers as needed. In other embodiments, one or more objects are replicated to one or more of the edge servers and/or to one or more of the parent servers, from the origin servers as needed.


In some embodiments, a data transfer method 700, 710 is implemented to transfer data between parent servers and edge servers. The data transfer method supports the Transport Layer Security (TLS) protocol (described in the Internet Engineering Task Force (IETF) RFC 2246, located at “http://www.ietf.org/rfc/rfc2246.txt”, incorporated by reference herein) to ensure communication privacy. Further, the implementation of the method for managed object replication and delivery supports three popular object formats, namely Apple Computer, Inc.'s QuickTime™, RealNetworks, Inc.'s Real™, and Microsoft Corporation's WindowsMedia™ formats for streaming of requested object(s). As will be apparent to those skilled in the art, any number of other protocols and object formats may be used.


Further, in some embodiments, a number of software components are used to facilitate the method of managed object replication and delivery. A first component is a WindowsMedia redirector 720, 760 which is a service running on the Microsoft Windows NT operating system that processes requests from a Windows Media player and performs the redirection of the request for Windows Media objects. The WindowsMedia redirector is provided on edge servers and parent servers. Currently, the Microsoft Media Server (MMS) protocol is used for streaming of Windows Media objects and that protocol does not support redirection. To provide redirection for the streaming of Windows Media objects, the uniform resource identifier (URI) hyperlinks at the customer's site for such streaming Windows Media objects are modified. URIs as used herein generally have the following form (defined in detail in T. Berners-Lee et al, Uniform Resource Identifiers (URI), IETF RFC 2396, August 1998, located at “http://www.ietf.org/rfc/rfc2396.txt”, incorporated by reference herein): scheme://host[port]/uri-path


where “scheme” can be a symbol such as “http” (see Hypertext Transfer Protocol—HTTP/1.1, IETF RFC 2616, located at “http://www.ietf.org/rfc/rfc2616.txt”, incorporated by reference herein) for an object on a Web server or “rtsp” (see Real Time Streaming Protocol (RTSP), IETF RFC 2326, located at “http://www.ietf.org/rfc/rfc2326.txt”, incorporated by reference herein) for an object on a streaming server. Other schemes can also be used and new schemes may be added in the future. The port number “port” is optional, the system substituting a default port number (depending on the scheme) if none is provided. The “host” field maps to a particular network address for a particular computer. The “uri-path” is relative to the computer specified in the “host” field. An uri-path is typically, but not necessarily, the path-name of a file in a media server directory. In a preferred embodiment, the HTTP protocol is used to effect the redirection of WindowsMedia objects. Therefore, the “scheme” field of the URIs of the WindowsMedia objects is changed from “mms” to “http”. For example, the URI for a sample object “sample.asf” in the Windows Media Advanced Streaming Format (ASF) will have a new URI of the form “http://host/path/sample.asf”. For objects using Windows Media ASX scripting, a sample URI for the “meta.asx” object will be in the form “http://host/?www.customer.com/path/meta.asx”, where “customer” is the name of the content provider of “meta.asx”. All URIs contained within the “meta.asx” object remain unchanged. Upon receiving the request “http://host/path/sample.asf”, the WindowsMedia redirector would respond to the request with the following example ASX script: TABLE-US-00001<ASX version=“3.0”><Entry><Ref href=“mms://servername/path/sample.asf”/></Entry></ASX>


in the message body, if the requested object is found available either locally or on another server (parent or origin). In this example, “servername” is or resolves to the Internet Protocol (IP) address of a media server that will serve the requested object to the requesting client. If the requested object cannot be found, the WindowsMedia redirector would respond to the request with the following example ASX script: TABLE-US-00002<ASX version=“3.0”><Entry><Ref href=“http://redirname/path/sample.asf”/></Entry></ASX> in the message body, where “redirname” is or resolves to the IP address of the redirector of a parent server, to trigger another round of redirection. A final round of redirection is reached when none of the parent servers (and the origin server, if applicable) has the requested object. In this case, the redirection process is terminated, and a “not found” error message is sent to the requesting client. Requests for ASX objects are processed in a similar way. Upon receiving the request for the sample object “meta.asx”, the WindowsMedia redirector checks the availability of the object pointed to by each URI inside “meta.asx” and rewrites the URI of each object accordingly. Then the WindowsMedia redirector sends a response to the request with the rewritten “meta.asx” in the message body of the response. The URI rewriting is done as follows. If a requested object, for example, “file.asf”, is found available locally or on another server, the corresponding URI would be rewritten to “mms://servername/path/file.asf”, where “servername” is or resolves to the IP address of the media server that will serve the requested object to the requesting client. If “file.asf” cannot be found, the corresponding URI is rewritten to “http://redirectorname/path/file.asf”, where “redirname” is or resolves to the IP address of a parent server redirector.


Another component is a Real/QuickTime redirector 730, 770 which is an application that processes Real-Time Streaming Protocol (RTSP) requests from a Real or QuickTime player for one or more objects and performs the redirection of the method for Real and QuickTime objects. The Real/QuickTime redirector is provided on edge servers and parent servers. The RTSP, described in detail in the IETF RFC 2326, is used for streaming Real and QuickTime objects, and the “REDIRECT” method supported in that protocol is used to effect redirection. A redirect request informs the client that it must reconnect to another server location and provides for the client the URI of that new server in the redirect request.


A best or optimal server selection mechanism is also provided (not shown in FIG. 7). The best or optimal server selection mechanism includes selection of an edge server most suitable for delivery of one or more objects to the client according to any number of currently known or future developed algorithms. In addition to redirection to a best or optimal edge server for handling a client request for an object, the best or optimal server mechanism may also be applied to trigger one or more further redirections to one or more parent server(s) when a requested object is not available at the handling edge server. In an implementation, to effect this operation, the hostname part of the URI for a requested object is modified. For example, in the link “http://customer-wm.fpondemand.net/customer/sample.asf”, “customer-wm.fpondemand.net” would be changed to “parent-wm.fpondemand.net” forcing the request to go through a further round of best or optimal server selection against parent servers only. In such embodiments, to effect best or optimal parent server selection, the parent-edge server topology is defined and the best or optimal server selection mechanism is provided a parent server table defining the relationships of such a topology. In some embodiments, the best or optimal server selection mechanism is similar to the best repeater selector described in U.S. Pat. No. 6,185,598.


A file replication manager application 740, 750 is also provided that manages object replication to and object removal from storage, retrieves objects from parent servers for replication to edge server storage, and performs storage cleanup as needed. The file replication manager is provided on edge servers and parent servers. In some embodiments, the file replication manager application uses the data transfer method and is in communication with the WindowsMedia and Real/QuickTime redirectors to provide, if available in the storage, objects requested by those redirectors.


In some embodiments, the message communicated between a WindowsMedia or a Real/QuickTime redirector and a file replication manager and between file replication managers is encapsulated using the User Datagram Protocol (UDP). This allows address handling and delivery to be handled by UDP and facilitates fast communication. Since UDP does not guarantee delivery, the message header contains a message number to be used to confirm that a response is to the current query, and not to a previous query. In addition, MD5 (See, e.g., Rivest, R., “The MD5 Message Digest Algorithm”, IETF RFC 1321, April 1992) is supported to provide a basic level of security. The MD5 hash is generated by running a MD5 hash algorithm on the message number, message, and a secret pass phrase only shared by components of the system of managed object replication and delivery. When a message is received, the MD5 hash of the message number, message, and secret pass phrase, is computed and compared against the MD5 hash provided in the message. If these two MD5 hashes do not match, the message is invalid, and will be discarded.


As will be apparent to those skilled in the art, FIG. 7 represents only some embodiments of the system according to the present invention. Many variations for implementing the system according to the teachings of the present invention are possible and are all within the scope of the invention.


Chunking


An extension of the above method and system is to provide chunking. Studies of log data show that, even for popular objects, a good percentage of requests for such objects exit before the object is completely served. To exploit this kind of object usage and further enhance the performance of the network, objects can be segmented into chunks and initial chunks of an object can be given preferential treatment in the replication scheme. For example, only the initial chunks of a object are replicated when a replication admission decision is made and the remaining chunks of the object are pulled to the storage only if the client does not exit before a certain amount or number (e.g., 90%) of the initial chunks of the object are served. The initial chunks of an object can be left in the storage even when the object becomes unpopular. By partitioning streams in this manner, a first part of an object can be served from edge servers quickly, even if most of the object stream must be fetched from a parent server or origin server.


Object Retention and Staleness


Optionally, some or all of the objects may be permanently retained in edge server storage or be retained depending on a quota. Similarly, a configurable or automatically adjusting threshold for storage filling and deletion may be provided.


Also, an edge server may be configured to determine whether a requested object in a server's storage is fresh and serve the requested object only when the object is not stale. In some embodiments, a file is maintained which lists the maximum storage age and storage quota in order to facilitate determining whether a requested object is fresh. If a request is received for a stale object a redirect is initiated to the relevant parent server or origin server to provide the requested object and a storage refresh will be performed if the requested object is popular.


Peers


Also, edge server storage fills of objects may be served by other peer edge servers instead of a relevant parent server or origin server. If a popular object has already been replicated to an edge server filling a new edge server request for that object from one of the peer edge servers may be more efficient than the parent server or origin server. Since there are typically more edge servers than parent servers and origin servers, there is an increased likelihood that a peer edge server may be closer in terms of network distance than a relevant parent server or origin server. Moreover, such peer edge server storage fills could also lessen the burden on the parent servers or origin servers.


The detailed descriptions may have been presented in terms of program procedures executed on a computer or network of computers. These procedural descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. The embodiments of the invention may be implemented as apparent to those skilled in the art in hardware or software, or any combination thereof. The actual software code or hardware used to implement the invention is not limiting of the invention. Thus, the operation and behavior of the embodiments often will be described without specific reference to the actual software code or hardware components. The absence of such specific references is feasible because it is clearly understood that artisans of ordinary skill would be able to design software and hardware to implement the embodiments of the invention based on the description herein with only a reasonable effort and without undue experimentation.


A procedure is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. These operations comprise physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, objects, attributes or the like. It should be noted, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities.


Further, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations of the invention described herein; the operations are machine operations. Useful machines for performing the operations of the invention include general purpose digital computers, special purpose computers or similar devices.


Each operation of the method may be executed on any general computer, such as a mainframe computer, personal computer or the like and pursuant to one or more, or a part of one or more, program modules or objects generated from any programming language, such as C++, Perl, Java™, Fortran, etc. And still further, each operation, or a file, module, object or the like implementing each operation, may be executed by special purpose hardware or a circuit module designed for that purpose. For example, the invention may be implemented as a firmware program loaded into non-volatile storage or a software program loaded from or into a data storage medium as machine-readable code, such code being instructions executable by an array of logic elements such as a processor or other digital signal processing unit. Any data handled in such processing or created as a result of such processing can be stored in any memory as is conventional in the art. By way of example, such data may be stored in a temporary memory, such as in the RAM of a given computer system or subsystem. In addition, or in the alternative, such data may be stored in longer-term storage devices, for example, magnetic disks, rewritable optical disks, and so on.


In the case of diagrams depicted herein, they are provided by way of example. There may be variations to these diagrams or the operations described herein without departing from the spirit of the invention. For instance, in certain cases, the operations may be performed in differing order, or operations may be added, deleted or modified.


Embodiments of the invention may be implemented as an article of manufacture comprising a computer usable medium having computer readable program code means therein for executing the method operations of the invention, a program storage device readable by a machine, tangibly embodying a program of instructions executable by a machine to perform the method operations of the invention, or a computer program product. Such an article of manufacture, program storage device or computer program product may include, but is not limited to, CD-ROM, CD-R, CD-RW, diskettes, tapes, hard drives, computer system memory (e.g., RAM or ROM), and/or the electronic, magnetic, optical, biological or other similar embodiments of the program (including, but not limited to, a carrier wave modulated, or otherwise manipulated, to convey instructions that can be read, demodulated/decoded and executed by a computer). Indeed, the article of manufacture, program storage device or computer program product may include any solid or fluid transmission medium, whether magnetic, biological, optical, or the like, for storing or transmitting signals readable by a machine for controlling the operation of a general or special purpose computer according to any or all methods of the invention and/or to structure its components in accordance with a system of the invention.


Embodiments of the invention may also be implemented in a system. A system may comprise a computer that includes a processor and a memory device and optionally, a storage device, an output device such as a video display and/or an input device such as a keyboard or computer mouse. Moreover, a system may comprise an interconnected network of computers. Computers may equally be in stand-alone form (such as the traditional desktop personal computer) or integrated into another apparatus (such as a cellular telephone).


The system may be specially constructed for the required purposes to perform, for example, the method of the invention or the system may comprise one or more general purpose computers as selectively activated or reconfigured by a computer program in accordance with the teachings herein stored in the computer(s). The system could also be implemented in whole or in part as a hard-wired circuit or as a circuit configuration fabricated into an application-specific integrated circuit. The invention presented herein is not inherently related to a particular computer system or other apparatus. The required structure for a variety of these systems will appear from the description given.


While this invention has been described in relation to certain embodiments, it will be understood by those skilled in the art that other embodiments according to the generic principles disclosed herein, modifications to the disclosed embodiments and changes in the details of construction, arrangement of parts, compositions, processes, structures and materials selection all may be made without departing from the spirit and scope of the invention Changes, including equivalent structures, acts, materials, etc., may be made, within the purview of the appended claims, without departing from the scope and spirit of the invention in its aspects. Thus, it should be understood that the above described embodiments have been provided by way of example rather than as a limitation of the invention and that the specification and drawing(s) are, accordingly, to be regarded in an illustrative rather than a restrictive sense. As such, the invention is not intended to be limited to the embodiments shown above but rather is to be accorded the widest scope consistent with the principles and novel features disclosed in any fashion herein.

Claims
  • 1. In a content delivery network having (CDN) comprising a plurality of servers, a computer-implemented method for handling replication of objects on the plurality of servers, the method comprising, creating a linked list of size (N) for a first object, wherein size (N) represents a total number of time sub-intervals each having an equal duration in time;initializing a dynamic measure of popularity for the first object;initializing the linked list for the first object, thereby commencing count of the first time sub-interval,at the conclusion of the first time sub-interval, incrementing the dynamic measure of popularity by a number of client requests for the first object made during the first time sub-interval;at the conclusion of each subsequent time sub-interval, incrementing the dynamic measure of popularity by a number of client requests for the first object made during each subsequent time sub-interval; andreplicating at least some of the first object on at least a first server when the dynamic measure of popularity of the first object exceeds a dynamic replication threshold based at least in part on a measure of capacity associated with the first server.
  • 2. The method of claim 1, wherein the first object is segmented in to chunks, including initial chunks and remaining chunks, and wherein the step of replicating replicates only initial chunks of the first object.
  • 3. The method of claim 2, wherein the remaining chunks of the first object are selectively replicated based at least in part on how many of the initial chunks are served to a client.
  • 4. The method of claim 1, wherein the measure of capacity associated with the first server comprises a measure of storage available on the first server.
CROSS-REFERENCE AND BACKGROUND

The present application is a continuation application claiming priority under 35 U.S.C. Section 120 to utility U.S. patent application Ser. No. 10/073,938, now U.S. Pat. No. 9,167,036, which is hereby incorporated by reference in its entirety. This invention relates in general to the field of computer networks. Particularly, aspects of this invention pertain to managed object replication and delivery over a network.

US Referenced Citations (443)
Number Name Date Kind
4495570 Kitajima et al. Jan 1985 A
4591983 Bennett et al. May 1986 A
4594704 Ollivier Jun 1986 A
4726017 Krum et al. Feb 1988 A
4803641 Hardy et al. Feb 1989 A
4839798 Eguchi et al. Jun 1989 A
4847784 Clancey Jul 1989 A
4920432 Eggers et al. Apr 1990 A
4922417 Churm et al. May 1990 A
4943932 Lark et al. Jul 1990 A
4949187 Cohen Aug 1990 A
4949248 Caro Aug 1990 A
5029232 Nall Jul 1991 A
5130792 Tindell et al. Jul 1992 A
5132992 Yurt et al. Jul 1992 A
5136716 Harvey et al. Aug 1992 A
5172413 Bradley et al. Dec 1992 A
5191573 Hair Mar 1993 A
5253275 Yurt et al. Oct 1993 A
5253341 Rozmanith et al. Oct 1993 A
5287499 Nemes Feb 1994 A
5287537 Newmark et al. Feb 1994 A
5291554 Morales Mar 1994 A
5341477 Pitkin et al. Aug 1994 A
5371532 Gelman et al. Dec 1994 A
5410343 Coddington et al. Apr 1995 A
5414455 Hooper et al. May 1995 A
5442389 Blahut et al. Aug 1995 A
5442390 Hooper et al. Aug 1995 A
5442749 Northcutt et al. Aug 1995 A
5471622 Eadline Nov 1995 A
5475615 Lin Dec 1995 A
5508732 Bottomley et al. Apr 1996 A
5515511 Nguyen et al. May 1996 A
5519435 Anderson May 1996 A
5528281 Grady et al. Jun 1996 A
5539621 Kikinis Jul 1996 A
5542087 Neimat et al. Jul 1996 A
5544313 Shachnai et al. Aug 1996 A
5544327 Dan et al. Aug 1996 A
5550577 Verbiest et al. Aug 1996 A
5550863 Yurt et al. Aug 1996 A
5550982 Long et al. Aug 1996 A
5557317 Nishio et al. Sep 1996 A
5568181 Greenwood et al. Oct 1996 A
5572643 Judson Nov 1996 A
5590288 Castor et al. Dec 1996 A
5592611 Midgely et al. Jan 1997 A
5594910 Filepp et al. Jan 1997 A
5603026 Demers et al. Feb 1997 A
5614940 Cobbley et al. Mar 1997 A
5619648 Canale et al. Apr 1997 A
5623656 Lyons Apr 1997 A
5625781 Cline et al. Apr 1997 A
5627829 Gleeson et al. May 1997 A
5630067 Kindell et al. May 1997 A
5633999 Clowes et al. May 1997 A
5634006 Baugher et al. May 1997 A
5638443 Stefik et al. Jun 1997 A
5644714 Kikinis Jul 1997 A
5646676 Dewkett et al. Jul 1997 A
5649186 Ferguson Jul 1997 A
5659729 Nielsen Aug 1997 A
5666362 Chen et al. Sep 1997 A
5671279 Elgamal Sep 1997 A
5675734 Hair Oct 1997 A
5682512 Tetrick Oct 1997 A
5699513 Feigen et al. Dec 1997 A
5712979 Graber et al. Jan 1998 A
5715453 Stewart Feb 1998 A
5721914 DeVries Feb 1998 A
5734719 Tsevdos et al. Mar 1998 A
5734831 Sanders Mar 1998 A
5740423 Logan et al. Apr 1998 A
5742762 Scholl et al. Apr 1998 A
5751961 Smyk May 1998 A
5761507 Govett Jun 1998 A
5761663 Lagarde et al. Jun 1998 A
5764906 Edelstein et al. Jun 1998 A
5774660 Brendel et al. Jun 1998 A
5774668 Choquier et al. Jun 1998 A
5777988 Cisneros Jul 1998 A
5777989 McGarvey Jul 1998 A
5778187 Monteiro et al. Jul 1998 A
5781909 Logan et al. Jul 1998 A
5784058 LaStrange et al. Jul 1998 A
5796952 Davis et al. Aug 1998 A
5799141 Galipeau et al. Aug 1998 A
5802106 Packer Sep 1998 A
5802291 Balick et al. Sep 1998 A
5812769 Graber et al. Sep 1998 A
5815662 Ong Sep 1998 A
5815664 Asano Sep 1998 A
5819092 Ferguson et al. Oct 1998 A
5828847 Gehr et al. Oct 1998 A
5832069 Waters et al. Nov 1998 A
5832506 Kuzma Nov 1998 A
5832514 Norin et al. Nov 1998 A
5835718 Blewett Nov 1998 A
5845090 Collins et al. Dec 1998 A
5845303 Templeman Dec 1998 A
5856974 Gervais et al. Jan 1999 A
5862339 Bonnaure et al. Jan 1999 A
5867706 Martin et al. Feb 1999 A
5867799 Lang et al. Feb 1999 A
5870546 Kirsch Feb 1999 A
5870559 Leshem et al. Feb 1999 A
5878212 Civanlar et al. Mar 1999 A
5884038 Kapoor Mar 1999 A
5890171 Blumer et al. Mar 1999 A
5893116 Simmonds et al. Apr 1999 A
5894554 Lowery et al. Apr 1999 A
5896533 Ramos et al. Apr 1999 A
5898456 Wahl Apr 1999 A
5903723 Beck et al. May 1999 A
5907704 Gudmundson et al. May 1999 A
5913028 Wang et al. Jun 1999 A
5913033 Grout Jun 1999 A
5918010 Appleman et al. Jun 1999 A
5919247 Van Hoff et al. Jul 1999 A
5920701 Miller et al. Jul 1999 A
5931904 Banga Aug 1999 A
5933832 Suzuoka et al. Aug 1999 A
5933835 Adams et al. Aug 1999 A
5935207 Logue et al. Aug 1999 A
5940831 Takano Aug 1999 A
5944780 Chase Aug 1999 A
5945989 Freishtat et al. Aug 1999 A
5951694 Choquier et al. Sep 1999 A
5956489 San Andres et al. Sep 1999 A
5956716 Kenner Sep 1999 A
5958008 Pogrebisky et al. Sep 1999 A
5961596 Takubo et al. Oct 1999 A
5966440 Hair Oct 1999 A
5968121 Logan et al. Oct 1999 A
5973696 Agranat et al. Oct 1999 A
5978791 Farber et al. Nov 1999 A
5983214 Lang et al. Nov 1999 A
5983227 Nazem et al. Nov 1999 A
5987606 Cirasole et al. Nov 1999 A
5991809 Kriegsman et al. Nov 1999 A
5996025 Day Nov 1999 A
6002720 Yurt et al. Dec 1999 A
6003030 Kenner et al. Dec 1999 A
6012090 Chung et al. Jan 2000 A
6014686 Elnozahy et al. Jan 2000 A
6014698 Griffiths Jan 2000 A
6016509 Dedrick Jan 2000 A
6016512 Huitema Jan 2000 A
6018516 Packer Jan 2000 A
6021426 Douglis Feb 2000 A
6023470 Lee et al. Feb 2000 A
6026440 Shrader et al. Feb 2000 A
6029175 Chow et al. Feb 2000 A
6029176 Cannon Feb 2000 A
6035332 Ingrassia et al. Mar 2000 A
6038216 Packer Mar 2000 A
6038310 Hollywood et al. Mar 2000 A
6038610 Belfiore et al. Mar 2000 A
6041324 Earl et al. Mar 2000 A
6044405 Driscoll et al. Mar 2000 A
6046980 Packer Apr 2000 A
6049831 Gardell et al. Apr 2000 A
6052718 Gifford Apr 2000 A
6052730 Felciano et al. Apr 2000 A
6065051 Steele et al. May 2000 A
6065062 Periasamy et al. May 2000 A
6070191 Narendran et al. May 2000 A
6078943 Yu Jun 2000 A
6081829 Sidana Jun 2000 A
6081835 Antcliff Jun 2000 A
6081840 Zhao Jun 2000 A
6085193 Malkin et al. Jul 2000 A
6092112 Fukushige Jul 2000 A
6092204 Baker et al. Jul 2000 A
6094706 Factor et al. Jul 2000 A
6098078 Gehani Aug 2000 A
6098096 Tsirigotis et al. Aug 2000 A
6105028 Sullivan et al. Aug 2000 A
6108673 Brandt et al. Aug 2000 A
6108703 Leighton et al. Aug 2000 A
6112231 DeSimone et al. Aug 2000 A
6112239 Kenner et al. Aug 2000 A
6112240 Pogue et al. Aug 2000 A
6115357 Packer et al. Sep 2000 A
6115752 Chauhan Sep 2000 A
6119143 Dias et al. Sep 2000 A
6125388 Reisman Sep 2000 A
6125394 Rabinovich Sep 2000 A
6128601 Van Horne et al. Oct 2000 A
6128623 Mattis Oct 2000 A
6128660 Grimm et al. Oct 2000 A
6130890 Leinwand et al. Oct 2000 A
6131095 Low et al. Oct 2000 A
6134583 Herriot Oct 2000 A
6144375 Jain et al. Nov 2000 A
6144702 Yurt et al. Nov 2000 A
6151624 Teare et al. Nov 2000 A
6154744 Kenner et al. Nov 2000 A
6154753 McFarland Nov 2000 A
6161137 Johnson et al. Dec 2000 A
6163779 Mantha et al. Dec 2000 A
6167427 Rabinovich et al. Dec 2000 A
6173311 Hassett et al. Jan 2001 B1
6173322 Hu Jan 2001 B1
6178160 Bolton et al. Jan 2001 B1
6181867 Kenner et al. Jan 2001 B1
6185598 Farber et al. Feb 2001 B1
6185619 Joffe et al. Feb 2001 B1
6189030 Kirsch et al. Feb 2001 B1
6189039 Harvey Feb 2001 B1
6195680 Goldszmidt et al. Feb 2001 B1
6205120 Packer et al. Mar 2001 B1
6212565 Gupta Apr 2001 B1
6226618 Downs May 2001 B1
6226642 Beranek et al. May 2001 B1
6230196 Guenthner et al. May 2001 B1
6233623 Jeffords et al. May 2001 B1
6240462 Agraharam et al. May 2001 B1
6243760 Armbruster et al. Jun 2001 B1
6249810 Kiraly Jun 2001 B1
6256675 Rabinovich Jul 2001 B1
6263313 Milsted Jul 2001 B1
6266335 Bhaskaran Jul 2001 B1
6266699 Sevcik Jul 2001 B1
6269394 Kenner et al. Jul 2001 B1
6272566 Craft Aug 2001 B1
6275470 Ricciulli Aug 2001 B1
6282569 Wallis et al. Aug 2001 B1
6286045 Griffith et al. Sep 2001 B1
6298041 Packer Oct 2001 B1
6314565 Kenner et al. Nov 2001 B1
6317787 Boyd et al. Nov 2001 B1
6324580 Jindal et al. Nov 2001 B1
6324582 Sridhar et al. Nov 2001 B1
6330602 Law et al. Dec 2001 B1
6332157 Mighdoll et al. Dec 2001 B1
6338044 Cook et al. Jan 2002 B1
6343298 Savchenko et al. Jan 2002 B1
6345294 O'Toole et al. Feb 2002 B1
6347085 Kelly et al. Feb 2002 B2
6351775 Yu Feb 2002 B1
6351776 O'Brien et al. Feb 2002 B1
6360256 Lim Mar 2002 B1
6370571 Medin Apr 2002 B1
6370580 Kriegsman Apr 2002 B2
6389462 Cohen et al. May 2002 B1
6398245 Gruse Jun 2002 B1
6405252 Gupta et al. Jun 2002 B1
6405257 Gersht et al. Jun 2002 B1
6412000 Riddle et al. Jun 2002 B1
6415280 Farber et al. Jul 2002 B1
6415368 Glance et al. Jul 2002 B1
6418421 Hurtado Jul 2002 B1
6421714 Rai et al. Jul 2002 B1
6421726 Kenner et al. Jul 2002 B1
6427170 Sitaraman et al. Jul 2002 B1
6430618 Karger et al. Aug 2002 B1
6442588 Clark et al. Aug 2002 B1
6453319 Mattis Sep 2002 B1
6456630 Packer et al. Sep 2002 B1
6460082 Lumelsky Oct 2002 B1
6460085 Toporek et al. Oct 2002 B1
6463454 Lumelsky et al. Oct 2002 B1
6463508 Wolf Oct 2002 B1
6466949 Yang et al. Oct 2002 B2
6470389 Chung et al. Oct 2002 B1
6473405 Ricciulli Oct 2002 B2
6477180 Aggarwal Nov 2002 B1
6480893 Kriegsman Nov 2002 B2
6484143 Swildens et al. Nov 2002 B1
6484204 Rabinovich Nov 2002 B1
6487555 Bharat et al. Nov 2002 B1
6490580 Dey et al. Dec 2002 B1
6493707 Dey et al. Dec 2002 B1
6496856 Kenner et al. Dec 2002 B1
6502125 Kenner et al. Dec 2002 B1
6502205 Yanai et al. Dec 2002 B1
6502215 Raad et al. Dec 2002 B2
6505248 Casper et al. Jan 2003 B1
6529477 Toporek et al. Mar 2003 B1
6553413 Leighton et al. Apr 2003 B1
6553420 Karger et al. Apr 2003 B1
6557054 Reisman Apr 2003 B2
6564251 Katariya et al. May 2003 B2
6577595 Counterman Jun 2003 B1
6581090 Lindbo et al. Jun 2003 B1
6584083 Toporek et al. Jun 2003 B1
6587837 Spagna Jul 2003 B1
6591288 Edwards et al. Jul 2003 B1
6591299 Riddle et al. Jul 2003 B2
6594260 Aviani, Jr. et al. Jul 2003 B1
6598121 Challenger et al. Jul 2003 B2
6611862 Reisman Aug 2003 B2
6625643 Colby et al. Sep 2003 B1
6651141 Adrangi Nov 2003 B2
6654344 Toporek et al. Nov 2003 B1
6654807 Farber et al. Nov 2003 B2
6658464 Reisman Dec 2003 B2
6665706 Kenner et al. Dec 2003 B2
6665726 Leighton et al. Dec 2003 B1
6678659 Van Kommer Jan 2004 B1
6691148 Zinky et al. Feb 2004 B1
6694358 Swildens et al. Feb 2004 B1
6699418 Okada et al. Mar 2004 B2
6708137 Carley Mar 2004 B2
6718328 Norris Apr 2004 B1
6732237 Jacobs et al. May 2004 B1
6741563 Packer May 2004 B2
6741990 Nair et al. May 2004 B2
6751673 Shaw Jun 2004 B2
6754699 Swildens et al. Jun 2004 B2
6754706 Swildens et al. Jun 2004 B1
6763377 Belknap Jul 2004 B1
6763388 Tsimelzon Jul 2004 B1
6778502 Ricciulli Aug 2004 B2
6785704 McCanne Aug 2004 B1
6799221 Kenner et al. Sep 2004 B1
6801576 Haldeman et al. Oct 2004 B1
6834306 Tsimelzon Dec 2004 B1
6839758 Sorensen Jan 2005 B2
6842604 Cook et al. Jan 2005 B1
6859791 Spagna Feb 2005 B1
6859840 Singal et al. Feb 2005 B2
6870851 Leinwand et al. Mar 2005 B1
6874032 Gersht et al. Mar 2005 B2
6901604 Kiraly May 2005 B1
6915307 Mattis Jul 2005 B1
6915329 Kriegsman Jul 2005 B2
6928442 Farber et al. Aug 2005 B2
6934255 Toporek et al. Aug 2005 B1
6950623 Brown et al. Sep 2005 B2
6963910 Belknap et al. Nov 2005 B1
6963980 Mattsson Nov 2005 B1
6963981 Bailey et al. Nov 2005 B1
6965890 Dey et al. Nov 2005 B1
6970432 Hankins et al. Nov 2005 B1
6973490 Robertson et al. Dec 2005 B1
6976090 Ben-Shaul et al. Dec 2005 B2
6981050 Tobias et al. Dec 2005 B1
6981180 Bailey et al. Dec 2005 B1
6996616 Leighton et al. Feb 2006 B1
6999988 Buddhikot et al. Feb 2006 B2
7003572 Lownsbrough et al. Feb 2006 B1
7007089 Freedman Feb 2006 B2
7010578 Lewin et al. Mar 2006 B1
7012900 Riddle Mar 2006 B1
7013342 Riddle Mar 2006 B2
7024466 Outten et al. Apr 2006 B2
7032072 Quinn et al. Apr 2006 B1
7039633 Dey et al. May 2006 B1
7047300 Oehrke et al. May 2006 B1
7054902 Toporek et al. May 2006 B2
7054935 Farber et al. May 2006 B2
7058706 Iyer et al. Jun 2006 B1
7069177 Carley Jun 2006 B2
7096266 Lewin et al. Aug 2006 B2
7103564 Ehnebuske Sep 2006 B1
7103645 Leighton et al. Sep 2006 B2
7110984 Spagna Sep 2006 B1
7117259 Rohwer Oct 2006 B1
7188085 Pelletier Mar 2007 B2
7206748 Gruse Apr 2007 B1
7254645 Nishi Aug 2007 B2
7562153 Biliris et al. Jul 2009 B2
20010027491 Terretta Oct 2001 A1
20010029525 Lahr Oct 2001 A1
20010049732 Raciborski et al. Dec 2001 A1
20010051980 Raciborski et al. Dec 2001 A1
20010056500 Farber et al. Dec 2001 A1
20020010798 Ben-Shaul et al. Jan 2002 A1
20020016831 Peled et al. Feb 2002 A1
20020016835 Gamerman Feb 2002 A1
20020018449 Ricciulli Feb 2002 A1
20020023164 Lahr Feb 2002 A1
20020023165 Lahr Feb 2002 A1
20020040404 Lahr Apr 2002 A1
20020042817 Lahr Apr 2002 A1
20020046273 Lahr et al. Apr 2002 A1
20020046405 Lahr Apr 2002 A1
20020049857 Farber et al. Apr 2002 A1
20020059592 Kiraly May 2002 A1
20020066038 Mattsson May 2002 A1
20020073167 Powell Jun 2002 A1
20020073199 Levine et al. Jun 2002 A1
20020078233 Biliris et al. Jun 2002 A1
20020082999 Lee et al. Jun 2002 A1
20020083124 Knox et al. Jun 2002 A1
20020087797 Adrangi Jul 2002 A1
20020089470 Raman et al. Jul 2002 A1
20020092026 Janniello et al. Jul 2002 A1
20020099850 Farber et al. Jul 2002 A1
20020116444 Chaudhri et al. Aug 2002 A1
20020124080 Leighton Sep 2002 A1
20020129134 Leighton et al. Sep 2002 A1
20020131645 Hamilton Sep 2002 A1
20020133537 Lau Sep 2002 A1
20020143798 Lisiecki et al. Oct 2002 A1
20020143888 Lisiecki et al. Oct 2002 A1
20020147774 Lisiecki et al. Oct 2002 A1
20020152318 Menon et al. Oct 2002 A1
20020163882 Bornstein et al. Nov 2002 A1
20020198953 O'Rourke et al. Dec 2002 A1
20020199016 Freedman Dec 2002 A1
20030009444 Eidler et al. Jan 2003 A1
20030018966 Cook et al. Jan 2003 A1
20030028623 Hennessey et al. Feb 2003 A1
20030028626 Hennessey et al. Feb 2003 A1
20030028777 Hennessey et al. Feb 2003 A1
20030031176 Sim Feb 2003 A1
20030055972 Fuller et al. Mar 2003 A1
20030061263 Riddle Mar 2003 A1
20030061280 Bulson et al. Mar 2003 A1
20030065703 Aborn Apr 2003 A1
20030065762 Stolorz et al. Apr 2003 A1
20030078888 Lee et al. Apr 2003 A1
20030078889 Lee et al. Apr 2003 A1
20030079027 Slocombe et al. Apr 2003 A1
20030095660 Lee et al. May 2003 A1
20030105604 Ash et al. Jun 2003 A1
20030112792 Cranor et al. Jun 2003 A1
20030149581 Chaudhri et al. Aug 2003 A1
20030154239 Davis et al. Aug 2003 A1
20030158923 Burkhart Aug 2003 A1
20030158928 Knox et al. Aug 2003 A1
20040022194 Ricciulli Feb 2004 A1
20040139097 Farber et al. Jul 2004 A1
20040177148 Tsimelzon, Jr. Sep 2004 A1
20050021863 Jungck Jan 2005 A1
20050033858 Swildens et al. Feb 2005 A1
20050038851 Kriegsman Feb 2005 A1
20050100027 Leinwand et al. May 2005 A1
20050114296 Farber et al. May 2005 A1
20050262104 Robertson et al. Nov 2005 A1
20060015574 Seed et al. Jan 2006 A1
20060143293 Freedman Jun 2006 A1
20070055764 Dilley et al. Mar 2007 A1
20070174463 Seed et al. Jul 2007 A1
20080065724 Seed et al. Mar 2008 A1
20080071859 Seed et al. Mar 2008 A1
20090254661 Fullagar et al. Oct 2009 A1
20100312861 Kolhi et al. Dec 2010 A1
20100332595 Fullagar et al. Dec 2010 A1
Foreign Referenced Citations (47)
Number Date Country
763380 Jun 2003 AU
2202572 Oct 1998 CA
2288488 Jun 2000 CA
2335661 Mar 2001 CA
2335662 Mar 2001 CA
2467998 Apr 2006 CA
ZL99810853.7 Aug 1999 CN
1264476 Aug 2000 CN
0649121 Apr 1995 EP
0651554 May 1995 EP
0801487 Oct 1997 EP
0817444 Jan 1998 EP
0824236 Feb 1998 EP
0865180 Sep 1998 EP
1063831 Dec 2000 EP
1104555 Jun 2001 EP
2281793 Mar 1995 GB
2353877 Apr 2004 GB
140935 Mar 2006 IL
05162529 Jun 1993 JP
07066829 Mar 1995 JP
08328583 Dec 1996 JP
10027148 Jan 1998 JP
10093552 Apr 1998 JP
2000207270 Jul 2000 JP
2001007844 Jan 2001 JP
2001290787 Oct 2001 JP
2001312434 Nov 2001 JP
2002522995 Jul 2002 JP
3566626 Jun 2004 JP
2005124165 May 2005 JP
3762649 Jan 2006 JP
20010023599 Mar 2001 KR
NI176482 Aug 2003 TW
WO-1996042041 Dec 1996 WO
WO-1997011429 Mar 1997 WO
WO-1997029423 Aug 1997 WO
WO-199742582 Nov 1997 WO
WO-1998004985 Feb 1998 WO
WO-1998006033 Feb 1998 WO
WO-199859486 Dec 1998 WO
WO-199917227 Apr 1999 WO
WO-199948246 Sep 1999 WO
WO-199953422 Oct 1999 WO
WO-2000029990 May 2000 WO
WO-2000060861 Oct 2000 WO
WO-200193533 Dec 2001 WO
Non-Patent Literature Citations (104)
Entry
Wu, Kun-Lung, Philip S. Yu, and Joel L. Wolf. “Segment-based proxy caching of multimedia streams.” Proceedings of the 10th international conference on World Wide Web. ACM, 2001.
European Exam Report, dated Apr. 29, 2011, EP App. No. 03739748.6, 5 pgs.
European Examination Report, dated Nov. 28, 201, Application No. 03739748.6, 6 pgs.
“Exporting Web Server Final Report”, http://www.cs.technion.ac.il/Labs/Lccn/projects/spring97/project4/final_report.html (downloaded Jul. 7, 2007). Spring 1997.
“IBM Technical Disclosure Bulletin; Local Area Network Server Replacement Procedure”, vol. 38, No. 1 (Jan. 1995) , 235-236.
JP 10(1998)—27148 machine translation prepared by Japanese Patent Office (JPO), published Jan. 27, 1998, Title: “Server System for Internet,” Applicant: Hitachi , 23 pgs.
Non-Final Office Action, dated Jun. 11, 2013, U.S. Appl. No. 12/880,324, filed Sep. 13, 2010; 17 pgs.
Patent Abstracts of Japan “Server System for Internet”, Pub. No. 10-027148, pub. date Jan. 27, 1998, Applicant: Hitachi, computer translation , 12 pgs.
Patent Abstracts of Japan, “Electronic Mail Multiplexing System and Communication Control Method in the System”, (Appln. No. JP19930162529), (Jun. 30, 1993) (Pub. No. JP 7066829).
Patent Abstracts of Japan, “Method and Device for Repeating and Converting Information”, (Appln. No. JP19960328583) (Pub. No. JP10171727) Jun. 26, 1998.
Summons to Attend Oral Proceedings, dated Jun. 28, 2013, EP Application No. 03739748.6, 6 pgs.
Adler, R. M., “Distributed Coordination Models for Client/Server Computing”, Computer 28, Apr. 4, 1995 , 14-22.
Aggarwal, A. et al., “Performance of Dynamic Replication Schemes for an Internet Hosting Service”, Technical Report, AT&T Labs Oct. 1998.
Almeroth, K. et al., “Scalable Delivery of Web Pages Using Cyclic Best-Effort (UDP) Multicast”, IEEE Infocom San Francisco, California, USA Jun. 1998 , pp. 1-24.
Andresen, D. et al., “Multiprocessor scheduling with client resources to improve the response time of WWW applications”, ACM Press, NY, Proc. 11th Inti Conf. on Supercomputing (Austria, ICS '97) Jul. 1997 , 92-99.
Andresen, et al., “SWEB: Towards a Scalable World Wide Web Server on Multicomputers”, Proc. IPPS Apr. 15, 1996 , 850-856.
Awerbuch, et al., “Competitive Distributed File Allocation”, in Proc. of the 25th Ann. ACM Symp. on Theory of Computing May 1993 , pp. 164-173.
Awerbuch, B. et al., “Distributed Paging for General Networks”, In Proc. of the 7th ACM-SIAM Symposium on Discrete Algorithms, Jan. 1996 , pp. 574-583.
Baentsch, M et al., “Enhancing the Web's Infrastructure: From Caching to Replication”, IEEE Internet Computing, Mar. 1997 , 1(2):18-27.
Baentsch, M. et al., “Introducing Application-Level Replication and Naming into Today's Web”, Computer Networks and ISDN Systems vol. 28, Nos. 7-11 May 1996 , pp. 921-930.
Bartal, Y. et al., “Competitive Algorithms for Distributed Data Management”, 24th Annual ACM STOC, May 1992, Victoria, B.C. Canada.
Basturk, E. et al., “Using network layer anycast for load distribution in the Internet”, Tech. Rep., IBM TJ. Watson Research Center Jul. 1997 , 21 pgs.
Berners-Lee, T. et al., RFC 1738—Uniform Resource Locators Dec. 1994 , pp. 1-25.
Berners-Lee, T. et al., “Hypertext Markup Language—2.0”, Internet Engineering Task Force (IETF) Request for Comments (RFC) 1866 Nov. 1995 , pp. 1-77.
Berners-Lee, T. et al., “Hypertext Transfer Protocol—HTTP/1.0”, Internet Engineering Task Force (IETF) Request for Comments (RFC) 1945 May 1996 , pp. 1-60.
Berners-Lee, T. et al., “Hypertext Transfer Protocol—HTTP/1.0”, Internet Engineering Task Force (IETF), Internet Draft, draft-ietf-http-v10-spec-00.ps Mar. 1995 , pp. 1-59.
Berra, P. B. et al., “Architecture for Distributed Database Systems”, Computer Communications vol. 13, No. 4 May 1, 1990 , pp. 217-231.
Bestavros, A., “Demand-Based Document Dissemination to Reduce Traffic and Balance Load in Distributed Information Systems”, In Proc. IEEE Symp. on Parallel and Distributed Processing, San Antonio, TX Oct. 1995 , 8 pgs.
Bestavros, et al., “Server-Initiated Document Dissemination for the WWW”, IEEE Data Engineering Bulletin Sep. 1996 , 19(3): 3-11.
Bestavros, A., “Speculative Data Dissermination and Service to Reduce Server Load Network Traffic and Service Time in Distributed Information Systems”, In Proc. ICDE '96: The 1996 Int'l Conf. on Data Engineering (Mar. 1996) , 4 Pages.
Bhattacharjee, S. et al., “Application-Layer Anycasting”, in Proc. IEEE INFOCOM '97 Apr. 1997 , 9 pgs.
Braun, H. et al., “Web traffic characterization: an assessment of the impact of caching documents from NCSA's web server”, Comput. Netw. ISDN Syst. 28, Dec. 1-2, 1995 , 37-51.
Brisco, T., “DNS Support for Load Balancing”, IETF RFC 1794 Apr. 1995 , pp. 1-7.
Carter, et al., “Dynamic server selection using bandwidth probing in wide-area networks”, Tech. Rep. BU-CS-96-007, Compo Sci. Dept., Boston University Mar. 1996 , 1-20.
Carter, et al., “Server selection using dynamic path characterization in Wide-Area Networks”, IEEE INFOCOM '97 1997 , pp. 1014-1021.
Carter, J. L. et al., “Universal Classes of Hash Functions”, Journal of Computer and System Sciences vol. 18, No. 2 Apr. 1979, 106-112.
Cate, V., “Alex: a global file system”, in Proc. Usenix Conf. on File Systems May 1992 , pp. 1-11.
Chankhunthod, A. et al., “A Hierarchical Internet Object Cache”, Proc. of the 1996 USENIX Technical Conf. Jan. 1996 , 153-163.
Cohen, J. et al., “Cache Array Routing Protocol v1.1”, http://tools.ietf.org/id/draft-vinod-carp-v1-01.txt (Last-Modified: Wed, Oct 1, 1997) Sep. 29, 1997 , 8 pages.
Colajanni, et al., “Adaptive TTL schemes for load balancing of distributed Web servers”, SIGMETRICS Perform. Eval. Rev. 25,Sep. 2, 1997 , 36-42.
Colajanni, M. et al., “Scheduling Algorithms for Distributed Web Servers”, Intl Conf. on Distributed Computing Systems (ICDCS), Baltimore, Maryland, USA May 1997 , pp. 169-176.
Crovella, et al., “Dynamic server selection in the Internet”, 3rd IEEE Workshop on the Arch. and Implementation of High Performance Computer Sys. '95 Aug. 1995 , pp. 158-162.
Danzig, P. B. et al., “An analysis of wide-area name server traffic: a study of the Internet Domain Name System”, Conf. Proc. Communications Architectures & Protocols; D. Oran, Ed. SIGCOMM '92; ACM Press, New York, NY Aug. 1992 , 281-292.
De Bra, P.M.E. et al., “Information Retrieval in the World Wide Web: Making Client-Based Searching Feasible”, Computer Networks and ISDN System, NL, North Holland Publishing, Amsterdam, vol. 27, No. 2, ISSN: 0169-7552 Nov. 1, 1994 , 183-192.
Deering, S. E. et al., “Multicast routing in datagram internetworks and extended LANs”, ACM Trans.Comput. Syst. 8,May 2, 1990 , 85-110.
Doi, K., “Super Proxy Script—How to make distributed proxy servers by URL hashing”, Sharp Corp., http://naragw.sharp.co.jp/sps/; download Jul. 7, 2007. dates unknown (1996-2000).
Eriksson, H., “MBONE: The Multicast Backbone”, Communications of the ACM vol. 37, No. 8 Aug. 1994 , pp. 54-60.
Feeley, M. et al., “Implementing Global Memory Management in a Workstation Cluster”, In Proc. 15th ACM Symp. on Operating Systems Principles Dec. 1995 , 201-212.
Fielding, R. et al., “Hypertext Transfer Protocol—HTTP/1.1”, Internet Engineering Task Force (IETF) Internet Draft, draft-ietf-http-v11-spec-00.txt Nov. 1995 , pp. 1-81.
Fielding, R. et al., “Hypertext Transfer Protocol—HTTP/1.1”, Internet Engineering Task Force (IETF) Request for Comments (RFC) 2068 Jan. 1997 , pp. 1-162.
Floyd, S. et al., “A Reliable Multicast Framework for Light-Weight Sessions and Application Level Framing”, In Proc. of ACM SIGCOMM '95, Aug. 1995 , 342-356.
Fox, A. et al., “A Framework for Separating Server Scalability and Availability from Internet Application Functionality”, PhD thesis, University of California, Berkeley, 1998 , 163 pgs.
Fox, A. et al., “Cluster-based scalable network services”, Proc. 16th ACM Symp. on Operating Systems Principles (Saint Malo, France, Oct. 5-8, 1997), W. M. Waite, Ed. SOSP '97. ACM Press, New York, NY , 78-91.
Gadde, S. et al., “Reduce, reuse, recycle: An approach to building large internet caches”, in Workshop on Hot Topics in Operating Systems (HotOS) Apr. 1997 , pp. 93-98.
Goldszmidt, M. et al., “Load Distribution for Scalable Web Servers: Summer Olympics 1996—A Case Study”, In Proc. 8th IFIPIIEEE Int'l Workshop on Distributed Systems: Operations and Management , Sydney, Australia. Oct. 1997 , 10 pgs.
Grigni, M. et al., “Tight Bounds on Minimum Broadcasts Networks”, SIAM J. Disc. Math. 4 (May 1991) , 207-222.
Guyton, et al., “Locating nearby copies of replicated Internet servers”, Proc. ACM SIGCOMM '95; pp. 288-298 Oct. 1995.
Gwertzman, J. et al., “The Case for Geographical Push-Caching”, Proc. Workshop on Hot OS '95 (May 4, 1995) , 51-55.
Gwertzman, J. et al., “World-Wide Web Cache Consistency”, Proc. 1996 USENIX Tech. Conf., pp. 141-151, San Diego, CA Jan. 1996.
Jeffery, C. et al., “Proxy sharing proxy servers”, In Proc. IEEE etaCOM Conf. May 1996 , pp. 116-119.
Karger, D. et al., “Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web”, In Proc. 29th Annual ACM Symp. on Theory of Computing May 1997 , 654-663.
Kim, Y. J. et al., “Clustered multi-media NOD: Popularity-based article prefetching and placement”, Sixteenth IEEE Symp. on Mass Storage Systems, San Diego, CA (Mar. 15-18, 1999 , pp. 194-202.
Korkea-Aho, M. , “Scalability in Distributed Multimedia Systems”, Technical report TKO-B128, Helsinki University of Technology.
Krishnamurthy, B. et al., “Study of piggyback cache validation for proxy caches in the World Wide Web”, in: Symp. on Internet Technology and Systems, USENIX Association Dec. 1997.
Kroeger, T. M. et al., “Exploring the Bounds of Web Latency Reduction from Caching and Prefetching”, Proc. Usenix Symp. Internet Technologies and Systems, Usenix Dec. 1997 , pp. 13-22.
Kwan, et al., “NCSA's World Wide Web Server: Design and Performance”, IEEE Nov. 1995 , pp. 68-74.
Little, T.D. C. et al., “Selection and Dissemination of Digital Video via the Virtual Video Browser”, Multimedia Tools and Applications vol. 1, No. 2 (Netherlands) Jun. 1995, 99. 149-172.
Luotonen, et al., “World-Wide Web Proxies”, CERN modified May 24, 1994 Apr. 1994 , 1-8.
Malkin, G., “RIP Version 2 Carrying Additional Information”, Internet Engineering Task Force (IETF) Request for Comments (RFC) 1388 Jan. 1993 , pp. 1-7.
Malpani, R. et al., “Making World Wide Web Caching Servers Cooperate”, In Proc. 4th Int'l World Wide Web Conf. (downloaded from http://www.w3.org/ConferencesIWWW4/Papers/59/ on Jul. 7, 2007) Dec. 1995 , 10 pages.
Mockapetris, P., “Domain Names—Concepts and Facilities”, IETF RFC 1034 Nov. 1987 , 55 pgs.
Mockapetris, P. , “Domain Names—Implementation and Specification”, IETF RFC 1035 Nov. 1987 , 55 pgs.
Mourad, et al., “Scalable Web Server Architectures”, iscc, 2nd IEEE Symposium on Computers and Communications (ISCC '97) Jul. 1997 , pp. 12-16.
Moy, J., “OSPF Version 2”, Internet Engineering Task Force (IETF) Request for Comments (RFC) 1583 Mar. 1994 , 132 pgs.
Niki, Hitoshi , “Storage Network”, Computopia vol. 36, No. 415, Japan, Computer Age Co., Ltd. (translation) Apr. 1, 2001 , p. 52.
Oguchi, et al., “A Study of Caching Proxy Mechanisms Realized on Wide Area Distributed Networks”, High Performance Distributed Computing, 5th Int'l Symposium Aug. 1996 , pp. 443-449.
Palmer, M. et al., “Fido: A Cache that Learns to Fetch”, In Proc. the 17th Int'l Conf. on Very Large Data Bases Sep. 1991 , 255-264.
Panigrahy, R., “Relieving Hot Spots on the World Wide Web”, Master's thesis, MIT EECS Jun. 1997 , pp. 1-66.
Parris, C. et al., “A Dynamic Connection Management Scheme for Guaranteed Performance Services in Packet-Switching Integrated Services Networks”, UC Berkeley Computer Science Division Tech. Report TR-93-005 1993 , 37 pgs.
Parris, C. et al., “The Dynamic Management of Guaranteed Performance Connections in Packet Switched Integrated Service Networks”, UC Berkeley Computer Science Division and International Computer Science Institute Tech. Report CSD-94-859 1994.
Partridge, C. et al., “Host Anycasting Service”, Internet Engineering Task Force (IETF) Request for Comments (RFC) 1546 Nov. 1993 , pp. 1-9.
Petri, S. et al., “Load Balancing and Fault Tolerance in Workstation Clusters. Migrating Groups of Communicating Processes”, Operating Systems Review, vol. 29, No. 4 Oct. 1995 , 25-36.
Plaxton, G. C. et al., “Fast Fault-Tolerant Concurrent Access to Shared Objects”, In Proc. 37th IEEE Symp. of Foundations of Computer Science Oct. 1996 , pp. 570-579.
Povey, D. et al., “A distributed internet cache”, in Proc. of the 20th Australasian Computer Science Conf. Feb. 1997.
Rabin, M. O. , “Efficient dispersal of information for security, load balancing, and fault tolerance”, J.ACM 36, 2 (Apr. 1989) , pp. 335-348.
Rabinovich, M. et al., “Dynamic Replication on the Internet Work Project No. 3116-17-7006”, AT&T Labs Research Mar. 5, 1998.
Rabinovich, M. et al., “RaDaR: A Scalable Architecture for a Global Web Hosting Service”, WWW8 May 1999.
Reisslein, M. et al., “Interactive video streaming with proxy servers”, in Proc. of First International Workshop on Intelligent Multimedia Computing and Networking (IMMCN) 2000 , pp. 1-16.
Rodriguez, P. et al., “Improving the WWW: Caching or Multicast?”, Computer Networks and ISDN Systems North Holland Publishing, Amsterdam, NL, vol. 30, No. 22-23, ISSN: 0169-7552 Nov. 1998 , pp. 2223-2243.
Ross, K. W., “Hash-Routing for Collections of Shared Web Caches”, IEEE Network Magazine 11, 7:37-44 Nov.-Dec. 1997 , pp. 1-21.
Sen, S. et al., “Proxy Prefix Caching for Multimedia Streams”, IEEE Jun. 1999, 10 pgs.
Smith, Neil, “What can Archives offer the World Wide Web?”, Technical Report 11, University of Kent, Computing Laboratory, University of Kent, Canterbury, UK Mar. 1994 , 1-12.
Takahashi, Takao , “How to customize Apache Q&A—Web server using Apache”, AI Publishing, Apr. 30, 1999, First Edition , pp. 63-64 (translation).
Thaler, D. G. et al., “Using name-based mappings to increase hit rates”, IEEE/ACM Trans. Netw. 6, Feb. 1, 1998 , 1-14.
Topolcic, C., “Experimental Internet Stream Protocol, Version 2 (ST-II)”, Internet Engineering Task Force (IETF) Request for Comments (RFC) 1190 Oct. 1990 , pp. 1-148.
Touch, J. et al., “The X-Bone”, Third Global Internet Mini-Conference at Globecom '98, Sydney, Australia (pp. 44-52 of mini-conference) Nov. 1998 , pp. 59-68.
Traina, P., “BGP-4 Protocol Analysis”, Internet Engineering Task Force (IETF) Request for Comments (RFC) 1774 Mar. 1995 , pp. 1-10.
Vin, H., “Multimedia Broadcasting Over the Internet: Part 1”, IEEE Multimedia IEEE Computer Society, US, vol. 5, NR. Oct. 4, 1998 , pp. 78-82.
Vitter, J. S. et al., “Optimal Prefetching via Data Compression”, Proc. 32nd Annual IEEE Symposium on Foundations of Computer Science Oct. 1991 , 21 pages.
Wessels, D., “Configuring Hierarchical Squid Caches”, Aug. 19, 1997 , 62 pgs.
Wessels, Duane, “Intelligent Caching for World-Wide Web Objects”, Masters Thesis, University of Colorado (also presented at INET '95 in Jun. '95) Jan. 1995 , 1-85.
Wessels, D. et al., “Internet Cache Protocol (ICP), Version 2”, Internet Engineering Task Force (IETF) Request for Comments (RFC) 2186 Sep. 1997 , pp. 1-9.
Wolfson, O. et al., “An Adaptive Data Replication Algorith”, ACM Transactions on Database Systems (TODS) vol. 22(4) Jun. 1997 , pp. 255-314.
Xiao, Li et al., “Exploiting neglected data locality in browsers”, in Proc. 10th Int'l World Wide Web Conference, (WWW10), Hong Kong (extended abstract) May 1-5, 2001 , 2 pgs.
Related Publications (1)
Number Date Country
20160044105 A1 Feb 2016 US
Continuations (1)
Number Date Country
Parent 10073938 Feb 2002 US
Child 14887053 US