Microsoft Technology Licensing, LLC

Other

Amazon Technologies, Inc.

Sudarshan Anand Chitre

Lev Novik

Balan Sethu Raman

Philip Daniel Piwonka

David A Orbits

Praerit Garg

Gayathri Tambaram Kailasam

Rafik Robeal

Subramanian Muralidhar

Yi Chen

Calvin Yue-Ren Kuo

Chris J Guzak

Jason Fergus Moore

Jonathan I Turow

Anil Kumar Nori

Eric R Flo

Shaoyu Zhou

Shaun A Kaasten

Steven M Lasker

Sankara J Subramanian

Tristam Kyle MacDonald

Aditya Bhalla

Justin Robert Knoepfler

Philip Austin Vaughn

Yadunandan Parthasarathy

Laxmi Narsimha Rao Orugant

Ambrish Mishra

Manikandan Thangarathnam

Sitaram C V Raju

Vijay Tandra Sistla

Jeffrey M Saathoff

Vijay Krishna Tandra Sistla

Technology is described for migrating connections for Internet of Things (IoT) devices. Data packets may be received from an IoT device for forwarding to a first physical host in a computing service environment. A determination to migrate the connection for the IoT device from the first physical host to a second physical host in the computing service environment may be performed when a throughput of the data packets received from the IoT device for the first physical host exceeds a defined threshold. A connection migration procedure may be initiated to migrate the connection for the IoT device from the first physical host to the second physical host. The connection migration procedure may include an exchange of session state information for the IoT device from the first physical host to the second physical host to enable the migration of the connection to the second physical host.

Connection migration for Internet of Things (IoT) devices

The subject disclosure relates to cross scope synchronization among different sets of nodes that synchronize the same data item(s) according to different synchronization scopes. In one aspect, create and update versions are defined for a scope in which a data item was created and updated, respectively, and create and update versions are defined for a local node shared for different groups of nodes synchronizing according to the different synchronization scopes (e.g., a server node).

Cross-scope synchronization of data item knowledge and corresponding metadata

Architecture for restoring nodes. After restoring a node, fix-up occurs to make the node appears as a different node than before the restore operation. The node appears as a new node, which new node knows the data up to a certain point from when the new node had the prior identity. This allows for new changes generated by the new node to flow to the other nodes in the topology, as well as have the changes that the prior identity sent to other nodes flow back to the new node. In other words, the architecture maintains information to create the new node in the topology while maintaining prior data knowledge. Additionally, item level metadata of associated data items is updated to correlate with the updated data items so that changes can be correctly enumerated and applied. This metadata update occurs across scopes of which the data items are included.

Synchronization framework that restores a node from backup

A synchronization framework is provided for synchronizing data groups between a server and clients that may go off-line. The framework includes a client sync provider component that interfaces to client storage in a storage format independent way, a sync agent component that collects synchronization metadata maintained by the clients and uploads and/or downloads changes to the data groups to and/or from server storage and a server sync provider component that interfaces via sync adapters to server storage independently of storage format. The framework provides default building blocks for building off-line synchronizing applications that behave according to default application synchronization scenarios, and also enables custom building blocks for custom off-line application synchronization scenarios.

Synchronization framework for occasionally connected applications

Systems and methods that track changes in a database via a change tracking layer that enables separation of change tracking and change enumeration. Such an arrangement enables multiple change enumeration and sync technologies over a single change tracking layer, while reducing amount of tracking information that are maintained.

SQL change tracking layer

Disclosed is a data synchronization service for use in a peer-to-peer computing environment. Selected data objects are copied onto selected computing devices. A service running on each device monitors data objects for changes. When a change is detected, the service sends a change notification to the other devices so that they can update their copies of the data object. A user can access a data object from any device, knowing that he will retrieve the latest version of the data object. Instead of incurring the costs of storing a large file on every device, a user 'ghosts' the file on some devices. A ghosting device stores only metadata about the file rather than the entire file. The user accesses the file through the ghost: access requests are sent to a device that holds the actual contents, and those contents are presented to the user as if they were stored locally.

Method and system for synchronizing data shared among peer computing devices

Described is a system and method for replicating each of a set of resources to a subject computer in a replica set prior to making use of a resource in the set of resources. The set of resources includes resources that are dependent upon each other for a proper functioning of the group. A manifest file that identifies each resource in a group of interrelated resources is used. The manifest file is generated at one computer in the replica set (typically the computer at which a modification to one of the interrelated resources occurred). When the modification occurs to one of the set of resources, the manifest file is transmitted (e.g., itself replicated) to each computer in the replica set. The manifest file includes an indicator that identifies the manifest file as a special file. When received at another computer in the replica set, a service evaluates the manifest file to identify whether the appropriate versions of the identified resources exist at the receiving computer. If not, the service at that computer awaits the receipt of each resource. The wait period may include delaying the execution of an application associated with (or even included within) the manifest file from launching. Alternatively, the FRS could simply disallow access to one or more resources identified in the manifest file until all have arrived. When all have arrived, the FRS releases control of the identified resources, which may then operate or be accessed in the ordinary manner.

System and method for reliably replicating data

Described is a technology in which an anchor value is determined, for example to synchronize a destination database or data store with modifications made to a source database. The new anchor value is determined in a manner that excludes modifications corresponding to any uncommitted transactions. The new anchor value may be based on a counter value or a date and time value stored with each modification. The new anchor value may be determined by comparing a first set of committed modifications that do not include uncommitted modifications against a second set of modifications that includes committed modifications and uncommitted modifications. Alternatively, the new anchor value may be determined from the earliest start date and time among the modifications that are part of any uncommitted transactions. The anchor may be used (e.g., via queries) to enumerate modifications for synchronization, and also for detecting conflicts between the source and destination databases.

Anchor for database synchronization excluding uncommitted transaction modifications

System and method for replicating data in resource sets

Growing community of inventors

Redmond, WA, United States of America

Sudarshan Anand Chitre