Abstract: Provided is an unobtrusive client verification system with one verification devices having processors that are configured to receive a first request from an unverified client device, generate a random number in response to receiving the first request from the unverified client device, define a set of expressions as a browser challenge problem that evaluates to an answer specified by the random number, encrypt the answer within an answer token, provide the browser challenge problem with the answer token to the unverified client device, receive a second request with a solution to the browser challenge problem and the answer token from the unverified client device, and verify the unverified client device in response to the solution matching the answer that is decrypted from the answer token provided with the second request.

Abstract: Provided is an Adaptive Network Security System (“ANSS”) that receives a first set of network data, detects commonality in a set of parameters within the first set of network data using an unsupervised machine learning technique, and models an expected behavior based on the commonality in the set of parameters. The ANSS may determine a threat risk associated with a second set of network data based on an amount of deviation between the set of parameters from the second plurality of network data and the expected behavior, and may perform a particular action from different actions against the second set of network data in response to the set of parameters from the second set of network data deviating from the expected behavior and the threat risk.

Abstract: Provided is an unobtrusive client verification system with one verification devices having processors that are configured to receive a first request from an unverified client device, generate a random number in response to receiving the first request from the unverified client device, define a set of expressions as a browser challenge problem that evaluates to an answer specified by the random number, encrypt the answer within an answer token, provide the browser challenge problem with the answer token to the unverified client device, receive a second request with a solution to the browser challenge problem and the answer token from the unverified client device, and verify the unverified client device in response to the solution matching the answer that is decrypted from the answer token provided with the second request.

Abstract: Provided is a controller for dynamically balancing load between different servers using different thresholds that are continually modified for each of the servers. The controller may generate a baseline load measure based on load measures received from the different servers, and may configure a first threshold for a first server and a second threshold for a second server based on the load measure at the first server deviating from the baseline load measure by a first amount that is greater than a second amount by which the load measure at the second server deviates from the baseline load measure. The controller may allocate an additional server to distribute first content with the first server in response to first content load at the first server satisfying the first threshold and the same load or a greater load of second content at the second server not satisfying the second threshold.

Abstract: A network firewall detects and protects against persistent low volume attacks based on a sequence of network data having a pattern that matches by some threshold or percentage a sequence of network data from an earlier iteration of the same persistent low volume attack. The attack patterns are derived from tokenizing one or more elements from a captured sequence of network data that is representative of an attack iteration. Counts for different resulting tokens may be stored in a feature vector that represents the attack pattern. If subsequent sequences of network data have a sufficient number of similar token, a pattern match can be identified and the firewall can take protective action including blacklisting the sending clients, blocking the traffic, redirecting the traffic, sending a problem to verify the sender is an actual user, or other actions.

Abstract: Provided is an unobtrusive client verification system with one verification devices having processors that are configured to receive a first request from an unverified client device, generate a random number in response to receiving the first request from the unverified client device, define a set of expressions as a browser challenge problem that evaluates to an answer specified by the random number, encrypt the answer within an answer token, provide the browser challenge problem with the answer token to the unverified client device, receive a second request with a solution to the browser challenge problem and the answer token from the unverified client device, and verify the unverified client device in response to the solution matching the answer that is decrypted from the answer token provided with the second request.

Abstract: A Multi-Threaded Indexed (“MTI”) file system may use a first set of threads, processes, or executable instances to index desired file attributes in a database while simultaneously but independently executing file operations with a second set of threads, processes, or executable instances. In response to receiving a file operation, the second set of threads, processes, or executable instance may query the database to directly identify files that are indirectly implicated by the file operation with a wildcard, regular expression, and/or other expression that indirectly identifies the files based on different file attributes, paths, name expressions, or combinations thereof. The second set of threads, processes, or executable instances are therefore able to identify the files implicated by the file operation based solely on the indexed file attributes already entered in the database without the need to load and scan the metadata of files in directories targeted by the file operation.

Abstract: Provided is a controller for dynamically balancing load between different servers using different thresholds that are continually modified for each of the servers. The controller may generate a baseline load measure based on load measures received from the different servers, and may configure a first threshold for a first server and a second threshold for a second server based on the load measure at the first server deviating from the baseline load measure by a first amount that is greater than a second amount by which the load measure at the second server deviates from the baseline load measure. The controller may allocate an additional server to distribute first content with the first server in response to first content load at the first server satisfying the first threshold and the same load or a greater load of second content at the second server not satisfying the second threshold.

Abstract: A controller may identify a problematic path from several paths over which to route egress traffic from a site, may determine a threshold amount of traffic to shift from the problematic path, and may implement different potential traffic shifts for shifting similar amounts of traffic as the threshold amount. The controller may provide the labels or header values that different nodes in the site may place in the egress traffic in order to control which path is used to distributed that egress traffic. The controller may modify routing policies affecting different Autonomous System numbers, address prefixes, or other routing parameters to select and/or shift egress traffic, that is associated with those routing parameters and that is about equal to the threshold amount of traffic, from the problematic path to a different path.

Abstract: A controller may identify a problematic path from several paths over which to route egress traffic from a site, may determine a threshold amount of traffic to shift from the problematic path, and may implement different potential traffic shifts for shifting similar amounts of traffic as the threshold amount. The controller may provide the labels or header values that different nodes in the site may place in the egress traffic in order to control which path is used to distributed that egress traffic. The controller may modify routing policies affecting different Autonomous System numbers, address prefixes, or other routing parameters to select and/or shift egress traffic, that is associated with those routing parameters and that is about equal to the threshold amount of traffic, from the problematic path to a different path.

Abstract: Hybrid pull and push based streaming selectively performs a pull-based distribution of a stream to a first point-of-presence (“PoP”) of a distributed platform having low demand for the stream, and a push-based distribution of the stream to a second PoP of the distributed platform having high demand for the stream. The push-based distribution may be used to prepopulate the second PoP cache with the live stream data as the live stream data is uploaded from an encoder to a source PoP of the distributed platform, and before that live stream data is requested by the second PoP. In doing so, requests for the live stream data received at the second PoP may result in cache hits with the requested live stream data being immediately served from the second PoP cache without having to retrieve the live stream data from outside the second PoP.

Abstract: Provided is a controller for dynamically balancing load between different servers using different thresholds that are continually modified for each of the servers. The controller may generate a baseline load measure based on load measures received from the different servers, and may configure a first threshold for a first server and a second threshold for a second server based on the load measure at the first server deviating from the baseline load measure by a first amount that is greater than a second amount by which the load measure at the second server deviates from the baseline load measure. The controller may allocate an additional server to distribute first content with the first server in response to first content load at the first server satisfying the first threshold and the same load or a greater load of second content at the second server not satisfying the second threshold.

Abstract: A network firewall detects and protects against persistent low volume attacks based on a sequence of network data having a pattern that matches by some threshold or percentage a sequence of network data from an earlier iteration of the same persistent low volume attack. The attack patterns are derived from tokenizing one or more elements from a captured sequence of network data that is representative of an attack iteration. Counts for different resulting tokens may be stored in a feature vector that represents the attack pattern. If subsequent sequences of network data have a sufficient number of similar token, a pattern match can be identified and the firewall can take protective action including blacklisting the sending clients, blocking the traffic, redirecting the traffic, sending a problem to verify the sender is an actual user, or other actions.

Abstract: A Multi-Threaded Indexed (“MTI”) file system may use a first set of threads, processes, or executable instances to index desired file attributes in a database while simultaneously but independently executing file operations with a second set of threads, processes, or executable instances. In response to receiving a file operation, the second set of threads, processes, or executable instance may query the database to directly identify files that are indirectly implicated by the file operation with a wildcard, regular expression, and/or other expression that indirectly identifies the files based on different file attributes, paths, name expressions, or combinations thereof. The second set of threads, processes, or executable instances are therefore able to identify the files implicated by the file operation based solely on the indexed file attributes already entered in the database without the need to load and scan the metadata of files in directories targeted by the file operation.

Abstract: A server distributing a stream to a client device may use server-side metrics to detect issues that interrupt or otherwise affect playback of the stream by the client device. The server reproduces the issues experienced by the client device from the server-side metrics without accessing or using client-side metrics. The server-side metrics may include data that may be produced or obtained by the server such as requested stream segment filenames that identify changes in the stream bitrate, and timestamps at which the client device requests different segments. The client-side metrics may include metrics that are produced by the client device, and that directly identify the same client-side issues the server reproduces via the server-side metrics. The server or a distributed platform in which the server operates may dynamically alter the delivery of the stream or perform other remedial actions if the server detects various client-side issues from the server-side metrics.

Abstract: The solution distributes the management of stream segments from a central storage cluster to different edge servers that upload stream segments to and receive stream segments from the central storage cluster. Each edge server tracks the stream segments it has uploaded to the central storage cluster as well as the expiration times for those segments. The tracking is performed without a database using a log file and file system arrangement. First-tier directories are created in the file system for different expiration intervals. Entries under the first-tier directories track individual segments that expire within the expiration interval of the first-tier directory with the file system entries being files or a combination of subdirectories and files. Upon identifying expired stream segments, the edge servers instruct the central storage cluster to delete those stream segments. This removes the management overhead from the central storage cluster and implements the distributed management without a database.

Abstract: A network firewall detects and protects against persistent low volume attacks based on a sequence of network data having a pattern that matches by some threshold or percentage a sequence of network data from an earlier iteration of the same persistent low volume attack. The attack patterns are derived from tokenizing one or more elements from a captured sequence of network data that is representative of an attack iteration. Counts for different resulting tokens may be stored in a feature vector that represents the attack pattern. If subsequent sequences of network data have a sufficient number of similar token, a pattern match can be identified and the firewall can take protective action including blacklisting the sending clients, blocking the traffic, redirecting the traffic, sending a problem to verify the sender is an actual user, or other actions.

Abstract: Multiple hit load balancing provides a quasi-persistent request distribution for encrypted requests passing over secure connections as well as for multiple requests passing over the same connection. The multiple hit load balancing involves tracking object demand at each server of a set of servers. The multiple hit load balancing further involves dynamically scaling the servers that cache and directly serve frequently requested objects based on the demand that is tracked by each of the servers. For infrequently requested objects, the servers perform a peer retrieval of the objects so to limit the number of the same object being redundantly cached by multiple servers of the set of servers.

Abstract: Asynchronous file tracking may include a first process that adds files to a cache and that generates different instances of a tracking file to track the files as they are entered into the cache. A second process, executing on the device, asynchronously accesses one or more instances of the tracking file at a different rate than the first process generates the tracking file instances. The second process may update a record of cached files based on a set of entries from each of the different instances of the tracking file accessed by the second process. Each set of entries may identify a different set of files that are cached by the device. The second process may then purge one or more cached files that satisfy eviction criteria while the first process continues to asynchronously add files to the cache and create new instances to track the newly cached files.

Abstract: Asynchronous file tracking may include a first process that adds files to a cache and that generates different instances of a tracking file to track the files as they are entered into the cache. A second process, executing on the device, asynchronously accesses one or more instances of the tracking file at a different rate than the first process generates the tracking file instances. The second process may update a record of cached files based on a set of entries from each of the different instances of the tracking file accessed by the second process. Each set of entries may identify a different set of files that are cached by the device. The second process may then purge one or more cached files that satisfy eviction criteria while the first process continues to asynchronously add files to the cache and create new instances to track the newly cached files.