Patent application number | Description | Published |
20090106411 | SCALABLE, HIGH PERFORMANCE AND HIGHLY AVAILABLE DISTRIBUTED STORAGE SYSTEM FOR INTERNET CONTENT - A method for content storage on behalf of participating content providers begins by having a given content provider identify content for storage. The content provider then uploads the content to a given storage site selected from a set of storage sites. Following upload, the content is replicated from the given storage site to at least one other storage site in the set. Upon request from a given entity, a given storage site from which the given entity may retrieve the content is then identified. The content is then downloaded from the identified given storage site to the given entity. In an illustrative embodiment, the given entity is an edge server of a content delivery network (CDN). | 04-23-2009 |
20100293229 | Highly scalable, fault tolerant file transport using vector exchange - A file transport mechanism according to the invention is responsible for accepting, storing and distributing files, such as configuration or control files, to a large number of field machines. The mechanism is comprised of a set of servers that accept, store and maintain submitted files. The file transport mechanism implements a distributed agreement protocol based on “vector exchange.” A vector exchange is a knowledge-based algorithm that works by passing around to potential participants a commitment bit vector. A participant that observes a quorum of commit bits in a vector assumes agreement. Servers use vector exchange to achieve consensus on file submissions. Once a server learns of an agreement, it persistently marks (in a local data store) the request as “agreed.” Once the submission is agreed, the server can stage the new file for download. | 11-18-2010 |
20110219108 | Scalable, high performance and highly available distributed storage system for Internet content - A method for content storage on behalf of participating content providers begins by having a given content provider identify content for storage. The content provider then uploads the content to a given storage site selected from a set of storage sites. Following upload, the content is replicated from the given storage site to at least one other storage site in the set. Upon request from a given entity, a given storage site from which the given entity may retrieve the content is then identified. The content is then downloaded from the identified given storage site to the given entity. In an illustrative embodiment, the given entity is an edge server of a content delivery network (CDN). | 09-08-2011 |
20120151016 | Content delivery network (CDN) content server request handling mechanism with metadata framework support - To serve content through a content delivery network (CDN), the CDN must have some information about the identity, characteristics and state of its target objects. Such additional information is provided in the form of object metadata, which according to the invention can be located in the request string itself, in the response headers from the origin server, in a metadata configuration file distributed to CDN servers, or in a per-customer metadata configuration file. CDN content servers execute a request identification and parsing process to locate object metadata and to handle the request in accordance therewith. Where different types of metadata exist for a particular object, metadata in a configuration file is overridden by metadata in a response header or request string, with metadata in the request string taking precedence. | 06-14-2012 |
20130007228 | Method and system for purging content from a content delivery network - A content file purge mechanism for a content delivery network (CDN) is described. A Web-enabled portal is used by CDN customers to enter purge requests securely. A purge request identifies one or more content files to be purged. The purge request is pushed over a secure link from the portal to a purge server, which validates purge requests from multiple CDN customers and batches the requests into an aggregate purge request. The aggregate purge request is pushed from the purge server to a set of staging servers. Periodically, CDN content servers poll the staging servers to determine whether an aggregate purge request exists. If so, the CDN content servers obtain the aggregate purge request and process the request to remove the identified content files from their local storage. | 01-03-2013 |
20130254247 | Scalable, high performance and highly available distributed storage system for Internet content - A method for content storage on behalf of participating content providers begins by having a given content provider identify content for storage. The content provider then uploads the content to a given storage site selected from a set of storage sites. Following upload, the content is replicated from the given storage site to at least one other storage site in the set. Upon request from a given entity, a given storage site from which the given entity may retrieve the content is then identified. The content is then downloaded from the identified given storage site to the given entity. In an illustrative embodiment, the given entity is an edge server of a content delivery network (CDN). | 09-26-2013 |
Patent application number | Description | Published |
20110173345 | Method and system for HTTP-based stream delivery - A method of delivering a live stream is implemented within a content delivery network (CDN) and includes the high level functions of recording the stream using a recording tier, and playing the stream using a player tier. The step of recording the stream includes a set of sub-steps that begins when the stream is received at a CDN entry point in a source format. The stream is then converted into an intermediate format (IF), which is an internal format for delivering the stream within the CDN and comprises a stream manifest, a set of one or more fragment indexes (FI), and a set of IF fragments. The player process begins when a requesting client is associated with a CDN HTTP proxy. In response to receipt at the HTTP proxy of a request for the stream or a portion thereof, the HTTP proxy retrieves (either from the archive or the data store) the stream manifest and at least one fragment index. Using the fragment index, the IF fragments are retrieved to the HTTP proxy, converted to a target format, and then served in response to the client request. The source format may be the same or different from the target format. Preferably, all fragments are accessed, cached and served by the HTTP proxy via HTTP. In another embodiment, a method of delivering a stream on-demand (VOD) uses a translation tier (in lieu of the recording tier) to manage the creation and/or handling of the IF components. | 07-14-2011 |
20110296048 | Method and system for stream handling using an intermediate format - A method of delivering a live stream is implemented within a content delivery network (CDN) and includes the high level functions of recording the stream using a recording tier, and playing the stream using a player tier. The step of recording the stream includes a set of sub-steps that begins when the stream is received at a CDN entry point in a source format. The stream is then converted into an intermediate format (IF), which is an internal format for delivering the stream within the CDN and comprises a stream manifest, a set of one or more fragment indexes (FI), and a set of IF fragments. The player process begins when a requesting client is associated with a CDN HTTP proxy. In response to receipt at the HTTP proxy of a request for the stream or a portion thereof, the HTTP proxy retrieves (either from the archive or the data store) the stream manifest and at least one fragment index. Using the fragment index, the IF fragments are retrieved to the HTTP proxy, converted to a target format, and then served in response to the client request. The source format may be the same or different from the target format. Preferably, all fragments are accessed, cached and served by the HTTP proxy via HTTP. | 12-01-2011 |
20140101758 | SERVER WITH MECHANISM FOR REDUCING INTERNAL RESOURCES ASSOCIATED WITH A SELECTED CLIENT CONNECTION - According to certain non-limiting embodiments disclosed herein, the functionality of a server is extended with a mechanism for identifying connections with clients that have exhibited attack characteristics (for example, characteristics indicating a DoS attack), and for transitioning internal ownership of those connections such that server resources consumed by the connection are reduced, while keeping the connection open. The connection thus moves from a state of relatively high resource use to a state of relatively low server resource use, and the server is able to free resources such as memory and processing cycles previously allocated to the connection. In some cases, the server maintains the connection for at least some time and uses it to keep the client occupied so that it cannot launch—or has fewer resources to launch—further attacks, and possibly to gather information about the attacking client. | 04-10-2014 |
20150040221 | SERVER WITH MECHANISM FOR CHANGING TREATMENT OF CLIENT CONNECTIONS DETERMINED TO BE RELATED TO ATTACKS - According to certain non-limiting embodiments disclosed herein, the functionality of a server is extended with a mechanism for identifying connections with clients that have exhibited attack characteristics (for example, characteristics indicating a DoS attack), and for transitioning internal ownership of those connections such that server resources consumed by the connection are reduced, while keeping the connection open. The connection thus moves from a state of relatively high resource use to a state of relatively low server resource use. According to certain non-limiting embodiments disclosed herein, the functionality of a server is extended by enabling the server to determine that any of a client and a connection exhibits one or more attack characteristics (e.g., based on at least one of client attributes, connection attributes, and client behavior during the connection, or otherwise). As a result of the determination, the server changes its treatment of the connection. | 02-05-2015 |