Configurable access-based cache policy control

Abstract

Various embodiments of the present disclosure relate to a computer-implemented method that receives a header associated with an object, wherein the header includes a limit value specifying a number of times the object is to be served from a cache device before a revalidation, and a current count value specifying a number of times the object has been served since a most recent revalidation or load; receives a request for the object from a requesting device; and provides the object from the cache device to the requesting device upon determining that the current count value is below the limit value, or sends a request to revalidate the object upon determining that the current count value matches the limit value.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of U.S. Patent Application Serial No. 17 / 023,261, filed September 16, 2020, which is hereby incorporated by reference herein. TECHNICAL FIELD

[0003] Embodiments of the present disclosure relate generally to distributed computing systems and, more particularly, to configurable access-based cache policy control. BACKGROUND

[0004] Distributed computing systems include many different hardware and software components that operate to provide various services to clients of the distributed computing system. For example, a distributed computing system that performs a video streaming service can provide access to a library of media titles that can be viewed on a range of different client devices. The distributed computing system provides access to the library of media to clients, where a client requests a particular media item (e.g., a movie, a television episode, a music video, etc.) and a content provider transmits the media item to the client device. Traditional content streaming services enhance streaming performance by storing digital content related to media items at various service endpoints and cache devices within a content delivery network (CDN). In this way, a given client device requests a particular media item and multiple service endpoints can service the client device by providing digital content associated with playback of the media item (e.g., subtitles, metadata, authentication data, etc.). In some systems, a cache device can store digital content in a local storage area and provide the digital content from the local storage area rather than requesting the digital content from an origin server.

[0005] One drawback of managing the delivery of content items from a CDN is that delivering digital content from a cache device to its local storage can strain certain parts of the CDN. For example, a cache device might store specific types of digital content, such as smart containers, which contain links directing requesting devices to a server endpoint. When this origin endpoint becomes overloaded, the origin server can update the smart container with a different link, directing the requesting device to an endpoint different from the original server endpoint. However, the cache device does not send requests to update the smart container stored locally. As a result, the cache device serves outdated smart containers, directing the requesting device to the original server endpoint. This technique strains compute and network resources because some server endpoints become overloaded with requests. Some CDNs attempt to address this by requiring the cache device to forward each request to the origin server, which then processes each request to efficiently load balance traffic to individual server endpoints. However, this technique reduces the efficiency of the CDN because the origin server needs to receive and respond to each request from numerous requesting devices.

[0006] As mentioned above, there is a need in the field for more effective technologies to manage traffic within content delivery networks. Summary of the Invention

[0007] Various embodiments of this disclosure relate to a computer-implemented method that receives a header associated with an object, wherein the header includes a limit value specifying the number of times the object will be provided from a cache device before re-verification, and a current count value specifying the number of times the object has been provided since the most recent re-verification, load, or reload; receives a request for the object from a requesting device; and provides the object to the requesting device from the cache device when it is determined that the current count value is below the limit value, or sends a request to re-verify the object when it is determined that the current count value matches the limit value.

[0008] Other embodiments include, but are not limited to, computer systems that perform one or more aspects of the disclosed technology, and one or more non-transitory computer-readable storage media that include instructions for performing one or more aspects of the disclosed technology.

[0009] At least one technical advantage of the disclosed technology compared to existing technologies is that the content delivery network can manage the number of times edge devices serve digital content from local storage. Specifically, by limiting the number of times a given object can be served from the cache before requiring re-authentication, the origin server can monitor traffic directed to a specific service endpoint without directly responding to requests for digital content stored on the edge device. These technical advantages represent one or more technological advancements relative to existing methods. Attached Figure Description

[0010] To enable a detailed understanding of the features described above in the various embodiments, a more specific description of the inventive concept briefly summarized above can be provided by referring to the various embodiments, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings merely illustrate typical embodiments of the inventive concept and should not be construed as limiting the scope in any way, and that other equally effective embodiments exist.

[0011] Figure 1 The diagram illustrates a network infrastructure configured to implement one or more aspects of this disclosure.

[0012] Figure 2 The illustrations depict various embodiments of the present disclosure and their transmission to... Figure 1 Example headers associated with messages from devices in the network infrastructure.

[0013] Figure 3 The illustrations depict various embodiments of the present disclosure. Figure 1 A more detailed illustration of the caching techniques performed by the various devices included in the network infrastructure.

[0014] Figure 4 The illustrations depict various embodiments of the present disclosure. Figure 1 A more detailed illustration of another technology performed by the various devices included in the network infrastructure.

[0015] Figure 5 Descriptions of various embodiments of the present disclosure for caching objects or re-verifying stored... Figure 1 The flowchart shows the method steps for objects in the caching device of the network infrastructure.

[0016] Figure 6 Various embodiments of the present disclosure are described for storing... Figure 1 The flowchart shows the steps for setting the count limit value for objects in the cache device of the network infrastructure.

[0017] Figure 7 The illustration shows another network infrastructure configured to implement one or more aspects of this disclosure.

[0018] Figure 8 Various embodiments according to this disclosure Figure 7 A more detailed diagram of the content servers included in the network infrastructure.

[0019] Figure 9 Various embodiments according to this disclosure Figure 7 A more detailed diagram of the control server included in the network infrastructure.

[0020] Figure 10 Various embodiments according to this disclosureFigure 7 A more detailed illustration of the endpoint devices included in the network infrastructure. Detailed Implementation

[0021] Numerous specific details are set forth in the following description to provide a more thorough understanding of the various embodiments. However, it will be apparent to those skilled in the art that the inventive concept can be realized without one or more of these specific details.

[0022] Video streaming services deliver high-quality digital content to viewers. In some cases, video streaming services use a Content Delivery Network (CDN) to deliver digital content to a large number of client devices. When delivering digital content to client devices, a CDN can deliver the digital content from multiple server endpoints, where a given server endpoint provides a portion of the digital content. For example, when responding to a request to replay a video, the content server can provide parts of the video from multiple server endpoints, such as one endpoint providing the video file, one endpoint providing the subtitle file, and another endpoint providing the metadata. Various techniques for maintaining the effectiveness of a CDN often attempt to balance the load applied to the multiple server endpoints within the CDN by managing the amount of requests sent to each server endpoint.

[0023] Existing technologies alleviate the load on the server endpoint by storing certain assets locally in a caching device and serving files directly from the caching device, rather than routing requests to the server endpoint. However, this technology allows the caching device to serve expired files instead of sending them within the CDN, which would otherwise cause the cache to receive requests for updated files. Other technologies require the caching device to forward each request to the origin server, so that the origin server can ensure that the file is the current version and can perform load balancing for traffic to a specific server endpoint. However, such a requirement is wasteful of resources because routing each request for a specific file to the origin server requires each request received by the CDN to travel from the edge device in the CDN to the origin server, and each response to travel from the origin server back to the edge device through the CDN.

[0024] Conversely, the exposed network and associated exposed technologies enable devices within the CDN to manage the load applied to service endpoints by controlling the digital content that directs requesting devices to specific service endpoints. Specifically, the origin server configures a caching policy for a given object. The origin server generates one or more messages associated with the object. When providing a message to the caching device, the origin server includes the object in the message body and includes a header with various parameters specifying how the caching device stores the object in its local storage. One parameter is a count limit, which limits the maximum number of times the caching device can provide the object to the requesting device before re-verification. The caching device can provide the object from its local storage to the requesting device, up to the count limit provided in the message. The caching device maintains a current count value indicating the number of times it has provided the object from its local storage. When the caching device receives a request message from the requesting device, it compares the current count value to the count limit and only provides the object to the requesting device if the current count value has not reached the count limit.

[0025] For example, a cache device might determine that the current count value equals the count limit. The cache device can respond to this determination by sending a revalidation request message to the origin server to revalidate the object stored in local storage. Upon receiving a response message from the origin server specifying a new count limit value (e.g., 50), the cache device can then set the object's count limit to 50 and reset the current count value to zero. Based on these cache control values, the cache device can respond to up to 50 additional requests by providing a local storage version of the object before attempting to revalidate it.

[0026] Advantageously, origin servers can manage the load on service endpoints by controlling the number of times a requesting device is directed to a specific endpoint. More specifically, traditional CDNs require origin servers to receive every request for an object in order to load balance requests to service endpoints. In contrast, distributed networks using the disclosed techniques free up CDN computational and network resources by controlling the number of times downstream devices (e.g., edge caching devices) can provide the object that directs a requesting device to a specific service endpoint before re-authentication is required. Origin servers within a CDN effectively control traffic to various service endpoints without receiving and directly responding to every single request message.

[0027] System Overview

[0028] Figure 1The diagram illustrates a network infrastructure 100 configured to implement one or more aspects of this disclosure. As shown, the network infrastructure 100 includes a content provider 110, a content delivery network (CDN) 120, a gateway 150, and client devices 160. The CDN 120 includes an origin server 122, a middleware caching device 124, a server endpoint 130, and an edge caching device 140. The edge caching device 140(1) includes an object 126.

[0029] For illustrative purposes, reference numbers for identifying objects are used, and additional numbers for identifying instances are used where necessary, to represent multiple instances of similar objects. Additionally, even when not shown, network infrastructure 100 includes multiple instances of devices. For example, network infrastructure 100 may include multiple content providers 110 (e.g., 110(1), 110(2), etc.), client devices 160 (e.g., 160(1), 160(2), etc.) and / or edge caching devices 140 (e.g., 140(1), 140(2), etc.), and remains within the scope of the disclosed embodiments.

[0030] In operation, content provider 110 provides one or more media items to origin server 122. Origin server 122 ingests a given media item and stores it as one or more files and / or objects. In various embodiments, one or more service endpoints 130 may store one or more files and / or objects. When client device 160 requests a media item, devices within CDN 120 (e.g., origin server 122, middleware caching device 124, and / or edge caching device 140(1)) may provide the files and / or objects associated with the requested media item via edge caching device 140(1). In some embodiments, origin server 122 may direct client device 160 to receive specific files and / or objects from a specific service endpoint (e.g., service endpoint 130(3)) by providing a link (e.g., link 128) to a specific service endpoint 130(3), wherein service endpoint 130(3) provides client device 160 with one or more files and / or objects associated with the media item.

[0031] Content provider 110 provides content accessible to one or more client devices 160. For example, content provider 110 may generate one or more media streams as content, wherein a given media stream includes multiple digital content, which may include video data, audio data, text data, graphic data, metadata, and / or other types of data. In some embodiments, content provider 110 may forward one or more media streams to origin server 122 for ingestion. In this case, origin server 122 may store digital content in one or more devices within content delivery network (CDN) 120. For example, origin server 122 may store incoming media streams as media applications (e.g., an episode of a television program) within a content library (not shown) and / or one or more service endpoints 130 (e.g., 130(1), 130(2), 130(3), etc.).

[0032] Content Delivery Network (CDN) 120 distributes content to users (via client devices 160) on behalf of one or more content providers 110. In various embodiments, CDN 120 includes multiple devices that control the efficient delivery of digital content to one or more client devices 160. For example, when origin server 122 ingests a media stream as one or more files and / or objects, origin server 122 may cause multiple copies of the files and / or objects to be stored in multiple cache devices 124, 140. When a given object is stored in a given cache device 124, 140, cache device 124, 140 can respond to a request made by the client device 160 associated with that file (e.g., a request for a media stream in which the file is a component) by providing a local storage version of the object, instead of forwarding the request to origin server 122. Such a technique reduces the load imposed on origin server 122.

[0033] Alternatively or additionally, a caching device, such as edge caching device 140(1), may respond to a received client request by retrieving the asset from the content library and delivering the asset to client device 160. In this case, edge caching device 140(1) may respond to subsequent requests for the asset by retrieving a copy of the asset from local storage and delivering the asset to client device.

[0034] In various embodiments, CDN 120 may include multi-tiered caching devices. For example, as shown, CDN 120 includes two tiers of caching devices, including a middle-tier caching device 124 and an edge caching device 140. Each tier of caching devices may include a variety of specific numbers of caching devices. Additionally or alternatively, a given middle-tier caching device 124 is referred to as a parent cache, which is upstream of the applicable edge(one or more) edge(cache) devices 140(1). For example, middle-tier caching device 124(1) may be the parent of edge(cache) devices 140(1), 140(2). There may be any number of caching devices in each tier, and there may be any number of tiers within CDN 120.

[0035] Origin server 122 is a computer system configured to serve download requests for specific media from client device 160. The requested media, such as a specific media application or media stream, may be stored as digital content files and / or objects, which may reside on a mass storage system accessible to origin server 122. The mass storage system may include, but is not limited to, directly attached storage devices, network-attached file storage devices, or network-attached block storage devices. In various embodiments, origin server 122 stores a first copy of the asset in the mass storage system and acts as an authoritative repository or primary storage location for one or more assets. In various embodiments, the assets stored in the mass storage system act as the true source.

[0036] In various embodiments, origin server 122 may configure one or more caching policies associated with an asset when providing the asset to downstream devices. For example, origin server 122 may include a caching policy value that specifies that only edge caching device 140 (e.g., edge caching device 140) should store a local copy of object 126 (“only-at-edge”). In this case, origin server 122 may include the caching policy in the header of the message sent to the downstream device.

[0037] In some embodiments, origin server 122 can configure a caching policy for a given object to manage traffic within CDN 120. For example, object 126 may be a smart container that includes a link 128 used by client device 160 to directly connect to a specific service endpoint 130 (e.g., service endpoint 130(3)). In this case, origin server 122 can perform various load management techniques for the set of service endpoints 130 by controlling the number of times the link 128 is provided to the requesting device to service endpoint 130(3). To monitor the number of times the link 128 is provided, origin server 122 sets a caching control policy for object 126 that limits the number of times downstream caching devices can serve object 126.

[0038] In some embodiments, caching devices 124, 140 may send a re-authentication request for object 126 to an upstream device when a limit is determined to be reached. In this case, the re-authentication request includes the number of times it is monitored. In this way, origin server 122 can track the number of times caching devices 124, 140 provide object 126, rather than receiving every request originating from the requesting device. In some embodiments, origin server 122 may analyze load-related data when configuring cache control policies. In some embodiments, this data may include load metric data reported to origin server 122 by service endpoint 130. Additionally or alternatively, origin server 122 may receive request messages from downstream devices that indicate a specific service endpoint 130. In this case, origin server 122 may process the request messages to determine the load data associated with the specific endpoint.

[0039] Caching devices 124 and 140 provide caching services to network infrastructure 100 and CDN 120 by storing copies of files and / or objects available to requesting devices. In various embodiments, origin server 122 may cause a given file and / or object to be copied and stored in one or more intermediate-tier caching devices 124 and / or edge caching devices 140. In this case, files may be included as files in a given file directory, while objects may be included in an object repository. Origin server 122 may trigger one or more cache population commands to populate the storage areas of a given caching device 124 or 140 with digital content included in a media database. Additionally or alternatively, caching devices 124 and 140 may populate the storage areas of a given caching device 124 or 140 on demand in response to resource requests from client device 160. In some embodiments, caching devices 124 and 140 may act as server endpoint 130 and may store one or more files and / or objects associated with a specific service.

[0040] In various embodiments, intermediate tier cache device 124 and edge cache devices 140 (e.g., 140(1)-140(5)) are geographically distributed around the world or within a given region. In various embodiments, a given edge cache device 140 may be logically or physically closer to the client device 160 than intermediate tier cache device 124 and / or origin server 122. Although Figure 1The diagram illustrates a CDN 120 with three tiers of origin servers 122 and / or caching devices 124, 140; however, those skilled in the art will recognize that the architecture of the CDN 120 is merely an example embodiment. Other embodiments may include an additional intermediate tier of caching devices 124, or a single-tier CDN 120. In some embodiments, the CDN 120 may be a peer-to-peer network where a strict hierarchical structure of caching devices 124, 140 is not maintained. Thus, Figure 1 I do not intend to limit the scope of the embodiments in any way.

[0041] Client device 160 is coupled to CDN 120 via gateway 150 and / or one or more networks (not shown). For example, client device 160 may be directly connected to gateway 150, which is connected to CDN 120 via a public network. In this case, client device 160 may act as an endpoint for receiving media applications originating from content provider 110.

[0042] Configurable access-based caching policy control

[0043] Figure 2 The illustrations depict various embodiments of the present disclosure and their transmission to... Figure 1 Example header 200 associated with messages from devices in network infrastructure 100. As shown, header 200 includes cache control 210, and further controls, including a last modified field 220 and a time limit field 230. Cache control 210 includes a count limit field 212, an edge cache field 214, a current count field 216, and a maximum time limit field 218.

[0044] Header 200 is part of a message sent by the device. In various embodiments, header 200 may be part of a Hypertext Transfer Protocol (HTTP) response message generated by an upstream device and sent to a downstream device (e.g., from intermediate tier caching device 124 to edge caching device 140 (2)). In this case, one or more fields may correspond to fields specified in the HTTP specification (e.g., HTTP / 3.0). For example, the upstream device may receive a request message for a resource from the downstream device, where the downstream device determines that cache control limits (e.g., expiration, service count, etc.) have been reached and requests re-validation or an updated version of the resource. In this case, the upstream device may send an HTTP response message with a message body that includes the requested resource (e.g., object 126). As shown, header 200 includes a set of header fields, including cache control 210, and associated fields such as last modified field 220 and age field 230. In some embodiments, other fields, such as the last modified field, may be used by caching devices 124, 140 to determine whether the resource included in the resource message is more recent or older than a local copy of the resource stored at caching devices 124, 140.

[0045] Cache control 210 includes a set of one or more cache control fields that specify caching strategies for storing and maintaining resources in the cache. In various embodiments, any caching devices 124, 140 located between client device 160 and origin server 122 that do not recognize cache control 210 may ignore cache control 210, but will still propagate response messages through CDN 120.

[0046] A count limit field 212 is included in cache control 210 and provides a download limit that restricts the number of times a given cache device 124, 140 can provide a local copy of an object before requiring re-verification from an upstream device (e.g., intermediate tier cache device 124, origin server 122). A current count field 216 specifies the number of times a given cache device 124, 140 has provided a local copy of an object. In various embodiments, cache devices 124, 140 can compare the current count value of the current count field 216 with the count limit value of the count limit field 212 to determine whether cache devices 124, 140 have reached their limits.

[0047] Edge cache field 214 specifies that the object should only be cached at the edge device. In this case, the intermediate device will not store a local copy of the object. For example, intermediate tier cache device 124 may receive a response message containing object 126 in the body and an "edge only" edge cache value. Because the "edge only" edge cache value is present in header 200, intermediate tier cache device 124 can respond by forwarding the response message to edge cache device 140 without storing a local copy of object 126.

[0048] The maximum age field 218 specifies a time limit, which indicates the maximum number of years an object can reach before it expires. In this case, caching devices 124 and 140 can compare the value of the age field 230 with the value of the maximum age field 218 to determine whether the object has expired. In some embodiments, the maximum age field 218 may correspond to a specific field in the specification, such as the "maximum age" field in the HTTP 3.0 specification. In various embodiments, caching devices 124 and 140 send a re-verification request when they determine that a local copy of the object has reached either the download limit or the age limit.

[0049] Figure 3 The illustrations depict various embodiments of the present disclosure. Figure 1 A more detailed illustration of the caching techniques implemented by the various devices included in the network infrastructure 100 is shown. As illustrated, the network infrastructure 300 includes an origin server 122, an edge caching device 140, a server endpoint 130, and a client device 160. The edge caching device 140 includes a storage controller 310 and a storage partition 320. The storage partition 320 stores a local copy of object 126.

[0050] Storage controller 310 is a component included in the device that manages the contents of storage areas within the device. For example, storage controller 310 may manage storage partitions (e.g., storage partition 320) within edge caching device 140. In some embodiments, storage controller 310 may communicate with other devices to indicate what files and / or objects are being stored in storage partition 320. Additionally or alternatively, storage controller 310, local to a given caching device 124, 140, may manage the transfer of files and / or objects between storage partition 320 and other devices.

[0051] In some embodiments, storage controller 310 manages messages associated with providing a given file and / or object to client device 160. For example, edge caching device 140 may receive a request message originating from client device 160, where the requesting device is associated with streaming a specific video. In this case, storage controller 310 may identify the specific object associated with the request message and determine whether storage partition 320 is storing that specific object. Storage controller 310 may respond with an indication associated with this determination.

[0052] In some embodiments, storage controller 310 receives a response message from an upstream device (e.g., origin server 122, intermediate tier cache device 124, etc.) associated with a specific object. For example, edge cache device 140 may receive a response message in the form of a revalidation response that revalidates a specific object included in storage partition 320. In this case, storage controller 310 may process parameters included in the header of the response message to update one or more attributes of the asset stored in storage partition 320.

[0053] Storage partition 320 is a local storage area at edge caching device 140. In some embodiments, storage partition 320 may act as a specific type of storage area, such as a shared HTTP cache. For example, storage partition 320 may act as an HTTP cache that enables edge caching device 140 to respond to a retrieval request message sent by client device 160 by providing the file and / or object associated with the request message.

[0054] For illustrative purposes only, a series of numbered bubbles 1-7 depict examples of a series of operations that occur when the storage controller 310 processes a retrieval request message.

[0055] As depicted by bubble number 1, client device 160 sends a request message. For example, client device 160 may send a retrieval request message associated with object 126. As depicted by bubble number 2, edge caching device 140 processes the request message. Edge caching device 140 receives the request message originating from client device 160 and identifies the requested resource. Storage controller 310 then accesses storage partition 320 to determine whether a copy of the identified resource is stored in storage partition 320. If it is determined that storage partition 320 does not store a valid local copy of the identified resource, edge caching device 140 sends a request message to the upstream origin server 122.

[0056] At bubble number 3, origin server 122 sends a response message providing object 126. In some embodiments, upstream devices, such as origin server 122 and / or intermediate tier cache device 124, may send subsequent re-authentication response messages in response to a re-authentication request sent by edge cache device 140. Each response message includes a header that includes various values ​​for parameters associated with the response message and / or resources associated with the response message.

[0057] At bubble number 4, storage controller 310 processes the header from the response message. For example, header 328 may include two cache control values ​​that specify how edge caching device 140 should store object 126 locally. A count limit value 100 specifies the maximum number of times edge caching device 140 should serve object 126 from storage partition 320 before requesting re-authentication. The current count value is a counter maintained by storage controller 310 to track the number of times edge caching device 140 has served object 126. In various embodiments, storage controller 310 resets the current count value upon receiving object 126 or a re-authentication response for object 126. At bubble number 5, storage controller 310 stores a local copy of the requested resource in storage partition 320.

[0058] At bubble number 6, edge caching device 140 provides object 126 to client device 160. In some embodiments, object 126 may be an object type that includes data instructing client device 160 to retrieve resources from other devices within CDN 120. For example, object 126 may be a smart container that includes link 128, which directs client device 160 to server endpoint 130. At bubble number 7, client device 160 uses link 128 to send a subsequent resource request to the specified server endpoint 130.

[0059] Figure 4 The illustrations depict various embodiments of the present disclosure. Figure 1 A more detailed illustration of another technology performed by the various devices included in network infrastructure 100. As shown, network infrastructure 400 includes origin server 122, intermediate tier cache device 124, and edge cache device 140. Intermediate tier cache device 124 includes storage controller 410 and storage partition 420. Edge cache device 140 includes storage controller 430 and storage partition 440.

[0060] In operation, storage controller 410 responds to a request received from edge cache device 140 to re-verify object 126(2) locally stored by edge cache device 140 in storage partition 440. In this case, storage controller 410 refers to header 428 corresponding to object 126(1) locally stored in intermediate tier cache device 124 (in storage partition 420). Based on the values ​​included in header 428, storage controller 410 provides a modified value to header 448 so that edge cache device 140 does not exceed the count limit value specified in header 428.

[0061] In bubble number 1, intermediate caching device 124 responds to a request message received from edge caching device 140. In some embodiments, edge caching device 140 may send a request message to load object 126 from intermediate caching device 124. Alternatively or additionally, edge caching device 140 may send a request message requesting revalidation of object 126(2) stored in storage partition 440. Based on the received request message, storage controller 410 refers to header 428 associated with object 126(1) stored in storage partition 420. The count limit is 100, and the current count limit is 20, indicating that object 126 can be served a maximum of 80 more times before requiring revalidation.

[0062] In bubble number 2, intermediate caching device 124 sends a response message to edge caching device 140. In various embodiments, intermediate caching device 124 sends a response message that includes object 126(2) in the message body and header 448. In this case, intermediate caching device 124 can provide different count limit values ​​to require edge caching device 140 to request re-verification more frequently. In some embodiments, storage controller 410 sets the count limit value included in header 448 as a fraction of the count limit value included in header 428.

[0063] In bubble number 3, edge caching device 140 stores object 126(2). In various embodiments, storage controller 430 processes header 448 to determine how to store object 126(2) in storage partition 440. In some embodiments, storage controller 410 does not increment the current count value included in header 428 when providing object 126(1) to edge caching device 140. In such cases, the current count value in header 448 may be incremented when edge caching device 140 provides object 126(2) to client device (e.g., storage controller 410 later updates the current count value in header 428 from 20 to 28 when receiving the next reauthentication request message indicating that edge caching device 140 has provided object 126(2) eight times since the last reload or reauthentication). In some embodiments, storage controller 410 may update the current count value associated with object 126(1) by a count limit value specified in the response header generated by storage controller 410 when processing a reauthentication request from edge caching device 140. Updating the current count value in this way preserves the delivery allocation for edge cache device 140 until a subsequent re-authentication request is sent.

[0064] Figure 5 Descriptions of various embodiments of the present disclosure for caching objects or re-verifying stored... Figure 1 A flowchart of the method steps for objects in a caching device within a network infrastructure. (Although this is a reference...) Figures 1-4 The present invention describes these method steps using a system, but those skilled in the art will understand that any system configured to implement these method steps in any order falls within the scope of the present invention.

[0065] Method 500 begins at step 501, where edge caching device 140 receives a resource request message. In various embodiments, storage controller 310 included in edge caching device 140 receives the resource request message originating from a requesting device (e.g., client device 160). Edge caching device 140 receives the request message originating from client device 160 and identifies the object associated with the requested resource. In some embodiments, client device 160 may request a media item. In this case, edge caching device 140 may identify one or more files stored in CDN 120 as resources requested by client device 160.

[0066] In step 503, edge caching device 140 determines whether a valid version of object 126 is included in local storage partition 320. In various embodiments, storage controller 310 accesses storage partition 320 to determine whether a copy of the object associated with the requested resource (e.g., object 126) is stored in storage partition 320. If storage controller 310 identifies object 126 in storage partition 320, storage controller 310 proceeds to step 513. Otherwise, storage controller 310 determines that storage partition 320 does not store a valid local copy of the requested resource and proceeds to step 505.

[0067] In step 505, edge caching device 140 sends a request to load the identified object. In various embodiments, edge caching device 140 sends the request message upstream towards origin server 122. The upstream device (e.g., origin server 122, intermediate caching device 124) sends a response message providing the requested resource (e.g., object 126). The response message includes a header 328 that includes various parameters specifying values ​​associated with the response message, or the resource associated with the response message.

[0068] In step 507, edge caching device 140 loads and locally stores object 126. In various embodiments, storage controller 310 causes edge caching device 140 to store the requested resource in storage partition 320. In step 509, edge caching device 140 stores a count limit value. In some embodiments, storage controller 310 processes header 328 from a response message and determines one or more values, including one or more cache control values, to associate with object 126. For example, storage controller 310 may extract a count limit value from header 328 and associate the extracted count limit value with object 126 stored in storage partition 320.

[0069] In step 511, edge caching device 140 sets the current count value to zero. In various embodiments, storage controller 310 may respond to storage object 126 by resetting the current count value. Alternatively or additionally, storage controller 310 may respond to a response message (e.g., a revalidation response) by resetting the current count value associated with object 126 stored in storage partition 320 from a non-zero value to zero. In this case, storage controller 310 uses the current count value to monitor the number of times edge caching device 140 has served object 126 since receiving the most recent revalidation response.

[0070] Returning to step 503, upon determining that edge caching device 140 stores a local copy of the requested resource, edge caching device 140 proceeds to step 513, whereby edge caching device 140 determines whether the associated current count value is lower than the associated count limit value. In various embodiments, storage controller 310 identifies object 126 and retrieves the applicable current count value and count limit value associated with object 126. Storage controller 310 determines whether the current count value is lower than the count limit value. When storage controller 310 determines that the current count value is lower than the count limit value, edge caching device 140 proceeds to step 515; otherwise, storage controller 310 determines that the current count value has reached the count limit value and proceeds to step 519.

[0071] In some embodiments, the storage controller 310 may evaluate other attributes of the object 126. For example, the storage controller 310 may evaluate the age of the object 126 stored in the storage partition 320 to determine whether the object 126 has expired. When the storage controller 310 determines that all applicable criteria for serving the object 126 are met, the edge caching device 140 proceeds to step 515; otherwise, the storage controller 310 determines that at least one criterion for serving the object 126 is not met and proceeds to step 519.

[0072] In step 515, edge caching device 140 provides locally stored object 126 to the requesting device. In various embodiments, storage controller 310 causes edge caching device 140 to provide object 126 to the requesting device. In step 517, edge caching device 140 increments the current count associated with object 126. In various embodiments, storage controller 310 increments the current count associated with object 126 to reflect that edge caching device 140 has provided at least a portion of object 126 to the requesting device. In other embodiments, storage controller 310 may increment the current count only upon receiving confirmation that edge caching device 140 has sent the full version of object 126 to the requesting device.

[0073] Returning to step 513, when it is determined that the current count value of an object has reached the counting limit, edge caching device 140 proceeds to step 519, wherein edge caching device 140 sends a request message requesting re-authentication of the locally stored object. In various embodiments, storage controller 310 responds to the current count value reaching the counting limit by causing edge caching device 140 to send a re-authentication message for object 126 to an upstream device (e.g., intermediate tier caching device 124, origin server 122). In some embodiments, the request message includes the current count value and the counting limit associated with object 126. Additionally or alternatively, the request message includes an entity token associated with a specific service endpoint 130 (e.g., service endpoint 130(2)) to which object 126 directs the requesting device. In this case, origin server 122 may load balance requests for service endpoint 130 based on processing the entity token.

[0074] In step 521, edge caching device 140 determines whether a new object has been received. In various embodiments, edge caching device 140 may receive a re-authentication response for object 126. In this case, storage controller 310 retains object 126 in storage partition 320. Alternatively, edge caching device 140 may receive a new version of object 126. When edge caching device 140 determines that a new object has been received, edge caching device 140 proceeds to step 507, where edge caching device 140 loads the new version of object 126 and stores the new version of object 126 in local storage. Otherwise, edge caching device 140 determines that no new version of object 126 has been received, indicating that a re-authentication response has been received, and proceeds to step 509, where the count limit value associated with object 126 specified in the re-authentication response is stored in storage partition 320.

[0075] Figure 6 Various embodiments of the present disclosure are described for storing... Figure 1 A flowchart illustrating the steps involved in setting a count limit for objects in a cache device within a network infrastructure. (Although this is a reference...) Figures 1-4 The present invention describes these method steps using a system, but those skilled in the art will understand that any system configured to implement these method steps in any order falls within the scope of the present invention.

[0076] Method 600 begins at step 601, where origin server 122 optionally receives load metrics from a set of service endpoints 130. In various embodiments, service endpoints 130 may periodically report load metrics to origin server 122 in one or more messages. In some embodiments, service endpoints 130 may send load metric data directly. Alternatively or additionally, service endpoints 130 may send load metric data via caching devices 124, 140.

[0077] In step 603, origin server 122 receives an entity token from the reauthentication request. In various embodiments, origin server 122 may receive one or more reauthentication request messages from one or more downstream devices (e.g., caching devices 124, 140), wherein the reauthentication request message is associated with a specific object 126. Additionally or alternatively, the reauthentication request message may include an entity token indicating a service endpoint 130 provided by origin server 122 in a previous response message to object 126. For example, origin server 122 may send a first response message to edge caching device 140(1) including object 126, wherein object 126 includes a link to service endpoint 130(3). Origin server 122 may then receive a reauthentication request message from edge caching device 140(1) including an entity token identifying service endpoint 130(3).

[0078] In step 605, origin server 122 processes load data and entity tokens. In various embodiments, origin server 122 may process received tokens and / or received load metric data. In some embodiments, origin server 122 may process entity tokens from received request messages without processing received load metric data. For example, when origin server 122 receives one or more reauthentication requests to receive updated load metric data, origin server 122 may process the entity tokens included in the received reauthentication requests to determine the load associated with one or more service endpoints 130. Origin server 122 can then perform various load balancing techniques for the one or more service endpoints 130.

[0079] In step 607, origin server 122 generates a response message for object 126 based on the processed load metric. In various embodiments, origin server 122 may generate new cache control values ​​based on the data processed in step 605 to include in the response message header 328 and / or specify a new service endpoint 130 (e.g., service endpoint 130(2)) for object 126. For example, origin server 122 may take into account the load applied to a particular service endpoint 130(3) based on the number of times object 126, for which a link to service endpoint 130(3) is provided, is served by edge caching device 140. Origin server 122 may then specify a different service endpoint 130(2) to direct subsequent requesting devices to service endpoint 130(2). Additionally or alternatively, origin server 122 may adjust the count limit for object 126 to adjust the maximum number of times edge caching device 140 serves object 126 before requiring additional re-authentication requests.

[0080] General Overview

[0081] Figure 7 The illustration depicts another network infrastructure 700 configured to implement one or more aspects of this disclosure. As shown, the network infrastructure 700 includes endpoint devices 715, a content server 710, and a control server 710, each connected via a communication network 705. The network infrastructure 700 is configured to distribute content to the content server 710, and then this content is distributed to the endpoint devices 715 on demand.

[0082] Each endpoint device 715 communicates with one or more content servers 710 (also referred to as a “cache” or “node”) to download content, such as text data, graphic data, audio data, video data, and other types of data. The downloadable content—also referred to herein as a “file”—is then presented to the user of one or more endpoint devices 715. In various embodiments, endpoint devices 715 may include computer systems, set-top boxes (STBs), mobile computers, smartphones, tablet devices, consoles and handheld video game systems, digital video recorders (DVRs), DVD players, connected digital TVs, dedicated media streaming devices (e.g., (Set-top box), and / or any other technically feasible computing platform that has network connectivity and is capable of presenting content (e.g., text, images, audio, and / or video content) to users.

[0083] Each content server 710 includes, but is not limited to, storage devices, which may be standalone networked attached storage (NAS) systems, storage area networks (SANs), clusters or "farms" of storage devices, distributed storage architectures, or any other devices suitable for implementing one or more aspects of this disclosure. Additionally or alternatively, each content server 710 may include, but is not limited to, computing devices with storage subsystems, which may be standalone servers, clusters or "farms" of servers, one or more network devices, or any other devices suitable for implementing one or more aspects of this disclosure. Each content server 710 may include, but is not limited to, web servers and databases, and may be configured to communicate with a control server 720 to determine the location and availability of various files monitored and managed by the control server 720. Each content server 710 may also communicate with a cloud service source 730 and one or more other content servers 710 to "populate" each content server 710 with copies of various files. Furthermore, content servers 710 may respond to requests for files received from endpoint devices 715. Files may then be distributed from content servers 710 or via a wider content distribution network. In some embodiments, content server 710 enables users to authenticate (e.g., using a username and password) to access files stored on content server 710.

[0084] The control server 720 may include, but is not limited to, computing devices, which may be a standalone server, a cluster or "farm" of servers, one or more network devices, or any other device suitable for implementing one or more aspects of this disclosure. Although in Figure 7 Only a single control server 720 is shown in the figure, but in various embodiments, multiple control servers 720 (e.g., control servers 720(1), 720(2), etc.) may be implemented to monitor and manage files.

[0085] In various embodiments, cloud service source 730 may include online storage service (OSS) (e.g., Simple storage service Cloud storage, etc., where directories of thousands or millions of files are stored and accessed to populate content server 710. Cloud service source 730 may also provide computing and / or other processing services. Although in Figure 7 Only one cloud service source 730 is shown in the figure, but in various embodiments, multiple cloud service sources 730 can be implemented (e.g., cloud service sources 730(1), 730(2), etc.).

[0086] Figure 8 Various embodiments according to this disclosure Figure 7 A more detailed illustration of the content server 710 included in the network infrastructure is shown. As shown, the content server 710 includes, but is not limited to, a central processing unit (CPU) 804, a system disk 806, an input / output (I / O) device interface 808, a network interface 810, an interconnect (bus) 812, and a system memory 814.

[0087] CPU 804 is configured to retrieve and execute programming instructions stored in system memory 814, such as server application 817. Similarly, CPU 804 is configured to store application data (e.g., software libraries) and retrieve application data from system memory 814. Interconnect 812 is configured to facilitate the transfer of data such as programming instructions and application data between CPU 804, system disk 806, I / O device interface 808, network interface 810, and system memory 814. I / O device interface 808 is configured to receive input data from one or more I / O devices 816 and send the input data to CPU 804 via interconnect 812. For example, one or more I / O devices 816 may include one or more buttons, keyboards, mice, and / or other input devices. I / O device interface 808 is also configured to receive output data from CPU 804 via interconnect 812 and send the output data to one or more I / O devices 816.

[0088] System disk 806 may include one or more hard disk drives (HDDs), solid-state storage devices (SSDs), and / or similar storage devices. System disk 806 is configured to store non-volatile data, such as one or more files 818 (e.g., audio files, video files, subtitles, application files, software libraries, etc.). Files 818 can then be retrieved by one or more endpoint devices 715 via network 705. In some embodiments, network interface 810 is configured to operate according to one or more communication standards, such as Ethernet, Bluetooth, and / or one or more wireless communication standards.

[0089] System memory 814 includes server application 817, which configures content server 710 to serve requests received from endpoint device 715 and other content servers 710. For example, a service request may be for one or more files 818. When server application 817 receives a service request for a specific file, server application 817 retrieves the corresponding file 818 from system disk 806 and sends file 818 to endpoint device 715 and / or content server 710 via network 705.

[0090] For example, file 818 can be one of multiple digital items, such as visual content items like videos and / or still images. Similarly, file 818 can be one of multiple textual content items associated with one or more visual content items, such as movie metadata. In various embodiments, file 818 can be one of multiple security application data items associated with one or more content items and / or applications being executed by content server 710, control server 720, and / or endpoint device 715.

[0091] Figure 9 Various embodiments according to this disclosure Figure 7 A more detailed illustration of the control server 720 included in the network infrastructure is shown. As shown, the control server 720 includes, but is not limited to, a CPU 904, a system disk 906, an I / O device interface 908, a network interface 910, an interconnect 912, and a system memory 914.

[0092] CPU 904 is configured to retrieve and execute programming instructions stored in system memory 914, such as controlling application 917. Similarly, CPU 904 is configured to store application data (e.g., software libraries) and retrieve application data from system memory 914 and / or a database 918 stored in system disk 906. Interconnect 912 is configured to facilitate data transfer between CPU 904, system disk 906, I / O device interface 908, network interface 910, and system memory 914. I / O device interface 908 is configured to transfer input and output data between one or more I / O devices 916 and CPU 904 via interconnect 912. In various embodiments, system disk 906 may include one or more hard disk drives, solid-state storage devices, etc. In various embodiments, system disk 906 is configured to store database 918, which stores information associated with one or more content servers 710, cloud service sources 730, and / or files 818.

[0093] System memory 914 includes a control application 917 configured to access and process information stored in database 918 to determine how a particular file 818 will be copied among content servers 710 included in network infrastructure 700. Control application 917 may also be configured to receive and analyze performance characteristics associated with one or more content servers 710 and / or endpoint devices 715.

[0094] Figure 10 Various embodiments according to this disclosure Figure 7 A more detailed illustration of the endpoint device 715 included in the network infrastructure. As shown, the endpoint device 715 may include, but is not limited to, a CPU 1010, a graphics subsystem 1012, a mass storage unit 1014, an I / O device interface 1016, a network interface 1018, an interconnect 1022, and a memory subsystem 1030.

[0095] In some embodiments, CPU 1010 is configured to retrieve programming instructions stored in memory subsystem 1030 and execute them. Similarly, CPU 1010 is configured to store and retrieve application data (e.g., software libraries) stored in memory subsystem 1030. Additionally or alternatively, CPU 1010 is configured to store and retrieve data, including content items and / or application data, from mass storage unit 1014. Interconnect 1022 is configured to facilitate the transfer of data, such as programming instructions and application data, between CPU 1010, graphics subsystem 1012, mass storage unit 1014, I / O device interface 1016, network interface 1018, and memory subsystem 1030.

[0096] The graphics subsystem 1012 is configured to generate frames of video data and send these frames to the display device 1050. In various embodiments, the graphics subsystem 1012 may be integrated into an integrated circuit (IC) along with the CPU 1010. The display device 1050 may include any technically feasible means for generating images for display. For example, the display device 1050 may be manufactured using liquid crystal display (LCD) technology, cathode ray tube technology, and / or light-emitting diode (LED) display technology.

[0097] Mass storage unit 1014 may include, for example, hard disk drives and / or flash memory drives, and is configured to store non-volatile data. For example, mass storage unit 1014 may store one or more files 818, such as content items and / or application data. In various embodiments, endpoint device 715 may copy one or more files 818 (e.g., security application data) stored in memory subsystem 1030 to mass storage unit 1014.

[0098] Input / output (I / O) device interface 1016 is configured to receive input data from one or more user I / O devices 1052 and transmit the input data to CPU 1010 via interconnect 1022. For example, user I / O device 1052 may include one or more buttons, keyboards, mice, or other clicking devices. In various embodiments, I / O device interface 1016 also includes an audio output unit configured to generate an electrical audio output signal. In this case, user I / O device 1052 may include an audio output device, such as headphones and / or speakers, configured to generate sound output in response to an electrical audio input signal. Additionally or alternatively, display device 1050 may include a speaker. Examples of suitable devices known in the art capable of displaying video frames and generating sound output include televisions, smartphones, smartwatches, tablet devices, and so on.

[0099] Network interface 1018 is configured to send and receive data packets via network 705. In some embodiments, network interface 1018 is configured to communicate using at least one of Ethernet, Bluetooth, and / or one or more wireless communication standards. Network interface 1018 is coupled to CPU 1010 via interconnect 1022.

[0100] The memory subsystem 1030 includes programming instructions and application data. In various embodiments, the memory subsystem 1030 may include an operating system 1032, a user interface 1034, a playback application 1038, and / or a page cache 1036. The operating system 1032 performs system management functions, such as managing hardware devices including a graphics subsystem 1012, a mass storage unit 1014, an I / O device interface 1016, and a network interface 1018. The operating system 1032 also provides process and memory management models for the user interface 1034, the playback application 1038, and / or the page cache 1036. For example, an endpoint device 715 may execute the operating system 1032 to write data to the page cache 1036 and / or synchronize data included in the page cache 1036 to the mass storage unit 1014.

[0101] A user interface (UI) 1034, such as a graphical user interface (GUI) employing window and object metaphors, provides a mechanism for the user to interact with the endpoint device 715. Those skilled in the art will recognize various operating systems 1032 and / or user interfaces 1034 suitable for inclusion in the endpoint device 715. A playback application 1038 is configured to request and / or receive content (e.g., one or more files 818) from a content server 710 via a network interface 1018. Additionally, the playback application 1038 is configured to interpret the content and present it via a display device 1050 and / or a user I / O device 1052.

[0102] Page cache 1036 is part of volatile memory that stores file 818, such as content items and / or application data (e.g., security application data, metadata, etc.). In various embodiments, page cache 1036 may correspond to a portion of non-volatile memory. In this case, endpoint device 715 can synchronize data initially written to volatile memory by writing data to the corresponding portion of non-volatile memory. For example, page cache 1036 may correspond to a portion of mass storage unit 1014. In this case, endpoint device 715 then reads and / or writes file 818 to page cache 1036 instead of directly accessing and / or writing file 818 to mass storage unit 1014. Endpoint device 715 can then synchronize data between page cache 1036 and mass storage unit 1014 such that a copy of the data is stored in both page cache 1036 and mass storage unit 1014.

[0103] In summary, the storage controller included in the caching device receives requests for objects stored within the content delivery network. In some embodiments, the object is cached at the caching device; in other embodiments, the caching device loads the object into its cache. The storage controller processes the header of a response message associated with the object to determine whether to serve the object to the requesting device. The header includes a set of one or more cache control parameters, including a count limit value specifying the maximum number of times the caching device will serve the object before requesting revalidation. The header also includes a current count value indicating the number of times the caching device has served the object since the most recent load or revalidation. When it is determined that the current count value is below the count limit, the storage controller causes the caching device to serve the object and increments the current count value. When it is determined that the current count value has reached the count limit, the storage controller causes the caching device to request revalidation for the object. When the caching device subsequently sends a request message requesting revalidation of a locally stored object, the request message includes a token indicating the number of times the caching device has served the locally stored object since the response message was received.

[0104] In some embodiments, the object may be a smart container that includes a link to a service endpoint within the content delivery network. When a caching device serves the object to a requesting device, the requesting device uses this link to connect to the service endpoint to deliver the asset. In some embodiments, an origin server within the content delivery network may estimate load data based on messages received from a caching device requesting the object or re-authenticating the object. In this case, the message indicates the number of times the caching device has served the object since the most recent load or re-authentication, thereby directing the device to a specific service endpoint. The origin server processes this data to set a count limit, which is then included in subsequent headers associated with the object.

[0105] Compared to existing technologies, at least one technical advantage of the disclosed technology is that the content delivery network can effectively cache valid objects at edge devices. Specifically, by limiting the number of times a given object can be served from the cache before requiring revalidation, the origin server can ensure that the object remains valid and up-to-date without limiting the expiration policy associated with that object. Furthermore, by controlling how the caching device serves the cached smart container, the origin server can effectively load balance requests directed by the smart container to a specific server endpoint, rather than accepting every request for a given object. Additionally, by dynamically modifying the count limit associated with revalidation, the content delivery network can easily configure the frequency at which the caching device revalidates a given object based on multiple factors, including usage and the frequency with which the object is served to the requester.

[0106] 1. In various embodiments, a computer-implemented method includes receiving a header associated with an object, wherein the header includes a limit value specifying the number of times the object will be provided from a cache device prior to re-authentication, and a current count value specifying the number of times the object has been provided since the most recent re-authentication or load; receiving a request for the object from a requesting device; and providing the object from the cache device to the requesting device if it is determined that the current count value is below the limit value, or sending a request to re-authenticate the object if it is determined that the current count value matches the limit value.

[0107] 2. The computer-implemented method as described in Clause 1, wherein the header further includes an expiration time specifying how long an object remains valid at a cache device, and the object is provided to the requesting device when the object is further determined to be valid based on the expiration time, or when the expiration time is reached or the current count value matches a limit value, a request is sent to revalidate the object.

[0108] 3. A computer-implemented method as described in Clause 1 or 2, wherein the object includes information identifying the first service endpoint.

[0109] 4. A computer-implemented method as described in any of Clauses 1-3, wherein the origin server sets the limit value based on the load reported by at least the first service endpoint.

[0110] 5. A computer-implemented method as described in any of Clauses 1-4, wherein a first service endpoint is included in a set of service endpoints, and the origin server sets a limit value based on one or more loads reported by each service endpoint included in the set of service endpoints.

[0111] 6. A computer-implemented method as described in any of Clauses 1-5, wherein the limit value is subtracted from a second limit value that is greater than the limit value, and the second limit value is associated with a second cache device that is the parent of the cache device.

[0112] 7. A computer-implemented method as described in any of Clauses 1-6, wherein the cache device receives a header from one of: (i) the origin server, or (ii) a second cache device that is the parent of the cache device.

[0113] 8. A computer-implemented method as described in any of Clauses 1-7, further comprising sending a second request to the object, wherein the second request includes the current count value.

[0114] 9. A computer-implemented method as described in any of Clauses 1-8, wherein the second request includes a re-verification request.

[0115] 10. A computer-implemented method as described in any of Clauses 1-9, wherein the second request includes a re-authentication token that identifies a first service endpoint for object identification when provided to the requesting device.

[0116] 11. In various embodiments, one or more non-transitory computer-readable media store instructions that, when executed by one or more processors, cause one or more processors to perform the following steps: receiving a header associated with an object, wherein the header includes a limit value specifying the number of times the object will be provided from a cache device prior to re-authentication, and a current count value specifying the number of times the object has been provided since the most recent re-authentication or load; receiving a request for the object from a requesting device; and, if it is determined that the current count value is below the limit value, providing the object from the cache device to the requesting device, or if it is determined that the current count value matches the limit value, sending a request to re-authenticate the object.

[0117] 12. One or more non-transitory computer-readable media as described in Clause 11, wherein the header further includes an expiration time specifying the time during which the object remains valid at the cache device, and the object is provided to the requesting device if the object is further determined to be valid based on the expiration time, or a request is sent to re-verify the object if the expiration time is reached or the current count value matches a limit value.

[0118] 13. One or more non-transitory computer-readable media as described in Clause 11 or 12, wherein the header further includes an edge limit indicating that an object will only be cached at the cache device when the cache device is at the edge of the network.

[0119] 14. One or more non-transitory computer-readable media as described in any of Clauses 11-13, further comprising instructions that, when executed by one or more processors, cause one or more processors to perform the steps of: determining that the requesting device is a client device, and, if the requesting device is a client device, incrementing the current count value before comparing the current count value with the limit value.

[0120] 15. One or more non-transitory computer-readable media as in any of Clauses 11-14, wherein the requesting device is a second cache device that is a child of the cache device.

[0121] 16. One or more non-transitory computer-readable media as in any of Clauses 11-15, wherein the object includes information identifying a first service endpoint included in a set of service endpoints, and the originating server sets a limit value based on one or more loads reported by each service endpoint included in the set of service endpoints.

[0122] 17. In various embodiments, a computing system includes a memory storing a storage controller application, and a processor coupled to the memory and performing the storage controller application by: receiving a header associated with an object, wherein the header includes a limit value specifying the number of times the object will be provided from a cache device prior to re-authentication, and a current count value specifying the number of times the object has been provided since the most recent re-authentication or load; receiving a request for the object from a requesting device; and, if it is determined that the current count value is below the limit value, providing the object from the cache device to the requesting device, or, if it is determined that the current count value matches the limit value, sending a request to re-authenticate the object.

[0123] 18. A computing system as described in Clause 17, wherein the header further includes an expiration time specifying how long an object remains valid at a cache device, and the object is provided to the requesting device when the object is further determined to be valid based on the expiration time, or when the expiration time is reached or the current count value matches a limit value, and a request is sent to revalidate the object.

[0124] 19. A computing system as described in Clause 17 or 18, wherein the object includes information identifying a first service endpoint included in a set of service endpoints, and the origin server sets a limit value based on one or more loads reported by each service endpoint included in the set of service endpoints.

[0125] 20. A computing system as described in any of Clauses 17-19, wherein the processor further performs the steps of: determining that the requesting device is a client device; and, if the requesting device is determined to be a client device, incrementing the current count value before comparing the current count value with the limit value.

[0126] Any and all combinations of any claim element recited in any claim and / or any element described in this application in any manner fall within the scope and protection of the contemplated invention.

[0127] The description of various embodiments is for illustrative purposes only and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments.

[0128] Aspects of the embodiments herein may be embodied as systems, methods, or computer program products. Therefore, aspects of this disclosure may take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or combined software and hardware embodiments that may be collectively referred to herein as “modules,” “systems,” or “computers.” Furthermore, any hardware and / or software techniques, processes, functions, components, engines, modules, or systems described in this disclosure may be implemented as circuits or collections of circuits. Additionally, aspects of this disclosure may take the form of computer program products embodied in one or more computer-readable media, on which computer-readable program code is embodied.

[0129] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (not an exhaustive list) of computer-readable storage media will include: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that may contain or store programs for use by or in connection with an instruction execution system, apparatus, or device.

[0130] The foregoing description of aspects of this disclosure includes flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to generate a machine. When executed via a processor of a computer or other programmable data processing apparatus, the instructions enable the implementation of the functions / actions specified in one or more blocks of the flowcharts and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable gate array (FPGA).

[0131] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing one or more specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, depending on the functions involved, two blocks shown consecutively may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system performing the specified functions or actions, or by a combination of dedicated hardware and computer instructions.

[0132] While the foregoing pertains to embodiments of this disclosure, other and additional embodiments of this disclosure may be devised without departing from its essential scope, the scope of which is defined by the appended claims.

Claims

1. A method implemented by a computer at a cache device, comprising: Receive a message associated with an object from an upstream device, the message including a header, wherein the header includes: Specify a limit on the number of times the object will be provided from the cache device before it is re-verified by the upstream device, and Specifies the current count of the number of times the object has been provided since the object was most recently re-verified or loaded by the upstream device; Receive a request for the object from the requesting device; and If it is determined that the current count value is lower than the limit value, the object is provided from the cache device to the requesting device, or If it is determined that the current count value matches the limit value, a request to re-verify the object is sent to the upstream device. The upstream device is either the origin server or a second cache device that is the parent of the cache device.

2. The computer-implemented method as described in claim 1, wherein: The header also includes an expiration time that specifies the duration for which the object remains valid on the cache device; and If the validity of the object is further determined based on the expiration time, the object is provided to the requesting device, or When the expiration time is reached or the current count value matches the limit value, the request is sent to the upstream device to re-verify the object.

3. The computer-implemented method as described in claim 1, wherein, The object includes information that identifies the first service endpoint.

4. The computer-implemented method as described in claim 3, wherein, The origin server sets the limit value based on the load reported by at least the first service endpoint.

5. The computer-implemented method as described in claim 4, wherein: The first service endpoint is included in a set of service endpoints, and The origin server sets the limit value based on one or more loads reported by each of the service endpoints included in the set of service endpoints.

6. The computer-implemented method as described in claim 1, wherein: The limit value is subtracted from a second limit value that is greater than the limit value, and The second limit value is associated with a second cache device that is the parent of the cache device.

7. The computer-implemented method of claim 1, further comprising sending a second request for the object to the upstream device, wherein the second request includes the current count value.

8. The computer-implemented method as described in claim 7, wherein, The second request includes a re-verification request for the object.

9. The computer-implemented method as described in claim 7, wherein, The second request includes a re-authentication token that identifies a first service endpoint of the object when provided to the requesting device.

10. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors at a cache device, cause the one or more processors to perform the following steps: Receive a message associated with an object from an upstream device, the message including a header, wherein the header includes: Specifies a limit on the number of times the object will be provided from the cache device before it is re-verified by the upstream device, and Specifies the current count of the number of times the object has been provided since the object was most recently re-verified or loaded by the upstream device; Receive a request for the object from the requesting device; and If it is determined that the current count value is lower than the limit value, the object is provided from the cache device to the requesting device, or If it is determined that the current count value matches the limit value, a request to re-verify the object is sent to the upstream device. The upstream device is either the origin server or a second cache device that is the parent of the cache device.

11. One or more non-transitory computer-readable media as claimed in claim 10, wherein: The header also includes an expiration time specifying the duration for which the object remains valid on the cache device; and If the validity of the object is further determined based on the expiration time, the object is provided to the requesting device, or When the expiration time is reached or the current count value matches the limit value, the request is sent to the upstream device to re-verify the object.

12. One or more non-transitory computer-readable media as claimed in claim 10, wherein, The header also includes an edge constraint that indicates that when the caching device is at the edge of the network, the object will only be cached at the caching device.

13. The one or more non-transitory computer-readable media of claim 10, further comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the following steps: It is determined that the requesting device is a client device; and If it is determined that the requesting device is a client device, the current count value is incremented before comparing the current count value with the limit value.

14. One or more non-transitory computer-readable media as claimed in claim 10, wherein, The requesting device is a second cache device that is a child of the cache device.

15. One or more non-transitory computer-readable media as claimed in claim 10, wherein: The object includes information identifying a first service endpoint included in a set of service endpoints; and The origin server sets the limit value based on one or more loads reported by each of the service endpoints included in the set of service endpoints.

16. A computing system at a cache device, comprising: The memory that stores the applications of the storage controller; as well as A processor, coupled to the memory, performs the memory controller application through the following steps: Receive a message associated with an object from an upstream device, the message including a header, wherein the header includes: Specifies a limit on the number of times the object will be provided from the cache device before it is re-verified by the upstream device, and Specifies the current count of the number of times the object has been provided since the object was most recently re-verified or loaded by the upstream device; Receive a request for the object from the requesting device; and If it is determined that the current count value is lower than the limit value, the object is provided from the cache device to the requesting device, or If it is determined that the current count value matches the limit value, a request to re-verify the object is sent to the upstream device. The upstream device is either the origin server or a second cache device that is the parent of the cache device.

17. The computing system of claim 16, wherein: The header also includes an expiration time specifying the duration for which the object remains valid on the cache device; and If the validity of the object is further determined based on the expiration time, the object is provided to the requesting device, or When the expiration time is reached or the current count value matches the limit value, the request is sent to the upstream device to re-verify the object.

18. The computing system of claim 16, wherein: The object includes information identifying a first service endpoint included in a set of service endpoints; and The origin server sets the limit value based on one or more loads reported by each of the service endpoints included in the set of service endpoints.

19. The computing system of claim 16, wherein, The processor also performs the following steps: It is determined that the requesting device is a client device; and If it is determined that the requesting device is a client device, the current count value is incremented before comparing the current count value with the limit value.

Images