Microsoft Technology Licensing, LLC

Microsoft Corporation

Anil K Ruia

Won Yoo

Ning Lin

Himanshu Patel

Chittaranjan Sadanand Pattekar

Erik B Olson

Wade Hilmo

Michael D Volodarsky

Yogesh Bansal

Bilal Alam

Venkat Raman Don

Michael E Brown

Paul J Leach

Parveen Kumar Patel

Lihua Yuan

William James Staples

Daniel Vasquez Lopez

Anish Desai

John A Bocharov

Jonathan A Silvera

Jaroslav Dunajsky

Matthew R Cox

Brett A Shirley

Randall Kern

Asim Mitra

Andrew E Goodsell

Ruslan A Yakushev

David Wang

Serguei Martchenko

Ian Jose

Tobias Marius Klima

Umair Ahmad

Wok Suk Yoo

Rick James

Thomas Deml

Alexandre Costa

Varun Joshi Kishanlal Joshi

Himanshu Kamarajbhai Patel

Michael Volodarsky

A system for database reversion is described. The system comprises: a database engine configured to host an active database; a log engine configured to generate transaction logs for transactions affecting the active database; a backup engine configured to create a backup data structure to allow for database reversion; and a memory buffer separate from the active database. A page in the active database has an associated page timestamp indicating a most recent update of the page in the active database. The database engine is configured to flush an updated copy of a page in the memory buffer to the active database. The backup engine is configured to, prior to the flush, store an image of the page in the active database to the backup data structure when the page in the active database is older than the time value related to the creation time of the backup data structure.

Database reversion with backup data structures

A system for write optimization in transactional data management systems is described. The system stores a tree data structure that comprises a root, a plurality of internal nodes, and a plurality of leaf nodes. Each internal node comprises a pivot key and a child pointer. Each leaf node stores key-value pairs sorted by a corresponding key. The system forms a plurality of hybrid nodes. The hybrid nodes comprise a layer of internal nodes that are immediate parents of the plurality of leaf nodes. A buffer is formed only for each internal node of the plurality of hybrid nodes. The buffer is used to store a message that encodes an operation. The message is to be applied to the corresponding leaf nodes of the plurality of hybrid nodes.

Write optimization in transactional data management systems

A caching system segments content into multiple, individually cacheable chunks cached by a cache server that caches partial content and serves byte range requests with low latency and fewer duplicate requests to an origin server. The system receives a request from a client for a byte range of a content resource. The system determines the chunks overlapped by the specified byte range and sends a byte range request to the origin server for the overlapped chunks not already stored in a cache. The system stores the bytes of received responses as chunks in the cache and responds to the received request using the chunks stored in the cache. The system serves subsequent requests that overlap with previously requested ranges of bytes from the already retrieved chunks in the cache and makes requests to the origin server only for those chunks that a client has not previously requested.

Byte range caching

An intelligent caching system is described herein that intelligently consolidates the name-value pairs in content requests containing query strings so that only substantially non-redundant responses are cached, thereby saving cache proxy resources. The intelligent caching system determines which name-value pairs in the query string can affect the redundancy of the content response and which name-value pairs can be ignored. The intelligent caching system organically builds the list of relevant name-value pairs by relying on a custom response header or other indication from the content server. Thus, the intelligent caching system results in fewer requests to the content server as well as fewer objects in the cache.

Intelligent caching for requests with query strings

Requests for content can be received from clients and forwarded to servers, and responses to the requests can be received from the servers and forwarded to the clients. A health model can also be maintained. The health model can be based on information in the responses and possibly also on information in the requests, and the health model can indicate the health of the servers in responding to different types of requests. The health model may differentiate between health in responding to requests with different features in URLs of the requests, such as different namespaces and/or different extensions.

Request-based server health modeling

The routing of requests in a shared hosting environment. The shared hosting environment includes a network farm of servers, each capable of processing the request corresponding to the host name. When a request is received, a router determines whether or not there is already a host name affinitization of subset of the servers to the host name corresponding to the request. If so, the message is dispatched to one of those affinitized servers. If not, one or more of the servers are affinitized to the host name to create a subset of affinitized server(s) for that host name. Different host names may have different subsets of servers that they are affinitized to. Over time, the affinitization may be terminated as appropriate.

Shared hosting using host name affinity

Architecture that facilitates the capture of connection state of a connection established between a client and an intermediate server and forwards the state to one or more target servers. A software component at the target server (as well as the intermediate server) uses this connection state to reply back to the client directly, thereby bypassing the intermediate server. All packets from the client related to the request are received at the intermediate server and then forwarded to the target server. The migration can be accomplished without any change in the client operating system and client applications, without assistance from a gateway device such as a load balancer or the network, without duplication of all packets between the multiple servers, and without changes to the transport layer stack of the intermediate and target servers.

Transparent migration of endpoint

A client system and a server system use a Hypertext Transfer Protocol (HTTP) authentication mode preference header to negotiate an HTTP authentication mode. The client system sends an HTTP request to the server system. In response to the HTTP request, the server system sends an HTTP response to the client system. The HTTP response includes an HTTP authentication mode preference header. The HTTP authentication mode preference header indicates whether a preferred HTTP authentication mode is connection-based HTTP authentication or request-based HTTP authentication. In subsequent HTTP requests to the server system, the client system uses the HTTP authentication mode indicated by the HTTP authentication mode preference header.

Predictive HTTP authentication mode negotiation

URL rewriting is a common technique for allowing users to interact with internet resources using easy to remember and search engine friendly URLs. When URL rewriting involves conditions derived for sources other than the URL, inconsistencies in HTTP kernel cache and HTTP user output cache may arise. Methods and a system for rewriting a URL while preserving cache integrity are disclosed herein. Conditions used by a rule set to rewrite a URL may be determined as cache friendly conditions or cache unfriendly conditions. If cache unfriendly conditions exist, the HTTP kernel cache is disabled and the HTTP user output cache is varied based upon a key. If no cache unfriendly conditions exist, then the HTTP kernel cache is not disabled and the HTTP user output cache is not varied. A rule set is applied to the URL and a URL rewrite is performed to create a rewritten URL.

HTTP cache with URL rewriting

A load balancing system is described herein that proactively balances client requests among multiple destination servers using information about anticipated loads or events on each destination server to inform the load balancing decision. The system detects one or more upcoming events that will affect the performance and/or capacity for handling requests of a destination server. Upon detecting the event, the system informs the load balancer to drain connections around the time of the event. Next, the event occurs on the destination server, and the system detects when the event is complete. In response, the system informs the load balancer to restore connections to the destination server. In this way, the system is able to redirect clients to other available destination servers before the tasks occur. Thus, the load balancing system provides more efficient routing of client requests and improves responsiveness.

Proactive load balancing

A live caching system is described herein that reduces the burden on origin servers for serving live content. In response to receiving a first request that results in a cache miss, the system forwards the first request to the next tier while 'holding' other requests for the same content. If the system receives a second request while the first request is pending, the system will recognize that a similar request is outstanding and hold the second request by not forwarding the request to the origin server. After the response to the first request arrives from the next tier, the system shares the response with other held requests. Thus, the live caching system allows a content provider to prepare for very large events by adding more cache hardware and building out a cache server network rather than by increasing the capacity of the origin server.

Network caching for multiple contemporaneous requests

Dynamically upsizing and/or downsizing a network farm in response to network demand. An application message router routes messages to the network farm. When the network farm approaches or is anticipated to be approaching capacity, a group of one or more servers may be added to the network farm. When the added server(s) are capable of participating in the network farm, the application message router is triggered to route also to the added servers. When the network farm has excess capacity, a group of one or more servers may be dropped from the network farm. This may be accomplished by triggering the application message router to no longer route messages to the removed servers. The removed servers may be either immediately or gracefully removed from service.

On-demand capacity management

Methods are provided for utilizing a modular server architecture for processing requests for services, such as authorization and authentication, in a web server. The modular server architecture includes self-contained modular components that can be plugged in and out of the web server, as needed, to provide requested web services. The modular server architecture is also extensible in that it provides set of server APIs for processing requests for supporting built-in server functionality as well as functionality provided by third party modular components. The modular server architecture also supports the integration of request processing tasks for both native and managed modular components, such as ASP.NET modules, by virtue of a managed module host component. The modular server architecture also optimizes server performance by only providing modular component functionality when needed. By utilizing the modular server architecture, server functionality is extended, duplication of request processing tasks is eliminated and performance administrative overhead is reduced.

Modular server architecture for multi-environment HTTP request processing

A method for caching data may be practiced, for example, in a computing environment including a server system that provides data to client systems. The server system includes a number of caches for storing data. The method allows a least expensive cache to first cache data or return data requested by a client. The method includes receiving data to be cached at a cache. The method further includes determining that the data has not been previously cached at a preceding cache. If the data has not been previously cached at a preceding cache the data is cached at the cache. Alternatively, requests for data may be received at a first cache. If the data is at the first cache, the first cache returns the data. If the data is not at the first cache, the request for data is forwarded to a subsequent cache.

Growing community of inventors

Issaquah, WA, United States of America

Anil K Ruia