Abstract: Examples of the present disclosure relate to systems and methods for fast and secure request forwarding. A server application may receive an indication that there is a request in a queue available for processing. The server application may peek at the request, thereby accessing at least a portion of the request without removing the request from the queue. Based on the portion of the request, a determination may be made about whether the server application should process the request directly or transfer the request to a different module. If it is determined that the request should be processed directly, the entire request may be received from the queue and processed accordingly. However, if it is determined that the request should be forwarded, the request may be transferred to a secondary queue. A different module may then receive the request from the secondary queue and process the request accordingly.

Abstract: Techniques described herein enable a client to store information indicating whether various hosts (e.g., servers, web domains) support a preferred security protocol, such as a False Start-modified TLS or SSL protocol. The client may then use this information to dynamically determine whether to use the preferred protocol when connecting to a particular host. When the client attempts a handshake to establish a secure connection with a host for the first time, the client does so using the preferred protocol. If the handshake fails, the client locally stores domain or other identifying information for the host so that the client may employ a non-preferred protocol in subsequent connection attempts. Thus, a client may avoid performance degradation caused by attempting a preferred-protocol connection with a host that does not support the preferred protocol. Stored information may include a time stamp enable periodic checks for host capability updates.

Abstract: Techniques described herein enable a client to store information indicating whether various hosts (e.g., servers, web domains) support a preferred security protocol, such as a False Start-modified TLS or SSL protocol. The client may then use this information to dynamically determine whether to use the preferred protocol when connecting to a particular host. When the client attempts a handshake to establish a secure connection with a host for the first time, the client does so using the preferred protocol. If the handshake fails, the client locally stores domain or other identifying information for the host so that the client may employ a non-preferred protocol in subsequent connection attempts. Thus, a client may avoid performance degradation caused by attempting a preferred-protocol connection with a host that does not support the preferred protocol. Stored information may include a time stamp enable periodic checks for host capability updates.

Abstract: Examples of the present disclosure relate to systems and methods for fast and secure request forwarding. A server application may receive an indication that there is a request in a queue available for processing. The server application may peek at the request, thereby accessing at least a portion of the request without removing the request from the queue. Based on the portion of the request, a determination may be made about whether the server application should process the request directly or transfer the request to a different module. If it is determined that the request should be processed directly, the entire request may be received from the queue and processed accordingly. However, if it is determined that the request should be forwarded, the request may be transferred to a secondary queue. A different module may then receive the request from the secondary queue and process the request accordingly.

Abstract: Techniques described herein enable a client to store information indicating whether various hosts (e.g., servers, web domains) support a preferred security protocol, such as a False Start-modified TLS or SSL protocol. The client may then use this information to dynamically determine whether to use the preferred protocol when connecting to a particular host. When the client attempts a handshake to establish a secure connection with a host for the first time, the client does so using the preferred protocol. If the handshake fails, the client locally stores domain or other identifying information for the host so that the client may employ a non-preferred protocol in subsequent connection attempts. Thus, a client may avoid performance degradation caused by attempting a preferred-protocol connection with a host that does not support the preferred protocol. Stored information may include a time stamp enable periodic checks for host capability updates.

Abstract: Browser storage management techniques are described. In one or more implementations, inputs are received at a computing device that specify maximum aggregate sizes of application and database caches, respectively, of browser storage to be used to locally store data at the computing device. For example, the inputs may be provided using a policy, by an administrator of the computing device, and so on. The maximum aggregate sizes are set of application and database caches, respectively, of browser storage at the computing device to the sizes specified by the inputs.

Abstract: Various embodiments enable on-demand scaling of a timer wheel. Some embodiments dynamically start and stop a timer wheel based, at least in part, on whether the timer wheel has any associated active timers. In some cases, the timer wheel is suspended when all associated active timers have been serviced. Alternately or additionally, the timer wheel is re-activated upon associating one or more active timers in need of service to the timer wheel. Various embodiments enable addition and removal of timer(s) to the timer wheel and/or various time slots associated with the timer wheel without using a global lock associated with the timer wheel.

Abstract: Various embodiments initialize a communication link associated with data transfer to a connected state between participants in the communication link. In some cases, the communication link is paired with a first Input/Output (I/O) completion port effective to enable the data transfer. Some embodiments disassociate the communication link with the first I/O completion port and re-initialize the communication link while retaining the connected state. Alternately or additionally, the communication link is paired with at least a second I/O completion port. In some cases, the second I/O completion port utilizes an I/O model that differs from an I/O model associated with the first I/O completion port. Alternately or additionally, the communication link can be reconfigured to follow a IO model that does not utilize an IO completion port at all.

Abstract: Various embodiments enable parallel querying of multiple network interfaces for communication configuration information. Returned communication configuration information can be used by a client device to enable communication with another computing device. In some embodiments, multiple responses to the parallel queries are received. Alternately or additionally, a response from a network interface can be determined through expiration of a user-configured timeout and/or a protocol configured timeout. Selection of a network interface from the multiple responses can be based, at least in part, on prioritizing the responding network interfaces using an adaptive selection algorithm.

Abstract: Various embodiments enable on-demand scaling of a timer wheel. Some embodiments dynamically start and stop a timer wheel based, at least in part, on whether the timer wheel has any associated active timers. In some cases, the timer wheel is suspended when all associated active timers have been serviced. Alternately or additionally, the timer wheel is re-activated upon associating one or more active timers in need of service to the timer wheel. Various embodiments enable addition and removal of timer(s) to the timer wheel and/or various time slots associated with the timer wheel without using a global lock associated with the timer wheel.

Abstract: Various embodiments initialize a communication link associated with data transfer to a connected state between participants in the communication link. In some cases, the communication link is paired with a first Input/Output (I/O) completion port effective to enable the data transfer. Some embodiments disassociate the communication link with the first I/O completion port and re-initialize the communication link while retaining the connected state. Alternately or additionally, the communication link is paired with at least a second I/O completion port. In some cases, the second I/O completion port utilizes an I/O model that differs from an I/O model associated with the first I/O completion port. Alternately or additionally, the communication link can be reconfigured to follow a IO model that does not utilize an IO completion port at all.

Abstract: Adaptive network communication techniques are described. In one or more implementations, a determination is made by a client device that a request, which is to be communicated to a content provider via a network, is for content that is accessible via the content provider upon authentication of credentials transmitted to the content provider from the client device. Responsive to the determination, an initial communication is formed by the client device for receipt by the content provider that includes the credentials without waiting for the content provider to request the credentials from the client device.

Abstract: In one or more embodiments, clients in various networks can proactively probe multiple proxies that are returned to the client. Clients can sort the proxies based on various parameters, such as connection time parameters as well as other parameters, and utilize the fastest or one of the fastest proxies available, or select a proxy based on other parameters that indicate the proxy is reliable. In this manner, slow or unreliable proxies can be avoided.

Abstract: Techniques described herein enable a client to store information indicating whether various hosts (e.g., servers, web domains) support a preferred security protocol, such as a False Start-modified TLS or SSL protocol. The client may then use this information to dynamically determine whether to use the preferred protocol when connecting to a particular host. When the client attempts a handshake to establish a secure connection with a host for the first time, the client does so using the preferred protocol. If the handshake fails, the client locally stores domain or other identifying information for the host so that the client may employ a non-preferred protocol in subsequent connection attempts. Thus, a client may avoid performance degradation caused by attempting a preferred-protocol connection with a host that does not support the preferred protocol. Stored information may include a time stamp enable periodic checks for host capability updates.

Abstract: A client application, such as an HTTP client, stores script profile data associated with JavaScript compilation as metadata in a cache, such as an HTTP indexed cache, for a given entry. Accessing the indexed data can be performed much faster without incurring additional disk input/output operations, thus facilitating compilation activities. In addition, an identifier such as the script URL can be used to efficiently enable compilation across websites that commonly utilize the same JavaScript.

Abstract: Browser storage management techniques are described. In one or more implementations, inputs are received at a computing device that specify maximum aggregate sizes of application and database caches, respectively, of browser storage to be used to locally store data at the computing device. For example, the inputs may be provided using a policy, by an administrator of the computing device, and so on. The maximum aggregate sizes are set of application and database caches, respectively, of browser storage at the computing device to the sizes specified by the inputs.

Abstract: Adaptive network communication techniques are described. In one or more implementations, a determination is made by a client device that a request, which is to be communicated to a content provider via a network, is for content that is accessible via the content provider upon authentication of credentials transmitted to the content provider from the client device. Responsive to the determination, an initial communication is formed by the client device for receipt by the content provider that includes the credentials without waiting for the content provider to request the credentials from the client device.