Multi-tier storage for delivery of services

Methods, systems, and computer readable media can be operable to facilitate the transfer of content between two or more storage units. The transfer of content between two or more storage units can be based upon a count of the number of hits to a storage unit entry associated with the content. In embodiments, the transfer of content between two or more storage units can be further based upon a predetermined threshold associated with a period.

TECHNICAL FIELD

This disclosure relates to providing a multi-tier storage system for delivery of services.

BACKGROUND

The advent of centric delivery solutions places an increasing value on high-throughput, high-density caching servers because of high network and storage demands. This increasing demand presents a challenge to develop storage based on fast, dense, reliable, and inexpensive storage systems. Currently, there is no storage medium that sufficiently meets all of these requirements. Random access memory (RAM) is fast but capacity-limited and very expensive; hard disk drives (HDDs) are high capacity and inexpensive, but slow; flash-based solid-state drives (SSDs) are relatively fast and moderately high-capacity, but very expensive, particularly the single-level-cell type that can support write traffic of a typical storage. Therefore, an improvement to data caching is desired, wherein the improvement can meet high-throughput and high-capacity needs at a low cost.

DETAILED DESCRIPTION

Methods, systems, and computer readable media can be operable to facilitate the transfer of content associated with, or stored within a storage unit entry (e.g., data associated with content such as information, video, audio, etc.) between two or more storage units. For example, a storage unit entry can include data corresponding with stored content and identification data and/or history field (e.g., data that serves to identify and/or indicate a status of the content stored within the storage unit entry). A storage unit can include a storage (e.g., SSD, HDD, etc.), a memory, a cache, or any other component that is operable to store data, and a storage unit entry can be a location for storing data within a storage unit. The transfer of content between two or more storage units can be based upon a count of the number of hits to the storage unit entry, or the number of requests for the content associated with the storage unit entry. In embodiments, the transfer of content between two or more storage units can be further based upon a predetermined threshold associated with a period.

Systems and methods of this disclosure can operate to implement a multi-tier storage using a mixture of storage components to achieve storage efficiencies while reducing costs. In embodiments, a multi-tier storage can produce higher streaming densities at lower costs than existing storage components used alone, thereby yielding a storage solution that simultaneously meets the goals of high throughput (e.g., rate of data reception/input or delivery/output), high density, and low cost. For example, a server (e.g., a video-on-demand server) can include a primary storage unit for storing content that is frequently requested and a secondary storage unit for storing content that is less frequently requested. The primary storage unit can be a storage medium that has a high throughput capability (e.g., SSD), and the secondary storage unit can be a storage medium that has a high storage capacity (e.g., HDD), thereby providing the server with greater bandwidth or throughput with which to provide popular content as well as greater storage capacity with which to store less-popular content.

In embodiments, a method can be used to ascertain the dynamic popularity of content associated with a storage unit entry by introducing a time-bounded popularity method. In embodiments, this method can introduce a rolling period window whereby content can be transferred from one storage unit to another when a play count (e.g., a count of the number of times a storage unit entry or content associated with the storage unit entry is requested) exceeds a transfer threshold. The rolling period window approach can be tuned by configuring various parameters (e.g., the number of periods for which to retain information, the length of each period, a transfer threshold defining a maximum number of storage unit entry hits over a period of time before the content is transferred from one storage unit to another).

In embodiments, a period can be defined in terms of total play requests to respond to traffic variations. In such embodiments, a rolling total play requests can be used to form a dynamic total play requests window, and this window can be adjusted according to traffic and/or storage unit behavior. It should be understood that this approach can be used in place of, in addition to, or in conjunction with a rolling time period counter approach.

FIG. 1is a block diagram illustrating an example network environment100operable to provide multi-tier storage for delivery services. One or more client devices105a-c(e.g., computer105a, mobile device or tablet105b, internet protocol (IP) television105c, etc.) can be connected to a customer premise equipment (CPE) device110a-b(e.g., modem110a, gateway110b, etc.). In embodiments, CPE devices110a-bcan be connected to a content distribution network115.

In embodiments, client device(s)105a-ccan communicate with one or more content delivery networks120via a connection to a content distribution network115. For example, client device(s)105a-ccan request content (e.g., data, video, etc.) from a content server125by transmitting a request to a content distribution network115, and the request can be routed from to the content server125via a content delivery network120. In embodiments, the content distribution network115can take the form of an all-coaxial, all-fiber, hybrid fiber-coaxial (HFC) network, an over-the-air network, a telephone network, for example, among many others. It should be understood that the content server125can represent a local content server at a headend (e.g., a cable modem termination system) or can be provided by a service provided via a connection to the content delivery network(s)120. In embodiments, content from the content server125can be delivered to a CPE device110a-bthrough a content delivery network120or a content distribution network115. It should be understood that content from the content server125can be delivered directly to a client device105a-cthrough a content distribution network115.

In embodiments, content stored on the content server125can be processed using various mechanisms. For example, video content stored on the content server125can be processed using either an MPEG-2 or an MPEG-4 coder-decoder (CODEC) to produce an MPEG transport stream. The MPEG transport stream can then be transmitted by the content server125to a client device105a-cover a content distribution network115and/or a content delivery network120. In embodiments, the MPEG transport stream can be converted to a signal that can be transported through a content distribution network115and/or a content delivery network120.

In embodiments, the content server125can include a plurality of storage units. In embodiments, an initial storage unit load can be implemented to increase performance of the content server125. In such embodiments, the peak-miss and write loads can be avoided when a storage unit within the content server125is empty, or near empty. In embodiments, controlled pre-placement of content (e.g., cache-warming), managed pacing of pull-thru into empty storage units, avoidance of storage unit restarts during primetime, and/or other approaches can be used in conjunction with multi-tier storage methods.

In embodiments, content included within the content server125can be managed by a content manager130. The content manager130can be operable to allocate node capacity (e.g., capacity of the content server125) to content objects. In embodiments, the allocation can be based on a best-fit, random, or hybrid allocation process. In embodiments, the content manager130can be further operable to select nodes for streaming and failover based upon requests received from any of the client devices105a-c. In embodiments, the content manager130can also identify instances of exceptional asymmetries in content allocation and/or use of streaming resources and demand for scaling the allocated resources. In embodiments, the content manager130and content server125can reside in the same physical server.

FIG. 2is a block diagram illustrating an example content server125operable to provide multi-tier storage for delivery services. In embodiments, the content server125can include a network interface210, a primary storage unit220, a secondary storage unit230, and a transfer module240. In embodiments, a network interface210can be used to receive an inquiry for a storage unit entry within the content server125. In embodiments, the network interface210can be used to output data associated with a storage unit entry (e.g., storage unit entries A-F). In embodiments, the network interface210can be used to input data to be stored within the content server125. It should be understood that the network interface210can be implemented as multiple interfaces.

In embodiments, a primary storage unit220can store a plurality of storage unit entries (e.g., storage unit entries A-C). The plurality of storage unit entries that are stored within the primary storage unit220can be storage unit entries that are frequently requested. In embodiments, the primary storage unit220can be smaller and faster than a secondary storage unit230. For example, the primary storage unit220can provide for efficient access to more popular content or more frequently requested content. In embodiments, the primary storage unit220can be a solid-state drive (SSD). It should be understood that the primary storage unit220can include various storage mediums (e.g., data cache, static memory, hard disk, flash memory, etc.).

In embodiments, a secondary storage unit230can store a plurality of storage unit entries (e.g., storage unit entries D-F). The plurality of storage unit entries that are stored within the secondary storage unit230can comprise storage unit entries that are associated with data that is requested by a client device110a-cofFIG. 1. For example, each secondary storage unit entry can include data corresponding with requested content and a history field that can store and update information associated with the requested content (e.g., a number of times the content has been requested). In embodiments, the secondary storage unit230can be used to store data or storage unit entries associated with content that is less popular or less frequently accessed than content stored in the primary storage unit220. For example, when a secondary storage unit230is full, data that is associated with content that is requested by a client device110a-c, or otherwise new data, can be inserted into the secondary storage unit as a most-recently used (MRU) entry, and a least-recently used (LRU) entry can be discarded from the secondary storage unit. In embodiments, miss data can be added to the secondary storage unit230. In embodiments, the secondary storage unit230can be a hard disk drive (HDD). It should be understood that the secondary storage unit230can include various storage mediums (e.g., data cache, static memory, hard disk, flash memory, etc.).

In embodiments, when content is inserted into the secondary storage unit230, the activity history associated with the content can be set or reset. For example, when content is inserted into the secondary storage unit230, the activity history of the content can be updated to include the most recent time at which the content or a storage unit entry associated with the content was hit. As another example, when content is inserted into the secondary storage unit230, the activity history of the content can be set or reset so that the activity history indicates that the content or a storage unit entry associated with the content has received no hits. In embodiments, the activity history of content, such as the number of times the content is hit or requested (e.g., content associated with a storage unit entry is requested by a client device), can be maintained within a server (e.g., content server125) or data store as a play count. In embodiments, when content is inserted into the secondary storage unit230, the activity history of the content can be retrieved from a server or data store and can be included as a history field in a count tag associated with the content. For example, the play count for content can be set to the most recent play count value associated with the content or a storage unit entry associated with the content. In embodiments, the activity history for content can be periodically reset. For example, the play count for content can be maintained for a predetermined period of time (e.g., in a server or data store) and then reset or attenuated (e.g., scaled down) upon the expiration of the predetermined period of time. In embodiments, a secondary storage unit entry can include a count tag, wherein the count tag comprises one or more period counters. When content is inserted into the secondary storage unit, period counters associated with the storage unit entry can be set to indicate that the content has yet to be hit more than once, or that the content has been hit once during the current period. It should be understood that period counters associated with a storage unit entry can be stored at a server or data store.

In embodiments, a transfer module240can compare an activity history associated with content stored in the secondary storage unit230to a predetermined threshold. For example, a piece of content's activity history can include a variety of information that serves to indicate a number of times that the content or a storage unit entry associated with the content has been hit and/or the times at which the storage unit entry has been hit. In embodiments, a piece of content's activity history can be maintained as a count tag associated with the content. For example, a storage unit entry's count tag can be updated and/or incremented each time content associated with the storage unit entry is hit, thus maintaining a count of the number of times the content is hit and/or an identification of the time at which the content was hit. In embodiments, a piece of content's activity history can be maintained in a data store, and a tag associated with the content can point to the stored activity history. In embodiments, if a hit to a secondary storage unit entry (e.g., storage unit entries D-F) pushes that storage unit entry's activity history (could be as simple as a play count) beyond a predetermined transfer threshold, content associated with the storage unit entry can be transferred to the primary storage unit220.

In embodiments, a transfer module240can transfer content from the secondary storage unit230to the primary storage unit220. For example, when an activity history associated with a secondary storage unit entry (e.g., storage unit entries D-F) reaches a predetermined threshold, the transfer module240can write the content of the secondary storage unit entry to the primary storage unit220. In embodiments, after the content is written to the primary storage unit220, the content can be removed from the secondary storage unit entry. For example, the content can become the MRU entry of the primary storage unit220. In embodiments, when content is transferred to the primary storage unit220, a LRU entry within the primary storage unit can be transferred from the primary storage unit to the secondary storage unit. For example, the LRU entry of the primary storage unit can become the MRU entry of the secondary storage unit230, and the activity history associated with the storage unit entry can be reset. The migration of a LRU block from the primary storage unit back into the secondary storage unit allows the storage unit entry to continue to be hit unless or until it eventually falls out the bottom of the secondary storage unit, while also providing the opportunity for the content associated with the storage unit entry to be transferred back to the primary storage unit if warranted.

FIG. 3is a flowchart illustrating an example process300for operating a multi-tier storage for delivery services. In embodiments, a play count associated with a storage unit entry can be compared to a transfer threshold. For example, when a secondary storage unit entry is hit, a play count associated with the secondary storage unit entry can be incremented, and if the play count eventually meets a transfer threshold, then the content associated with the secondary storage unit entry can be transferred to a primary storage unit. The process300can start at310where a transfer threshold is initialized for a secondary storage unit. In embodiments, the transfer threshold can be a fixed number. In embodiments, the transfer threshold can be variable based upon factors such as, for example, a capacity or load associated with a content server125ofFIG. 1, a capacity or load associated with a content distribution network115ofFIG. 1, the amount of traffic that is expected for a storage unit, the type of content or data stored within the storage unit, among many other factors. In embodiments, to avoid a slow ramp to steady-state behaviors, it can be beneficial to begin with a low transfer threshold (e.g. one (1) play for insertion into a secondary storage unit section of the server and one (1) hit for transfer into the primary storage unit section) until the respective storage units are mostly full, at which point the transfer threshold can be raised to the desired level. It should be understood that such caching improvements can be used in conjunction with the multi-tier storage methods described herein.

At320, a storage unit entry hit to a storage unit entry that is within a secondary storage unit (e.g., secondary storage unit230ofFIG. 2) can be received. In embodiments, a storage unit entry hit can be the reception of a request for content or data that is associated with the storage unit entry by a server (e.g., content server125ofFIG. 1).

At330, a play count associated with the storage unit entry for which a hit is received can be incremented. In embodiments, a count tag associated with the storage unit entry can be updated to reflect the hit to the storage unit entry. For example, each storage unit entry can include a count tag that indicates the number of times the corresponding storage unit entry has been hit or the number of times the content associated with the storage unit entry has been requested. When a secondary storage unit entry is hit, the number that is indicated by the count tag of the storage unit entry can be incremented to account for the hit. In embodiments, an activity history associated with a storage unit entry or the content associated with the storage unit entry can be maintained, for example, within a server or data store. When the secondary storage unit entry is hit, the activity history associated with the storage unit entry can be updated to account for the hit.

At340, a determination can be made whether the transfer threshold has been met by the storage unit entry that is hit. In embodiments, the activity history, or current play count, associated with the hit storage unit entry can be compared to the transfer threshold. For example the activity history, or play count associated with the storage unit entry can indicate a number of times that the storage unit entry has been hit, and this number can be compared to the transfer threshold. If the activity history, or play count, associated with the storage unit entry is less than, or in some cases equal to, the transfer threshold, the determination can be made that the transfer threshold has not been met and the process300can return to320. If the activity history, or play count associated with the storage unit entry is greater than, or in some cases equal to the transfer threshold, the determination can be made that the transfer threshold has been met and the process300can proceed to350.

At350, the content associated with the storage unit entry for which the transfer threshold has been met can be transferred from the secondary storage unit to a primary storage unit (e.g., primary storage unit220ofFIG. 2). In embodiments, a transfer module240ofFIG. 2can write the content of the secondary storage unit entry to the primary storage unit220. In embodiments, after the content is written to the primary storage unit220, the content can be removed from the secondary storage unit entry. For example, the content can become the MRU entry of the primary storage unit220. In embodiments, when content is transferred to the primary storage unit220, a LRU entry within the primary storage unit can be transferred from the primary storage unit to the secondary storage unit. For example, the LRU entry of the primary storage unit can become the MRU entry of the secondary storage unit230, and the activity history associated with the storage unit entry can be reset.

FIG. 4is a flowchart illustrating an example process400for operating a multi-tier storage using a rolling period window. The process400can start at405where a transfer threshold is initialized for a secondary storage unit. In embodiments, the transfer threshold can be a fixed number. In embodiments, the transfer threshold can be variable based upon factors such as, for example, a capacity or load associated with a content server125ofFIG. 1, a capacity or load associated with a content distribution network115ofFIG. 1, the amount of traffic that is expected for a storage unit, the type of content or data stored within the storage unit, among many other factors. In embodiments, the transfer threshold can be associated with a period of time. For example, the period of time can be a fixed length of time, or the period of time can be dynamic based upon factors such as, for example, total accessed block or CPU load. In embodiments, the period of time can be adjusted by altering the number of period counters maintained within an activity history, or count tag of a storage unit entry (e.g., the activity history can include 3, 4, 5, or any other number of period counters in order to maintain a count of content requests for a desired period of time), and/or by altering the length of time associated with a period (e.g., each period counter can maintain a count of content requests for a number of minutes, a number of hours, a number of days, or any other predetermined period of time).

At410, a hit to a secondary storage unit entry can be received. In embodiments, a storage unit entry hit can be the reception of a request for content associated with the storage unit entry by a server (e.g., content server125ofFIG. 1).

At415, the period of the storage unit entry's last hit can be identified. In embodiments, rolling period counters can be kept for entries in the secondary storage unit (e.g., secondary storage unit230ofFIG. 2), and can be accessed and/or updated when a corresponding storage unit entry is hit. In embodiments, a storage unit entry can include a count tag, and the count tag can include one or more period counters. In embodiments, the period associated with each period counter can be fixed or can be dynamic based upon factors such as, for example, capacity and/or load of a server or a network. Each period counter can indicate and/or include the number of hits to the storage unit entry during a specific period of time. In embodiments, each period counter can be associated with a predetermined maximum number of storage unit requests (e.g., each period counter can be maintained over a predetermined range of requests). For example, each time a storage unit entry is hit, the current period counter can be incremented, and when the number of storage unit requests reaches the predetermined maximum number for the current period, the oldest period counter can be discarded, each of the remaining period counters can be shifted, and a new period counter can be inserted into the corresponding count tag. In embodiments, the number of period counters included in a count tag can be varied and can be based upon many different factors. In embodiments, the first period counter of the plurality of period counters in the count tag can indicate the period of the storage unit entry's last hit. In embodiments, the period counter can also indicate the number of times the storage unit entry was hit during said period of time.

At420, a determination can be made whether the current period is the same as the period of the storage unit entry's last hit. For example, the period of the storage unit entry's last hit can be identified from the newest period counter of a count tag associated with the storage unit entry or from another data store or server, and the identified period of the storage unit entry's last hit can be compared to a current period. In embodiments, a current period can be maintained within a content server125(e.g., at transfer module240ofFIG. 2).

If, at420, the determination is made that the current period is the same as the period of the storage unit entry's last hit, the process400can proceed to425. At425, a play count associated with the current period can be updated for the storage unit entry. In embodiments, a count tag associated with the storage unit entry can be updated to reflect the hit to the storage unit entry. For example, the period counter corresponding with the current period (e.g., the newest period counter of the storage unit entry's count tag) can be incremented to account for the hit to the storage unit entry. In embodiments, an activity history associated with a storage unit entry can be maintained, for example, within a server or data store. When the secondary storage unit entry is hit, the activity history associated with the storage unit entry can be updated to account for the hit. For example, the activity history associated with the storage unit entry can be updated to reflect that an additional hit has been made to the storage unit entry during the current period.

Returning to420, if the determination is made that the current period is not the same as the period of the storage unit entry's last hit, the process400can proceed to430. At430, the period counters of the storage unit entry can be shifted according to the difference between the period of the storage unit entry's last hit and the current period. In embodiments, counts for a predetermined number of periods can be maintained within a count tag for each storage unit entry, and the periods can include the last period in which the storage unit entry was hit as well as a number of periods that chronologically precede the last period in which the storage unit entry was hit. It should be understood, that one or more of the period counters for a storage unit entry can be empty (e.g., where the storage unit entry was not hit during the corresponding period). In embodiments, the difference between the current period and the last period in which the storage unit entry was hit can indicate how many of the storage unit entry's period counters are to be discarded and replaced with empty period counters. For example, the number of period counters that are to be discarded and replaced with empty counters can be equivalent to the difference between the current period and the last period in which the storage unit entry was hit, and one of the new, empty counter can correspond with the current period. In embodiments, empty period counters can replace discarded period counters, period counters that are not discarded can be shifted to the end of the count tag, and the period counter that is now at the beginning of the count tag can correspond with the current period. The following is an example shift that can take place where the period length is five (5) minutes, the number of period counters retained in a count tag is five (5), and the difference in start times between the current period and the last period in which the storage unit entry was hit is fifteen (15) minutes: the number of period counters to be discarded would be equal to the start-time difference between periods, fifteen (15), divided by the period length, five (5), and, therefore, the three (3) oldest period counters of the count tag would be discarded, the newest period counter would be shifted to the next-to-last spot in the count tag, and three (3) empty period counters corresponding with the three (3) periods between the last period of a hit and the current period (current period inclusive) would be added to the count tag, with the first counter (now empty counter) now corresponding to the current period.

At435, one or more new period counters can be inserted at the beginning of the storage unit entry's count tag to replace the discarded counters or the counters that were shifted out. In embodiments, the newest period counter (e.g., the first counter in the count tag) can correspond with the current period. After the one or more new period counters are inserted, the process400can proceed to425.

At440, a sum of the play counts associated with each period counter of the storage unit entry can be calculated. In embodiments, each period counter within a count tag can indicate the number of times the storage unit entry was hit during a corresponding period. The play counts of each of the period counters can be added together to calculate a total number of times the storage unit entry was hit over the period of time covered by the period counters in combination. For example, where each period counter accounts for a five (5) minute period, and a count tag maintains a maximum of five (5) period counters, the number of times the storage unit entry was hit over the last twenty to twenty-five (25) minutes (as low as twenty depending on the current position within the current period) can be calculated by summing the play counts of each of the period counters. In embodiments, the number of period counters maintained within a count tag can be varied to account for larger or smaller periods of time. In embodiments, the time associated with each period counter can be varied to account for larger or smaller periods of time.

At445, a determination can be made whether the predetermined threshold has been met at the hit storage unit entry. In embodiments, the sum of the play counts of each of the period counters associated with the storage unit entry can be compared to the predetermined threshold. If the sum of the play counts is less than, or in some cases equal to, the predetermined threshold, the determination can be made that the predetermined threshold has not been met and the process400can return to410. In embodiments, the updated activity information (e.g., the updated period counters) for the secondary storage unit entry can be stored until the secondary storage unit entry is hit again at410.

If, at445, the determination is made that the sum of the play counts of each of the period counters associated with the storage unit entry is greater than, or in some cases equal to, the predetermined threshold, the determination can be made that the predetermined threshold has been met and the process400can proceed to450. At450, the content associated with the storage unit entry for which the predetermined threshold has been met can be transferred from the secondary storage unit (e.g., secondary storage unit230ofFIG. 2) to a primary storage unit (e.g., primary storage unit220ofFIG. 2). In embodiments, after the content is written to the primary storage unit220, the content can be removed from the secondary storage unit entry. For example, the content can become the MRU entry of a primary storage unit220. In embodiments, when content is transferred to the primary storage unit220, a LRU entry within the primary storage unit can be transferred from the primary storage unit to the secondary storage unit230. For example, the LRU entry of the primary storage unit can become the MRU entry of the secondary storage unit230, and the activity history associated with the storage unit entry can be reset.

FIG. 5is a block diagram illustrating an example hardware configuration500operable to provide multi-tier storage for delivery services. While a content server125is shown, it should be understood that many different kinds of network devices can implement a multi-tier storage for delivery services. The configuration500can include a processor510, a memory520, a primary storage unit530, a secondary storage unit540, and an input/output device550. Each of the components510,520,530,540and550can, for example, be interconnected using a system bus560. The processor510is capable of processing instructions for execution within the configuration500. In one implementation, the processor510is a single-threaded processor. In another implementation, the processor510is a multi-threaded processor. The processor510is capable of processing instructions stored in the memory520or on the storage device storage units530or540.

The memory520stores information within the configuration500. In one implementation, the memory520is a computer-readable medium. In one implementation, the memory520is a volatile memory unit. In another implementation, the memory520is a non-volatile memory unit.

In some implementations, the storage device storage units530and540are capable of providing mass storage within the configuration500. In one implementation, the storage device storage units530and540are a computer-readable medium. In various different implementations, the storage device storage units530and540can, for example, include a hard disk device, an optical disk device, flash memory, random-access memory, or some other large capacity storage device. It should be understood that more storage units can be available in addition to the primary storage unit530and secondary storage unit540.

The input/output device550provides input/output operations for the configuration500. In some implementations, the input/output device550can include one or more of a plain old telephone interface (e.g., an RJ11 connector), a network interface device (e.g., an Ethernet card), a serial communication device (e.g., RS-232 port), and/or a wireless interface device (e.g., 802.11 card). In additional and/or other implementations, the input/output device can include driver devices configured to receive input data and send output data to other input/output devices, such as one or more client devices105a-cofFIG. 1, as well as sending communications to, and receiving communications from one or more networks (e.g., content delivery network(s)120ofFIG. 1, content distribution network(s)115ofFIG. 1, etc.). Other implementations, however, can also be used, such as mobile computing devices, mobile communication devices, set-top box television client devices, etc.

Those skilled in the art will appreciate that the invention improves upon methods and apparatuses for implementing a multi-tiered storage unit within a server. Methods, systems, and computer readable media can be operable to facilitate the transfer of content associated with storage unit entries between two or more storage units. The transfer of content between two or more storage units can be based upon a count of the number of hits to the storage unit entry. In embodiments, the transfer of content between two or more storage units can be further based upon a predetermined threshold associated with a period.

The subject matter of this disclosure, and components thereof, can be realized by instructions that upon execution cause one or more processing devices to carry out the processes and functions described above. Such instructions can, for example, comprise interpreted instructions, such as script instructions, e.g., JavaScript or ECMAScript instructions, or executable code, or other instructions stored in a computer readable medium.

Particular embodiments of the subject matter described in this specification have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results, unless expressly noted otherwise. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some implementations, multitasking and parallel processing may be advantageous.