Server handoff in content delivery network
A content delivery method directs a request by a client for an object to a first server in a content delivery network (CDN), regardless of whether the first server has the requested object. If the first server has the requested object, then it is served to the client from the first server; otherwise, the first server redirects the client request to a second server in the CDN to handle the request. The second server may be a peer server of the first server. The first and second servers may be edge servers in the CDN.
Latest Level 3 Communications, LLC Patents:
- Control device discovery in networks having separate control and forwarding devices
- Dynamic binding and load determination in a content delivery network (CDN)
- Apparatus, system, and method for asymmetrical and dynamic routing
- Service activation system
- Device deployment and network management using a self-service portal
This application is a continuation of U.S. patent application Ser. No. 11/715,316, titled “Managed Object Replication And Delivery” filed Mar. 8, 2007, now abandoned which is a continuation of co-pending U.S. patent application Ser. No. 10/073,938 titled “Managed Object Replication And Delivery” filed Feb. 14, 2002, the disclosures of each of which are incorporated herein by reference in their entirety. This application is also related to U.S. patent application Ser. No. 11/980,672, titled “Popularity-based selective replication in Content Delivery Network,” and filed on even date herewith, the entire disclosure of which is incorporated herein by reference.BACKGROUND
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.
Exemplary embodiments of the invention are illustrated in the accompanying drawings in which like references indicate similar or corresponding elements and in which:
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
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
According to embodiments of the invention and referring to
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
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
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
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
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
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 of the list records the number of requests that arrived when the current time was within the first sub-interval, the second element P 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, so, e.g., P becomes P, P becomes P, and P[N] becomes P. After the rotation, the new P 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 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+P+ . . . +P[N] is stored in a register M. The popularity can be then computed by adding P to M. When a rotation occurs, the new value of M becomes M+=P−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 can be set to M after the rotation. Then, the value of P 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 . . . 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 is incremented (at 430) by 1. If the current time is within a new time sub-interval (at 440), then the value of P is decremented by the value of M, M+=P−P[N], the list P is rotated and P 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.
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
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
At the outset when the system starts and there is no popularity data available yet, the initial values of both PL and PI 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 PL and PI automatically. The initial values of PL and PI can also be set to other values. Indeed, the initial values of PL and PI 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 PL and PI. If a computed PL or PI is smaller than the minimum specification, PL or PI 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
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):
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:
in the message body, if the requested object is found available either locally or on another server (parent or origin). In this example, “servemame” 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:
in the message body, where “redimame” 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://servemame/path/file.asf”, where “servemame” 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://redirectomame/path/file.asf”, where “redimame” 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
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,
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.
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.
1. A content delivery method for distributing objects maintained on at least one origin server via a content delivery network (CDN), the method comprising:
- providing a plurality of servers in the CDN, wherein each of the plurality of servers is distinct from the at least one origin server, the plurality of servers comprising a plurality of edge servers and a plurality of parent servers;
- directing a request by a client for an object to a first edge server in the CDN, regardless of whether the first edge server has the requested object, wherein said first edge server was selected based at least in part on network traffic conditions;
- if the first edge server has the requested object, serving the requested object to the client from the first edge server;
- otherwise, sending the client a response that causes the client to be redirected to a second server in the CDN to handle the request, wherein the second server comprises a parent server of the first edge server; and
- receiving, at the second server, a second request for the object from the client and serving the requested object to the client from the second server, wherein if a copy of the requested object is not stored on the second server, directing the client to another server in the CDN.
2. A method as recited in claim 1, wherein said serving the requested object to the client from the second server is responsive to said second request.
3. A method as recited in claim 1, wherein the object is a streaming object.
4. A method as recited in claim 1, wherein said first edge server was selected based at least in part on server load.
5. A method as recited in claim 1, further comprising:
- attempting to serve the requested object to the client from the second server in the CDN.
6. A method as recited in claim 1, wherein the step of directing is repeated for a plurality of other servers in the CDN.
7. A method, in a framework in which resources maintained on one or more origin servers of content providers are delivered to end user clients via a shared content delivery network (CDN), the method comprising:
- providing a plurality of server sites in the CDN, wherein each of the plurality of server sites comprises one or more servers distinct from the one or more origin servers, the plurality of server sites comprising a plurality of edge server sites and a plurality of parent server sites;
- causing a client request for a resource to be directed to a first edge server site in said CDN, without consideration as to whether the first edge server site has a copy of the requested resource, wherein said first edge server site was selected based at least in part on network traffic conditions;
- if the first edge server site has a copy of the requested resource, then serving the requested resource to the client from the first edge server site; otherwise,
- if the first edge server site does not have a copy of the requested resource, sending the client a response that causes the client to be directed to a second server site in the CDN, wherein the second server site comprises a parent server site of the first edge server site; and
- receiving, at the second server site, a second request for the resource from the client and serving the requested resource to the client from the second server site, wherein if a copy of the requested resource is not stored on the second server site, directing the client to another server site in the CDN.
8. A method as recited in claim 7, further comprising:
- attempting to serve the requested resource to the client from the second server site in the CDN.
9. A method as recited in claim 7, wherein a copy of the requested resource is stored at the second server site prior to the issuance of the resource request by the client.
10. A method, in a framework in which resources maintained on one or more origin servers of at least one content provider are delivered to end user clients via a content delivery network (CDN), the method comprising:
- providing a plurality of server sites in CDN, wherein each of the plurality of server sites comprises one or more servers distinct from the one or more origin servers, the plurality of server sites comprising a plurality of edge server sites and a plurality of parent server sites;
- receiving a client request for a resource at a first edge server site in said CDN, wherein said first edge server site was selected based at least in part on network traffic conditions;
- if the first edge server site has a copy of the requested resource, then serving the requested resource to the client from the first edge server site; otherwise,
- if the first edge server site does not have a copy of the requested resource, then sending the client a response that causes the client to retrieve the requested resource from a second server site in the CDN, wherein the second server site comprises a parent server site of the first edge server site; and
- receiving, at the second server site, a second request for the resource from the client and serving the requested resource to the client from the second server site, wherein if a copy of the requested resource is not stored on the second server site, directing the client to another server site in the CDN.
11. A method as recited in claim 10, a copy of the requested resource is stored at the second server site prior to receipt of the client request by the first server site.
|4495570||January 22, 1985||Kitajima et al.|
|4591983||May 27, 1986||Bennett et al.|
|4594704||June 10, 1986||Ollivier|
|4726017||February 16, 1988||Krum et al.|
|4803641||February 7, 1989||Hardy et al.|
|4839798||June 13, 1989||Eguchi et al.|
|4847784||July 11, 1989||Clancey|
|4920432||April 24, 1990||Eggers et al.|
|4922417||May 1, 1990||Churm et al.|
|4943932||July 24, 1990||Lark et al.|
|4949187||August 14, 1990||Cohen|
|4949248||August 14, 1990||Caro|
|5029232||July 2, 1991||Nall|
|5130792||July 14, 1992||Tindell et al.|
|5132992||July 21, 1992||Yurt et al.|
|5136716||August 4, 1992||Harvey|
|5172413||December 15, 1992||Bradley|
|5191573||March 2, 1993||Hair|
|5253275||October 12, 1993||Yurt et al.|
|5253341||October 12, 1993||Rozmanith|
|5287499||February 15, 1994||Nemes|
|5287537||February 15, 1994||Newmark et al.|
|5291554||March 1, 1994||Morales|
|5341477||August 23, 1994||Pitkin et al.|
|5371532||December 6, 1994||Gelman|
|5410343||April 25, 1995||Coddington|
|5414455||May 9, 1995||Hooper|
|5442389||August 15, 1995||Blahut|
|5442390||August 15, 1995||Hooper|
|5442749||August 15, 1995||Northcutt|
|5471622||November 28, 1995||Eadline|
|5475615||December 12, 1995||Lin|
|5508732||April 16, 1996||Bottomley|
|5515511||May 7, 1996||Nguyen|
|5519435||May 21, 1996||Anderson|
|5528281||June 18, 1996||Grady|
|5539621||July 23, 1996||Kikinis|
|5542087||July 30, 1996||Neimat et al.|
|5544313||August 6, 1996||Shachnai|
|5544327||August 6, 1996||Dan|
|5550577||August 27, 1996||Verbiest|
|5550863||August 27, 1996||Yurt|
|5550982||August 27, 1996||Long|
|5557317||September 17, 1996||Nishio|
|5568181||October 22, 1996||Greenwood et al.|
|5572643||November 5, 1996||Judson|
|5590288||December 31, 1996||Castor|
|5592611||January 7, 1997||Midgely|
|5594910||January 14, 1997||Filepp et al.|
|5603026||February 11, 1997||Demers et al.|
|5614940||March 25, 1997||Cobbley et al.|
|5619648||April 8, 1997||Canale|
|5623656||April 22, 1997||Lyons|
|5625781||April 29, 1997||Cline|
|5627829||May 6, 1997||Gleeson et al.|
|5630067||May 13, 1997||Kindell|
|5633999||May 27, 1997||Clowes|
|5634006||May 27, 1997||Baugher et al.|
|5638443||June 10, 1997||Stefik et al.|
|5644714||July 1, 1997||Kikinis|
|5646676||July 8, 1997||Dewkett et al.|
|5649186||July 15, 1997||Ferguson|
|5659729||August 19, 1997||Nielsen|
|5666362||September 9, 1997||Chen|
|5671279||September 23, 1997||Elgamal|
|5675734||October 7, 1997||Hair|
|5682512||October 28, 1997||Tetrick|
|5699513||December 16, 1997||Feigen et al.|
|5712979||January 27, 1998||Graber et al.|
|5715453||February 3, 1998||Stewart|
|5721914||February 24, 1998||DeVries|
|5734719||March 31, 1998||Tsevdos et al.|
|5734831||March 31, 1998||Sanders|
|5740423||April 14, 1998||Logan et al.|
|5742762||April 21, 1998||Scholl|
|5751961||May 12, 1998||Smyk|
|5761507||June 2, 1998||Govett|
|5761663||June 2, 1998||Lagarde et al.|
|5764906||June 9, 1998||Edelstein et al.|
|5774660||June 30, 1998||Brendel et al.|
|5774668||June 30, 1998||Choquier et al.|
|5777988||July 7, 1998||Cisneros|
|5777989||July 7, 1998||McGarvey|
|5778187||July 7, 1998||Monteiro et al.|
|5781909||July 14, 1998||Logan et al.|
|5784058||July 21, 1998||LaStrange et al.|
|5796952||August 18, 1998||Davis|
|5799141||August 25, 1998||Galipeau et al.|
|5802106||September 1, 1998||Packer|
|5802291||September 1, 1998||Balick et al.|
|5812769||September 22, 1998||Graber|
|5815662||September 29, 1998||Ong|
|5815664||September 29, 1998||Asano|
|5819092||October 6, 1998||Ferguson et al.|
|5828847||October 27, 1998||Gehr|
|5832069||November 3, 1998||Waters et al.|
|5832506||November 3, 1998||Kuzma|
|5832514||November 3, 1998||Norin et al.|
|5835718||November 10, 1998||Blewett|
|5845090||December 1, 1998||Collins, III et al.|
|5845303||December 1, 1998||Templeman|
|5856974||January 5, 1999||Gervais et al.|
|5862339||January 19, 1999||Bonnaure|
|5867706||February 2, 1999||Martin et al.|
|5867799||February 2, 1999||Lang et al.|
|5870546||February 9, 1999||Kirsch|
|5870559||February 9, 1999||Leshem et al.|
|5878212||March 2, 1999||Civanlar et al.|
|5884038||March 16, 1999||Kapoor|
|5890171||March 30, 1999||Blumer et al.|
|5893116||April 6, 1999||Simmonds et al.|
|5894554||April 13, 1999||Lowery et al.|
|5896533||April 20, 1999||Ramos et al.|
|5898456||April 27, 1999||Wahl|
|5903723||May 11, 1999||Beck et al.|
|5907704||May 25, 1999||Gudmundson et al.|
|5913028||June 15, 1999||Wang et al.|
|5913033||June 15, 1999||Grout|
|5918010||June 29, 1999||Appleman et al.|
|5919247||July 6, 1999||Van Hoff et al.|
|5920701||July 6, 1999||Miller et al.|
|5931904||August 3, 1999||Banga|
|5933832||August 3, 1999||Suzuoka et al.|
|5933835||August 3, 1999||Adams et al.|
|5935207||August 10, 1999||Logue et al.|
|5940831||August 17, 1999||Takano|
|5944780||August 31, 1999||Chase|
|5945989||August 31, 1999||Freishtat et al.|
|5951694||September 14, 1999||Choquier et al.|
|5956489||September 21, 1999||San Andres et al.|
|5956716||September 21, 1999||Kenner|
|5958008||September 28, 1999||Pogrebisky et al.|
|5961596||October 5, 1999||Takubo et al.|
|5966440||October 12, 1999||Hair|
|5968121||October 19, 1999||Logan et al.|
|5973696||October 26, 1999||Agranat et al.|
|5978791||November 2, 1999||Farber et al.|
|5983214||November 9, 1999||Lang et al.|
|5983227||November 9, 1999||Nazem et al.|
|5987606||November 16, 1999||Cirasole et al.|
|5991809||November 23, 1999||Kriegsman|
|5996025||November 30, 1999||Day|
|6002720||December 14, 1999||Yurt et al.|
|6003030||December 14, 1999||Kenner et al.|
|6012090||January 4, 2000||Chung et al.|
|6014686||January 11, 2000||Elnozahy et al.|
|6014698||January 11, 2000||Griffiths|
|6016509||January 18, 2000||Dedrick|
|6016512||January 18, 2000||Huitema|
|6018516||January 25, 2000||Packer|
|6021426||February 1, 2000||Douglis|
|6023470||February 8, 2000||Lee et al.|
|6026440||February 15, 2000||Shrader et al.|
|6029175||February 22, 2000||Chow et al.|
|6029176||February 22, 2000||Cannon|
|6035332||March 7, 2000||Ingrassia, Jr. et al.|
|6038216||March 14, 2000||Packer|
|6038310||March 14, 2000||Hollywood et al.|
|6038610||March 14, 2000||Belfiore et al.|
|6041324||March 21, 2000||Earl et al.|
|6044405||March 28, 2000||Driscoll, III et al.|
|6046980||April 4, 2000||Packer|
|6049831||April 11, 2000||Gardell et al.|
|6052718||April 18, 2000||Gifford|
|6052730||April 18, 2000||Felciano et al.|
|6065051||May 16, 2000||Steele et al.|
|6065062||May 16, 2000||Periasamy et al.|
|6070191||May 30, 2000||Narendran et al.|
|6078943||June 20, 2000||Yu|
|6081829||June 27, 2000||Sidana|
|6081835||June 27, 2000||Antcliff et al.|
|6081840||June 27, 2000||Zhao|
|6085193||July 4, 2000||Malkin et al.|
|6092112||July 18, 2000||Fukushige|
|6092204||July 18, 2000||Baker|
|6094706||July 25, 2000||Factor et al.|
|6098078||August 1, 2000||Gehani et al.|
|6098096||August 1, 2000||Tsirigotis et al.|
|6105028||August 15, 2000||Sullivan et al.|
|6108673||August 22, 2000||Brandt et al.|
|6108703||August 22, 2000||Leighton et al.|
|6112231||August 29, 2000||DeSimone et al.|
|6112239||August 29, 2000||Kenner et al.|
|6112240||August 29, 2000||Pogue et al.|
|6115357||September 5, 2000||Packer et al.|
|6115752||September 5, 2000||Chauhan|
|6119143||September 12, 2000||Dias et al.|
|6125388||September 26, 2000||Reisman|
|6125394||September 26, 2000||Rabinovich|
|6128601||October 3, 2000||Van Horne et al.|
|6128623||October 3, 2000||Mattis et al.|
|6128660||October 3, 2000||Grimm et al.|
|6130890||October 10, 2000||Leinwand et al.|
|6131095||October 10, 2000||Low et al.|
|6134583||October 17, 2000||Herriot|
|6144375||November 7, 2000||Jain et al.|
|6144702||November 7, 2000||Yurt et al.|
|6151624||November 21, 2000||Teare et al.|
|6154744||November 28, 2000||Kenner et al.|
|6154753||November 28, 2000||McFarland|
|6161137||December 12, 2000||Ogdon et al.|
|6163779||December 19, 2000||Mantha et al.|
|6167427||December 26, 2000||Rabinovich et al.|
|6173311||January 9, 2001||Hassett et al.|
|6173322||January 9, 2001||Hu|
|6178160||January 23, 2001||Bolton et al.|
|6181867||January 30, 2001||Kenner et al.|
|6185598||February 6, 2001||Farber et al.|
|6185619||February 6, 2001||Joffe et al.|
|6189030||February 13, 2001||Kirsch et al.|
|6189039||February 13, 2001||Harvey|
|6195680||February 27, 2001||Goldszmidt et al.|
|6205120||March 20, 2001||Packer et al.|
|6212565||April 3, 2001||Gupta|
|6226618||May 1, 2001||Downs|
|6226642||May 1, 2001||Beranek et al.|
|6230196||May 8, 2001||Guenthner et al.|
|6233623||May 15, 2001||Jeffords et al.|
|6240462||May 29, 2001||Agraharam et al.|
|6243760||June 5, 2001||Armbruster et al.|
|6249810||June 19, 2001||Kiraly|
|6256675||July 3, 2001||Rabinovich|
|6263313||July 17, 2001||Milsted|
|6266335||July 24, 2001||Bhaskaran|
|6266699||July 24, 2001||Sevcik|
|6269394||July 31, 2001||Kenner et al.|
|6272566||August 7, 2001||Craft|
|6275470||August 14, 2001||Ricciulli|
|6282569||August 28, 2001||Wallis et al.|
|6286045||September 4, 2001||Griffiths et al.|
|6298041||October 2, 2001||Packer|
|6314565||November 6, 2001||Kenner et al.|
|6317787||November 13, 2001||Boyd et al.|
|6324580||November 27, 2001||Jindal|
|6324582||November 27, 2001||Sridhar et al.|
|6330602||December 11, 2001||Law et al.|
|6332157||December 18, 2001||Mighdoll et al.|
|6338044||January 8, 2002||Cook et al.|
|6343298||January 29, 2002||Savchenko et al.|
|6345294||February 5, 2002||O'Toole et al.|
|6347085||February 12, 2002||Kelly|
|6351775||February 26, 2002||Yu|
|6351776||February 26, 2002||O'Brien et al.|
|6360256||March 19, 2002||Lim|
|6370571||April 9, 2002||Medin, Jr.|
|6370580||April 9, 2002||Kriegsman|
|6389462||May 14, 2002||Cohen et al.|
|6398245||June 4, 2002||Gruse et al.|
|6405252||June 11, 2002||Gupta et al.|
|6405257||June 11, 2002||Gersht et al.|
|6412000||June 25, 2002||Riddle et al.|
|6415280||July 2, 2002||Farber et al.|
|6415368||July 2, 2002||Glance et al.|
|6418421||July 9, 2002||Hurtado|
|6421714||July 16, 2002||Rai et al.|
|6421726||July 16, 2002||Kenner et al.|
|6427170||July 30, 2002||Sitaraman et al.|
|6430618||August 6, 2002||Karger et al.|
|6442588||August 27, 2002||Clark et al.|
|6453319||September 17, 2002||Mattis et al.|
|6456630||September 24, 2002||Packer et al.|
|6460082||October 1, 2002||Lumelsky|
|6460085||October 1, 2002||Toporek et al.|
|6463454||October 8, 2002||Lumelsky et al.|
|6463508||October 8, 2002||Wolf|
|6466949||October 15, 2002||Yang et al.|
|6470389||October 22, 2002||Chung et al.|
|6473405||October 29, 2002||Ricciulli|
|6480893||November 12, 2002||Kriegsman|
|6484143||November 19, 2002||Swildens et al.|
|6484204||November 19, 2002||Rabinovich|
|6487555||November 26, 2002||Bharat et al.|
|6490580||December 3, 2002||Dey et al.|
|6493707||December 10, 2002||Dey et al.|
|6496856||December 17, 2002||Kenner et al.|
|6502125||December 31, 2002||Kenner et al.|
|6502205||December 31, 2002||Yanai et al.|
|6502215||December 31, 2002||Raad et al.|
|6505248||January 7, 2003||Casper et al.|
|6529477||March 4, 2003||Toporek et al.|
|6553413||April 22, 2003||Lewin et al.|
|6553420||April 22, 2003||Karger et al.|
|6557054||April 29, 2003||Reisman|
|6564251||May 13, 2003||Katariya et al.|
|6577595||June 10, 2003||Counterman|
|6581090||June 17, 2003||Lindbo et al.|
|6584083||June 24, 2003||Toporek et al.|
|6587837||July 1, 2003||Spagna|
|6591288||July 8, 2003||Edwards et al.|
|6591299||July 8, 2003||Riddle et al.|
|6594260||July 15, 2003||Aviani et al.|
|6598121||July 22, 2003||Challenger et al.|
|6611862||August 26, 2003||Reisman|
|6625643||September 23, 2003||Colby et al.|
|6651141||November 18, 2003||Adrangi|
|6654344||November 25, 2003||Toporek et al.|
|6654807||November 25, 2003||Farber et al.|
|6658464||December 2, 2003||Reisman|
|6665706||December 16, 2003||Kenner et al.|
|6665726||December 16, 2003||Leighton et al.|
|6678659||January 13, 2004||Van Kommer|
|6691148||February 10, 2004||Loyall et al.|
|6694358||February 17, 2004||Swildens et al.|
|6699418||March 2, 2004||Okada et al.|
|6708137||March 16, 2004||Carley|
|6718328||April 6, 2004||Norris|
|6732237||May 4, 2004||Jacobs et al.|
|6741563||May 25, 2004||Packer|
|6741990||May 25, 2004||Nair et al.|
|6751673||June 15, 2004||Shaw|
|6754699||June 22, 2004||Swildens et al.|
|6754706||June 22, 2004||Swildens et al.|
|6763377||July 13, 2004||Belknap et al.|
|6763388||July 13, 2004||Tsimelzon|
|6778502||August 17, 2004||Ricciulli|
|6785704||August 31, 2004||McCanne|
|6799221||September 28, 2004||Kenner et al.|
|6801576||October 5, 2004||Haldeman et al.|
|6834306||December 21, 2004||Tsimelzon|
|6839758||January 4, 2005||SØrensen|
|6842604||January 11, 2005||Cook et al.|
|6859791||February 22, 2005||Spagna|
|6859840||February 22, 2005||Singal et al.|
|6870851||March 22, 2005||Leinwand et al.|
|6874032||March 29, 2005||Gersht et al.|
|6901604||May 31, 2005||Kiraly|
|6915307||July 5, 2005||Mattis et al.|
|6915329||July 5, 2005||Kriegsman|
|6928442||August 9, 2005||Farber et al.|
|6934255||August 23, 2005||Toporek et al.|
|6950623||September 27, 2005||Brown et al.|
|6963910||November 8, 2005||Belknap|
|6963980||November 8, 2005||Mattsson|
|6963981||November 8, 2005||Bailey et al.|
|6965890||November 15, 2005||Dey et al.|
|6970432||November 29, 2005||Hankins et al.|
|6973490||December 6, 2005||Robertson et al.|
|6976090||December 13, 2005||Ben-Shaul et al.|
|6981050||December 27, 2005||Tobias et al.|
|6981180||December 27, 2005||Bailey et al.|
|6996616||February 7, 2006||Leighton et al.|
|6999988||February 14, 2006||Buddhikot et al.|
|7003572||February 21, 2006||Lownsbrough et al.|
|7007089||February 28, 2006||Freedman|
|7010578||March 7, 2006||Lewin et al.|
|7012900||March 14, 2006||Riddle|
|7013342||March 14, 2006||Riddle|
|7024466||April 4, 2006||Outten et al.|
|7032072||April 18, 2006||Quinn et al.|
|7039633||May 2, 2006||Dey et al.|
|7047300||May 16, 2006||Oehrke et al.|
|7054902||May 30, 2006||Toporek et al.|
|7054935||May 30, 2006||Farber et al.|
|7058706||June 6, 2006||Iyer et al.|
|7069177||June 27, 2006||Carley|
|7096266||August 22, 2006||Lewin et al.|
|7103564||September 5, 2006||Ehnebuske|
|7103645||September 5, 2006||Leighton et al.|
|7110984||September 19, 2006||Spagna|
|7117259||October 3, 2006||Rohwer|
|7188085||March 6, 2007||Pelletier|
|7206748||April 17, 2007||Gruse|
|7254645||August 7, 2007||Nishi|
|7562153||July 14, 2009||Biliris et al.|
|20010027491||October 4, 2001||Terretta et al.|
|20010029525||October 11, 2001||Lahr|
|20010049732||December 6, 2001||Raciborski et al.|
|20010051980||December 13, 2001||Raciborski et al.|
|20010056500||December 27, 2001||Farber et al.|
|20020010798||January 24, 2002||Ben-Shaul et al.|
|20020016831||February 7, 2002||Peled et al.|
|20020016835||February 7, 2002||Gamerman|
|20020018449||February 14, 2002||Ricciulli|
|20020023164||February 21, 2002||Lahr|
|20020023165||February 21, 2002||Lahr|
|20020040404||April 4, 2002||Lahr|
|20020042817||April 11, 2002||Lahr|
|20020046273||April 18, 2002||Lahr et al.|
|20020046405||April 18, 2002||Lahr|
|20020049857||April 25, 2002||Farber et al.|
|20020059592||May 16, 2002||Kiraly|
|20020066038||May 30, 2002||Mattsson et al.|
|20020073199||June 13, 2002||Levine et al.|
|20020078233||June 20, 2002||Biliris|
|20020082999||June 27, 2002||Lee et al.|
|20020083124||June 27, 2002||Knox et al.|
|20020087797||July 4, 2002||Adrangi|
|20020089470||July 11, 2002||Raman et al.|
|20020092026||July 11, 2002||Janniello et al.|
|20020099850||July 25, 2002||Farber et al.|
|20020116444||August 22, 2002||Chaudhri et al.|
|20020124080||September 5, 2002||Leighton et al.|
|20020129134||September 12, 2002||Leighton et al.|
|20020131645||September 19, 2002||Hamilton|
|20020133537||September 19, 2002||Lau et al.|
|20020143798||October 3, 2002||Lisiecki et al.|
|20020143888||October 3, 2002||Lisiecki et al.|
|20020147774||October 10, 2002||Lisiecki et al.|
|20020152318||October 17, 2002||Menon et al.|
|20020163882||November 7, 2002||Bornstein et al.|
|20020198953||December 26, 2002||O'Rourke et al.|
|20020199016||December 26, 2002||Freedman|
|20030009444||January 9, 2003||Eidler et al.|
|20030018966||January 23, 2003||Cook et al.|
|20030028623||February 6, 2003||Hennessey et al.|
|20030028626||February 6, 2003||Hennessey et al.|
|20030028777||February 6, 2003||Hennessey et al.|
|20030031176||February 13, 2003||Sim|
|20030055972||March 20, 2003||Fuller et al.|
|20030061263||March 27, 2003||Riddle|
|20030061280||March 27, 2003||Bulson et al.|
|20030065703||April 3, 2003||Aborn|
|20030065762||April 3, 2003||Stolorz et al.|
|20030078888||April 24, 2003||Lee et al.|
|20030078889||April 24, 2003||Lee et al.|
|20030079027||April 24, 2003||Slocombe et al.|
|20030095660||May 22, 2003||Lee et al.|
|20030105604||June 5, 2003||Ash et al.|
|20030112792||June 19, 2003||Cranor et al.|
|20030149581||August 7, 2003||Chaudhri|
|20030154239||August 14, 2003||Davis et al.|
|20030158923||August 21, 2003||Burkhart|
|20030158928||August 21, 2003||Knox et al.|
|20040022194||February 5, 2004||Ricciulli|
|20040139097||July 15, 2004||Farber et al.|
|20040177148||September 9, 2004||Tsimelzon|
|20050021863||January 27, 2005||Jungck|
|20050033858||February 10, 2005||Swildens et al.|
|20050038851||February 17, 2005||Kriegsman|
|20050100027||May 12, 2005||Leinwand et al.|
|20050114296||May 26, 2005||Farber et al.|
|20050262104||November 24, 2005||Robertson et al.|
|20060143293||June 29, 2006||Freedman|
|20070055764||March 8, 2007||Dilley et al.|
|20090254661||October 8, 2009||Fullagar et al.|
|20100312861||December 9, 2010||Kolhi et al.|
|20100332595||December 30, 2010||Fullagar et al.|
|0 649 121||October 1994||EP|
|0 651 554||October 1994||EP|
|2 281 793||March 1995||GB|
|WO 96/42041||December 1996||WO|
|WO 97/11429||March 1997||WO|
|WO 97/29423||August 1997||WO|
|WO 09742582||November 1997||WO|
|WO 98/04985||February 1998||WO|
|WO 98/06033||February 1998||WO|
|WO 9859486||December 1998||WO|
|WO 99/017227||April 1999||WO|
|WO 99 48246||September 1999||WO|
|WO 00/29990||May 2000||WO|
|WO 00/60861||October 2000||WO|
- U.S. Appl. No. 10/073,938, filed Feb. 14, 2002.
- U.S. Appl. No. 11/715,316, filed Mar. 8, 2007.
- U.S. Appl. No. 11/980,672, filed Oct. 31, 2007.
- USPTO, Official Action, Final Rejection dated Jan. 21, 2009 in U.S. Appl. No. 10/073,938, filed Feb. 14, 2002.
- USPTO, Official Action, Final Rejection dated Sep. 11, 2006 in U.S. Appl. No. 10/073,938, filed Feb. 14, 2002.
- USPTO, Official Action, Non-Final Rejection dated Jan. 12, 2006 in U.S. Appl. No. 10/073,938, filed Feb. 14, 2002.
- USPTO, Official Action, Non-Final Rejection dated Mar. 29, 2005 in U.S. Appl. No. 10/073,938, filed Feb. 14, 2002.
- USPTO, Official Action, Non-Final Rejection dated Apr. 29, 2008 in U.S. Appl. No. 10/073,938, filed Feb. 14, 2002.
- USPTO, Official Action, Non-Final Rejection dated Oct. 31, 2008 in U.S. Appl. No. 11/715,316, filed Mar. 8, 2007.
- Korean Intellectual Property Office (KIPO), Notice of Preliminary Rejection (Non-Final)) for Korean Patent Application No. KR Oct. 2004-7012607, Jan. 19, 2010 [6 pgs.] plus English translation (provided by foreign associate) [5 pgs.].
- USPTO, Non-Final Office Action mailed Oct. 7, 2009 in U.S. Appl. No. 11/980,672.
- “Exporting Web Server Final Report,” http://www.cs.technion.ac.il/Labs/Lccn/projects/spring97/project4/final—report.html, Spring 1997 (downloaded Jul. 7, 2007).
- “Local Area Network Server Replacement Procedure”, IBM Technical Disclosure Bulletin, vol. 38, No. 1, (Jan. 1995), 235-236.
- “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.
- Adler, R. M., “Distributed Coordination Models for Client/Server Computing,” Computer 28, 4 (Apr. 1995), 14-22.
- Aggarwal, A. et al., “Performance of Dynamic Replication Schemes for an Internet Hosting Service”. Technical Report, At&T Labs, Oct. 1998.
- Andresen et al., “SWEB: Towards a Scalable World Wide Web Server on Multicomputers”, Proc. IPPS, (Apr. 15, 1996), 850-856.
- Andresen, D., et al., Multiprocessor scheduling with client resources to improve the response time of WWW applications, Proc. 11th Int'l Conf. on Supercomputing (Austria, Jul. 1997). ICS '97. ACM Press, NY, NY, 92-99.
- Awerbuch, B. et al., Distributed Paging for General Networks. In Proc. of the 7th ACM-SIAM Symposium on Discrete Algorithms, pp. 574-583, Jan. 1996.
- Baentsch, M, et al. “Enhancing the Web's Infrastructure: From Caching to Replication.” IEEE Internet Computing, 1(2): Mar. 18-27, 1997.
- Basturk, E., et al., “Using network layer anycast for load distribution in the Internet,” Tech. Rep., IBM T.J. Watson Research Center, Jul., 1997 (21 pgs.).
- Bestavros, A., “Speculative Data Dissemination 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.
- Bestavros, et al., “Server-Initiated Document Dissemination for the WWW,” IEEE Data Engineering Bulletin 19(3): Sep. 3-11, 1996.
- Bhattacharjee et al., “Application-layer anycasting,” in Proc. IEEE INFOCOM '97, Apr. 1997.
- 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.
- Carter et al., “Dynamic server selection using bandwidth probing in wide-area networks,” Tech. Rep. BU-CS-96-007, Comp. Sci. Dept., Boston University, Mar. 1996.
- Carter et al., Server selection using dynamic path characterization in Wide-Area Networks, IEEE INFOCOM '97, 1997 (pp. 1014-1021).
- Carter, J. Lawrence et al., “Universal Classes of Hash Functions”, Journal of Computer and System Sciences, vol. 18, No. 2, (Apr. 1979), 143-154.
- Chankhunthod, A. et al., “A Hierarchical Internet Object Cache”, Proc. of the 1996 USENIX Technical Conf., Jan. 1996, pp. 153-163.
- Cohen, J., et al., “Cache Array Routing Protocol v1.1”, Sep. 29, 1997; http://tools.ietf.org/id/draft-vinod-carp-v1-01.txt (Last-Modified: Wed, Oct. 1, 1997).
- Colajanni, M. and Yu, P. S. 1997. Adaptive TTL schemes for load balancing of distributed Web servers. SIGMETRICS Perform. Eval. Rev. 25, 2 (Sep. 1997), 36-42.
- Crovella et al., Dynamic server selection in the Internet, 3rd IEEE Workshop on the Arch. and Implementation of High Performance Computer Sys. '95, pp. 158-162, Aug. 1995.
- De Bra, P.M.E., et al., “Information Retrieval in the World Wide Web: Making Client-Based Searching Feasible”, Computer Networks and ISDN Systems, 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/, dates unknown (1996-2000), download Jul. 7, 2007.
- 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.
- Floyd, S., et al., “A Reliable Multicast Framework for Light-Weight Sessions and Application Level Framing”, In Proc. of ACM SIGCOMM '95, 342-356, Aug. 1995.
- Fox, A., “A Framework for Separating Server Scalability and Availability from Internet Application Functionality,” PhD thesis, University of California, Berkeley, 1998.
- 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.
- Goldszmidt, et al., “Load Distribution for Scalable Web Servers: Summer Olympics 1996—A Case Study,” In Proc. 8th IFIP/IEEE Int'l Workshop on Distributed Systems: Operations and Management, Sydney, Australia, Oct. 1997.
- 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., pp. 116-119, May 1996.
- JP 10(1998)—27148 machine translation prepared by Japanese Patent Office (JPO), published Jan. 27, 1998, Title: “Server System for Internet”, Applicant: Hitachi [23 pages].
- 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.
- Korkea-aho, M. (1995). Scalability in Distributed Multimedia Systems, Technical report TKO-B128, Helsinki University of Technology.
- Kwan et al., NCSA's World Wide Web Server: Design and Performance, IEEE, pp. 68-74, Nov. 1995.
- Luotonen et al., World-Wide Web Proxies, CERN, Apr. 1994 (modified May 24, 1994).
- Malpani, R., et al., “Making World Wide Web Caching Servers Cooperate”, in Proc. 4th Int3 l. World Wide Web Conf. (Dec. 1995), 10 pages (downloaded from http://www.w3.org/Conferences/WWW4/Papers/59/ on Jul. 7, 2007).
- Mourad et al., “Scalable Web Server Architectures,” iscc, 2nd IEEE Symposium on Computers and Communications (ISCC '97), Jul. 1997, pp. 12-16.
- Niki, Hitoshi, “Storage Network”, Computopia vol. 36, No. 415, Japan, Computer Age. Co., Ltd., Apr. 1, 2001, p. 52 (translation).
- Oguchi et al., A Study of Caching Proxy Mechanisms Realized on Wide Area Distributed Networks, High Performance Distributed Computing, 5th Int'l Symp., pp. 443-449, Aug. 1996.
- 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.
- Patent Abstracts of Japan, “Server System for Internet”, Pub. No. 10-027148, pub. date Jan. 27, 1998, Applicant: Hitachi, computer translation, 12 pgs.
- 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, pp. 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), 570-579.
- Rabin, M. O., 1989, “Efficient dispersal of information for security, load balancing, and fault tolerance,” J. ACM 36, 2 (Apr. 1989), 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.
- Ross, K.W., “Hash-Routing for Collections of Shared Web Caches”, IEEE Network Magazine, 11, 7:37-44, Nov.-Dec. 1997.
- Smith, “What can Archives offer the World Wide Web?”, Technical Report 11, University of Kent, Computing Laboratory, University of Kent, Canterbury, UK, Mar. 1994.
- Takahashi, Takao, “How to customize Apache Q&a,—Web server using Apache” Al Publishing, Apr. 30, 1999, First Edition, pp. 63-64 (translation).
- Thaler, D. G. And Ravishankar, C. V. 1998. Using name-based mappings to increase hit rates. IEEE/ACM Trans. Netw. 6, (Feb. 1, 1998), 1-14.
- Vitter, J. S., et al., “Optimal Prefetching via Data Compression,” Proc. 32nd Annual IEEE Symposium on Foundations of Computer Science (Oct. 1991).
- Wessels, Intelligent Caching for World-Wide Web Objects, Masters Thesis, University of Colorado, Jan. 1995 (also presented at INET '95 in Jun. 1995).
- Wolfson, O., et al., an Adaptive Data Replication Algorithm, ACM Transactions on Database Systems (TODS), vol. 22(4), Jun. 1997, pp. 255-314.
- International Preliminary Examination Report (IPER), Form PCT/IPEA/409, WIPO, for PCT/US03/04108, Oct. 2003 [3 pgs.].
- International Search Report (ISR), Form PCT/ISA/210, WIPO, for PCT/US03/04108, Aug. 2003 [3 pgs.].
- Sen, S., et al., “Proxy Prefix Caching for Multimedia Streams”, IEEE, 1999, Jun. 1999.
- Berra, P.B., et al., “Architecture for Distributed Database Systems,” Computer Communications, vol. 13, No. 4, May 1, 1990, pp. 217-231.
- 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, Jun. 1995 (Netherlands), pp. 149-172.
- 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 Nov. 1998, pp. 2223-2243, ISSN: 0169-7552.
- Vin, H., Multimedia Broadcasting Over the Internet: Part 1, Oct. 1998, IEEE Multimedia, IEEE Computer Society, US, vol. 5, NR.4, pp. 78-82.
- Martin Reisslein et al., “Interactive Video Streaming With Proxy Servers,” INFOCOM 2000, pp. 1-11.
- Almeroth, K., et al. “Scalable Delivery of Web Pages Using Cyclic Best-Effort (UDP) Multicast”, IEEE INFOCOM, San Francisco, California, USA, Jun. 1998.
- Awerbuch, et al., Competitive Distributed File Allocation. In Proc. of the 25th Ann. ACM Symp. on Theory of Computing, pp. 164-173, May 1993.
- Baentsch, M., et al., “Introducing Application-Level Replication and Naming into Today's Web,” Computer Networks and ISDN Systems, vol. 28, No. 7-11, pp. 921-930, May 1996.
- Bartal, Y., et al., “Competitive Algorithms for Distributed Data Management”, 24th Annual ACM STOC, May 1992, Victoria, B.C. Canada.
- Berners-Lee, T. & Connolly, D., “Hypertext Markup Language—2.0,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1866, Nov. 1995.
- Berners-Lee, T., et al., “Hypertext Transfer Protocol—HTTP/1.0,” Internet Engineering Task Force (IETF) Internet Draft, draft-ieff-http-v10-spec-00.ps, Mar. 1995.
- Berners-Lee, T., et al., “Hypertext Transfer Protocol—HTTP/1.0,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1945, May 1996.
- Berners-Lee, T., et al., RFC 1738—Uniform Resource Locators, Dec. 1994.
- 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.
- Brisco, T. P. RFC 1794: DNS support for load balancing, Apr. 1995.
- Cate, V. “Alex: a global file system”, in Proc. Usenix Conf. on File Systems, May, 1992, pp. 1-11.
- Colajanni, M., et al., “Scheduling Algorithms for Distributed Web Servers,” International Conf. on Distributed Computing Systems (ICDCS), Baltimore, Maryland, USA, May 1997.
- 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 (Aug. 1992). D. Oran, Ed. SIGCOMM '92. ACM Press, New York, NY, 281-292.
- Eriksson, H., “MBONE: The Multicast Backbone,” Communications of the ACM, vol. 37, No. 8, p. 54-60, Aug. 1994.
- 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.
- Fielding, R., et al., “Hypertext Transfer Protocol—HTTP/1.1,” Internet Engineering Task Force(IETF) Request for Comments (RFC) 2068, Jan. 1997.
- 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.
- 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, pp. 194-202 (Mar. 15-18, 1999).
- 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.
- Li Xiao and Xiaodong Zhang, Exploiting neglected data locality in browsers, in Proc. 10th Int'l World Wide Web Conference, (WWW10), Hong Kong, May 1-5, 2001 (extended abstract) [2 pgs.].
- Malkin, G., “RIP Version 2 Carrying Additional Information,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1388, Jan. 1993.
- Mockapetris, P., RFC 1034: Domain Names—Concepts and Facilities, Nov. 1987.
- Mockapetris, P., RFC 1035: Domain Names—Implementation and Specification, Nov. 1987.
- Moy, J., “OSPF Version 2,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1583, Mar. 1994.
- Office Action (Final) for corresponding Japanese application, JP 2003-568495, from Japanese Patent Office, dated Feb. 12, 2008 (organized translation, 2 pgs.).
- Office Action for corresponding Chinese (PRC) patent application No. 03806039.6, from the Patent Office of the People's Republic of China, dated Jul. 13, 2007 (translation, 28 pgs., including 2 pg. summary).
- Office Action for corresponding Japanese application, JP 2003-568495, from Japanese Patent Office, dated Sep. 11, 2007 (organized translation, 2 pgs.).
- 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.
- 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.
- Povey, D. et al., “A distributed internet cache,” in Proc. Of the 20th Australasian Computer Science Conf., Feb. 1997.
- Second Office Action for corresponding Chinese (PRC) patent application No. 03806039.6, from the Patent Office of The People's Republic of China, dated Feb. 22, 2008 (translation, 4 pgs., including 2 pg. summary).
- Third Office Action for corresponding Chinese (PRC) patent application No. 03806039.6, from the Patent Office of The People's Republic of China, dated Aug. 8, 2008 (translation, 27 pgs. including 2 pg. summary).
- Topolcic, C., “Experimental Internet Stream Protocol, Version 2 (ST-II),” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1190, Oct. 1990.
- Touch, J. et al., “The X-Bone,”. Third Global Internet Mini-Conference at Globecom '98. Sydney, Australia, Nov. 1998, pp. 59-68 (pp. 44-52 of the mini-conference).
- Traina, P., “BGP-4 Protocol Analysis,” Internet Engineering Task Force (IETF) Request for Comments (RFC) 1774, Mar. 1995.
- Wessels, D. “Configuring Hierarchical Squid Caches”, Aug. 19, 1997.
- Wessels, D. et al., RFC2186, “Internet Cache Protocol (ICP), Version 2”, Sep. 1997, Memo; Internet RFC/STD/FYI/BCP Archives, Network Working Group.
- European Patent Office (EPO), Communication for Application No. EP03739748 dated Oct. 28, 2010, [1 pg.], including European Search Report [1 pg.], Annex to European Search Report [1 pg.].
- Korean Intellectual Property Office (KIPO), Notice of Final Rejection [3 pgs.] (with unofficial translation [2 pgs.]) for Korean Patent Application No. KR 10-2004-7012607, Sep. 30, 2010.
- “European Exam Report, dated Apr. 29, 2011”, EP App. No. 03739748.6, 5 pgs.
- European Examination Report, dated Nov. 28, 2012, Application No. 03739748.6, 6 pgs.
- Summons to Attend Oral Proceedings, dated Jun. 28, 2013, EP Application No. 03739748.6, 6 pgs.
Filed: Oct 30, 2007
Date of Patent: Jul 15, 2014
Patent Publication Number: 20080065724
Assignee: Level 3 Communications, LLC (Broomfield, CO)
Inventors: Steven L. Seed (Woodland Hills, CA), Kevin Hobbs (Vista, CA), Shane M. Glynn (Culver City, CA), Isaac W. Foraker (Winnetka, CA), Peter J. Jones (Thousand Oaks, CA), Homer H. Chen (Thousand Oaks, CA)
Primary Examiner: Sulaiman Nooristany
Application Number: 11/978,656
International Classification: G06F 15/16 (20060101);