Method and system for synchronizing offline data in a computing system

Abstract

A method for synchronizing offline data in a computing system includes: receiving, at a server associated with a storage service, a request from an application to create a synchronization group associated with a plurality of member electronic devices; at the server, receiving one or more objects stored by the storage service that will be shared by the plurality of member electronic devices; at the server, receiving an instruction from the first member electronic device to modify a first object among the one or more objects when the first member electronic device is operating offline, and synchronizing, by the server, one or more storage devices on one or more other member electronic devices of the synchronization group such that the first object in the one or more storage devices is updated to include the modification made by the first member electronic device to the first object.

Description

[0001] This application is a divisional application of the following application.

[0002] International application number of the original application: PCT / US2016 / 054859

[0003] The original international filing date was September 30, 2016.

[0004] The original application's national application number was 201680056479.8.

[0005] The original invention application was titled: Peer-to-peer synchronous storage system.

[0006] Related applications and priorities

[0007] This patent document claims priority to U.S. Provisional Patent Application No. 62 / 236,480, filed October 2, 2015, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0008] This application relates to methods and systems for synchronizing offline data in a computing system. Background Technology

[0009] Sharing data among multiple devices and users is often desirable. However, this can be difficult when one or more devices are offline but still want to share data. Additionally, users may have the ability to modify data simultaneously. Detecting and resolving conflicts that such modifications might cause in a distributed system can be challenging. Summary of the Invention

[0010] This disclosure is not limited to the specific systems, methods, or protocols described, as these can vary. The terminology used in this specification is for the purpose of describing a particular version or embodiment and is not intended to be limiting.

[0011] As used herein, unless the context clearly specifies otherwise, the singular forms “a,” “an,” and “the” include plural references. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art. As used in this document, the term “comprising” means “including but not limited to.”

[0012] In one embodiment, a system for creating a synchronization group in a distributed system includes an offline electronic device having a short-range communication transmitter and a storage service, and a computer-readable storage medium including one or more programming instructions. When executed, the programming instructions cause the electronic device to receive a request from an application to create a synchronization group and verify that the application has read access to the storage service. In response to the verification that the application has read access to the storage service, the system receives an indication of one or more objects to be shared stored in the storage service, identifies one or more members of the synchronization group, and assigns one or more permissions to the identified members. The system synchronizes access permissions for objects in the electronic device and one or more member electronic devices associated with the member electronic device, such that when a member electronic device is within range of the transmitter of the electronic device, the object can be accessed via each of the member electronic devices, wherein the access permissions of the member electronic devices to the object are based on the assigned one or more permissions.

[0013] Optionally, the system assigns a unique name to the synchronization group. The system publishes the unique name to a list accessible to the member electronic devices.

[0014] Optionally, each of the member electronic devices is offline.

[0015] Optionally, the system detects network connectivity and responds by sending a request to create the synchronization group to the synchronization group server, and creating a version of the synchronization group, which is then created by the synchronization group server at the synchronization group server, and synchronizing objects and metadata with the electronic device and one or more member electronic devices.

[0016] Optionally, the system generates an access control list (ACL) that indicates which member electronic device is permitted to access the object.

[0017] In one embodiment, a system for creating a synchronization group in a distributed system includes an electronic device containing a storage service and a computer-readable storage medium including one or more programming instructions. When executed, the programming instructions cause the electronic device to receive a request from an application to create the synchronization group and verify that the application has read access to the storage service. In response to the verification that the application has read access to the storage service, the system receives an indication of one or more objects to be shared stored in the storage service, identifies one or more members of the synchronization group, and assigns one or more permissions to the identified members. The system identifies a synchronization group server associated with the synchronization group and sends a notification to the synchronization group server informing it that the synchronization group has been created and that access permissions to objects in the electronic device and one or more member electronic devices associated with the one or more members are synchronized, such that the objects are accessible via each of the member electronic devices, wherein the access permissions of the member electronic devices to the objects are based on the assigned one or more permissions.

[0018] Optionally, the system assigns a unique name to the synchronization group. The system publishes the unique name to a list accessible to the member electronic devices.

[0019] Optionally, the system generates an access control list that indicates which member electronic device is permitted to access the object.

[0020] Optionally, the system communicates with the synchronization group server using one or more remote procedure calls. Attached Figure Description

[0021] Figure 1A and 1B Various embodiments of a distributed peer-to-peer synchronization system are shown.

[0022] Figure 2 A flowchart illustrating an example method for creating a synchronization group according to an embodiment is shown.

[0023] Figure 3 An example data exchange according to an embodiment is shown.

[0024] Figure 4 An example of conflict resolution according to an embodiment is shown.

[0025] Figure 5 An example of synchronized group settings according to an embodiment is shown.

[0026] Figure 6 An example of object visibility / invisibility transformation according to an embodiment is shown.

[0027] Figure 7 A block diagram of example hardware, according to various embodiments, is shown that can be used to contain or implement program instructions and communicate with other devices. Detailed Implementation

[0028] For the purposes of this application, the following terms shall have their respective meanings as stated below:

[0029] An "Access Control List" or "ACL" is a list, table, or other data structure that identifies a permission that is attached to a specific object or set of objects. A permission may apply to a single device or multiple devices.

[0030] A "dynamic name server" is an electronic device that allows clients to create names and associate network endpoints, such as IP addresses or port numbers, with those names. One or more other electronic devices can then look up that name on the dynamic name server, find the corresponding endpoint, and communicate with it.

[0031] "Electronic device" or "computing device" refers to a device that includes a processor and memory. Each device may have its own processor and / or memory, or, as in a virtual machine or container arrangement, the processor and / or memory may be shared with other devices. Memory may contain or receive programming instructions that, when executed by the processor, cause the electronic device to perform one or more operations according to those programming instructions. Examples of electronic devices include personal computers, servers, mainframes, virtual machines, containers, gaming systems, televisions, and mobile electronic devices such as smartphones, personal digital assistants, cameras, tablets, laptops, media players, etc. In a client-server arrangement, the client device and the server are both electronic devices, where the server contains instructions and / or data accessed by the client device via one or more communication links in one or more communication networks. In a virtual machine arrangement, the server can be an electronic device, and each virtual machine or container can also be considered an electronic device. In the following discussion, for the sake of brevity, client devices, server devices, virtual machines, or containers may be simply referred to as "devices".

[0032] A "member" refers to an electronic device that has joined a synchronization group. Members can be identified by the device's globally unique name and / or metadata associated with the device, such as synchronization priority.

[0033] An "object" is a process, dataset, or other resource, function, or transaction that the server controls access to through authorized clients.

[0034] A "prefix" refers to one or more key prefixes (or key ranges) used to specify the subset of data to be synchronized. For example, defining a synchronization group in a database with the prefixes "foo" and "bar" means that the synchronization group synchronizes all entries whose keys begin with the string "foo" or "bar". This set of prefixes cannot be modified after the synchronization group is created.

[0035] In this document, the terms "processor" and "processing device" refer to hardware components of an electronic device configured to execute programmed instructions. Unless otherwise specifically stated, the singular terms "processor" or "processing device" are intended to include both single processing device embodiments and embodiments in which multiple processing devices process together or in combination.

[0036] "Structured storage" refers to a computer-readable storage medium that includes at least some objects to be synchronized between or among two devices. Structured storage may include key-value stores, mappings of string keys to data types, relational databases, and / or similar entities.

[0037] "Storage services" refers to a computer-readable storage system that facilitates the synchronization of objects across electronic devices in a peer-to-peer manner.

[0038] A “synchronization group” is intended to refer to a group of devices that are permitted to synchronize a set of data with each other and / or to a data storage facility.

[0039] "Synchronization Group Name" refers to a globally unique name that identifies the synchronization group.

[0040] A "synchronization group server" is an electronic device that communicates with a synchronization group. A synchronization group server can store information associated with the synchronization group, such as metadata.

[0041] Unless otherwise stated, the singular terms “processor,” “processing device,” “electronic device,” or “computing device” are intended to include both single processing device embodiments and embodiments in which multiple processing devices work together or in combination.

[0042] In this document, the terms “memory,” “memory device,” “data storage,” “data storage facility,” etc., each refer to a non-transitory device on which computer-readable data, programming instructions, or both are stored. Unless otherwise specified, the terms “memory,” “memory device,” “data storage,” “data storage facility,” etc., are intended to include embodiments of a single device, embodiments in which multiple memory devices together or jointly store datasets or instruction sets, and embodiments of individual sectors within such devices.

[0043] Figure 1A Various embodiments of a distributed peer-to-peer synchronization system are illustrated. For example... Figure 1A As shown, system 100 may include a synchronization group 102 having two or more electronic devices 104a-N. Although Figure 1A A synchronization group B is shown, but one or more electronic devices 104a-N may belong to one or more other synchronization groups. Electronic devices 104a-N in synchronization group 102 may belong to one or more users. For example, synchronization group 102 may include mobile phones, tablets, and laptops belonging to a single user who wishes to synchronize data between these devices. In another example, synchronization group 102 may include a mobile phone associated with a first user, a tablet associated with a second user, a mobile phone associated with a third user, and a laptop associated with a fourth user. Additional and / or alternative numbers of user and / or electronic device types may be used within the scope of this disclosure.

[0044] Devices in each synchronization group 102 will store additional data structures or ACLs identifying other devices that are members of the synchronization group. In this context, the term "device" can refer to an actual electronic device identifier or an identifier of a user using a particular electronic device. In various embodiments, a device associated with a read "R" or write "W" permission can join the synchronization group. An "A" permission can identify a device acting as a synchronization group administrator. The synchronization group administrator can perform certain actions that are not permitted for non-administrators, such as allowing new devices to join the synchronization group, removing devices from the synchronization group, modifying applicable ACLs, etc. In one embodiment, the synchronization group can also specify a conflict resolution strategy for coordinating synchronization conflicts. Multiple synchronization groups can be defined, and these groups can overlap or nest. In one embodiment, the synchronization group metadata can be distributed and can exist on all nodes participating in the synchronization group. The administrator of the synchronization group can be a person permitted to change or modify the metadata. This metadata can be synchronized using a peer-to-peer (p2p) synchronization protocol.

[0045] like Figure 1A As shown, synchronization group 102 can communicate with one or more synchronization group servers 106a-N via a communication network 108, such as a wireless telephone network, the Internet, an intranet, a local area network, a wide area network, other types of networks, or any combination thereof. In various embodiments, synchronization group servers 106a-N may be part of synchronization group 102. Synchronization group servers 106a-N can store and manage metadata and / or data associated with synchronization group 102. Metadata may include, but is not limited to, a list of electronic devices permitted to join the synchronization group, a list of current members of the synchronization group, and data to be synchronized between which devices in the synchronization group.

[0046] In some embodiments, synchronization group servers 106a-N can be used when devices join and leave synchronization group 102. Providing synchronization group servers 106a-N on non-mobile devices, such as servers in the cloud, is often convenient, as this makes it less likely for synchronization group servers 106a-N to be lost or stolen. In other embodiments, synchronization group servers 106a-N can be implemented as mobile electronic devices or other types of electronic devices. In yet another embodiment, synchronization group 102 may not be associated with synchronization group servers 106a-N. More specifically, metadata can be managed by an administrator within synchronization group 102.

[0047] like Figure 1B As shown, in various embodiments, a synchronization group server 106a-N (or other server) may be considered a member of a synchronization group. For example, if a synchronization group is created while an electronic device is online, or if a synchronization group is created while the electronic device is offline and the electronic device later connects to the Internet, the synchronization group server can be a member of the synchronization group. In this way, the synchronization group server can provide data and / or server backups, serving as a convenient location for electronic devices to access the most recent updates.

[0048] One or more electronic devices 104a-N can communicate with one or more other electronic devices via a communication network 110, such as a wireless telephone network, the Internet, an intranet, a local area network, a wide area network, other types of networks, or any combination thereof. In other embodiments, the communication network 110 can be a short-range or near-field communication network. Thus, electronic devices can communicate with each other without an Internet connection. When devices are able to communicate via the network, subsequent management of the newly created synchronization group can be transferred to a synchronization group server via the Internet or other network connections.

[0049] In some embodiments, synchronization groups can be created when one or more electronic devices that will become part of the synchronization group are offline, meaning these devices are not connected to the internet. When a synchronization group is created, the creator becomes the default administrator or manager of the new synchronization group. As devices join the synchronization group (permitted by the synchronization group's ACL), these devices form a loosely coupled distributed system for synchronization group management. This may include bootstrapping other members allowed to join the synchronization group and acknowledging and propagating changes to the synchronization group's metadata, etc.

[0050] Synchronization groups can also be synchronized peer-to-peer. Administrators can make themselves available via a discovery service so members can contact them even when offline. Synchronization group management is robust because it does not rely on any single administrator. It also allows the creation of synchronization groups to continue even when the creator is not connected to the internet.

[0051] In various implementations, device users may want to create a synchronization group while their devices are offline. For example, user 1 of device A may be camping with user 2 of device B and user 3 of device C, and none of the devices have internet access. However, user 1 may want to create a synchronization group that includes devices B and C so that the three users can share photos of their camping trip.

[0052] User 1 can access an app on her device to store photos she wants to share. These photos can have the same prefix, such as "camping trip". User 1 can choose options to share identifiable photos, and can also be given the option to restrict sharing to a set of user identities. User 1 can identify User 2 and User 3.

[0053] This application creates a sync group on behalf of User 1. Since User 1 is offline, the creation of the sync group on the sync group server remains pending. However, the sync group is created on Device 1. Device 1 uses Near Field Communication (NFC) to send a request to join the sync group to Devices 2 and 3. Once the request is accepted, Devices 1, 2, and 3 will sync and share photos or other objects. When Device 1 regains its internet connection, the creation of the sync group on the sync group server is complete. New members can then join the sync group via the sync group server, and existing members can synchronize their sync group metadata with the sync group server.

[0054] In some embodiments, the sync group creator can assign a default administrator (possibly a device in the cloud) for use by other sync group members. If a default administrator is designated, that administrator is immediately added to the sync group as soon as they become online and reachable. Sync group administrators can periodically "ping" the default administrator to join the sync group until it accepts or declines the request. The resulting group state can be logged and propagated to other administrators in the group via the sync protocol. This approach helps creators and / or administrators transfer administrative responsibility to more capable sync group members. In this way, sync group management enables offline functionality and load balancing.

[0055] The following describes an example of a synchronized group data structure based on an embodiment:

[0056]

[0057]

[0058]

[0059] In various embodiments, communication can be performed via one or more Remote Procedure Calls (RPCs). For example, an application can communicate with a storage service via RPC, and the storage service can communicate with a storage service server via RPC. The RPC from the application to the storage service can be handled by a synchronization group server module within the storage service. According to an embodiment, example permissions for creating certain RPCs are explained below:

[0060]

[0061]

[0062] In one embodiment, the application may have at least read access to create the RPC associated with the sync group. Additionally, the application may have read access to join the sync group. The application may require administrator privileges to perform "eject," "destroy," or "set up" operations. To create a sync group, a data ACL may exist before each sync group prefix, and the calling application should have at least read access to the ACL. The application may not require additional permissions to leave the sync group.

[0063] Create a sync group

[0064] Figure 2 A flowchart illustrating an example method for creating a synchronization group according to an embodiment is shown. Figure 2 As shown, the storage service can receive 200 requests from applications (such as a storage service agent) to create new synchronization groups. The storage service can verify 202 that the application receiving the request has read access to the storage service.

[0065] In response to verification that the application has read access to the storage service, a 204 synchronization group can be created locally within the storage service, provided that the synchronization group does not already exist in the storage service. When creating a synchronization group, the storage service can assign a globally unique name to the synchronization group. This name can include the name of the synchronization group server. For example, the name can include the name of the synchronization group server as a prefix. The storage service can define key prefixes that constitute the synchronization group. A prefix is ​​an indication specifying the subset of data to be synchronized and / or ACLs. For example, defining a synchronization group in the database with prefixes "foo" and "bar" means that the synchronization group synchronizes all entries whose keys begin with the string "foo" or "bar".

[0066] In one embodiment, the storage service may receive instructions on one or more objects to be shared with members of the synchronization group. These objects may be data objects, such as documents, images, photos, messages, and / or the like. The storage service may also receive instructions on one or more objects to be shared from a user. For example, a user may specify which objects from the storage service will be shared with members of the synchronization group.

[0067] In various embodiments, the storage service can identify one or more potential members of an established synchronization group and one or more permissions associated with those members. The storage service can identify one or more potential members based on input from a user. For example, a user can identify a member by providing its name or other identifier. The storage service can identify a conflict resolution strategy associated with the synchronization group. The conflict resolution data strategy can specify how conflicts related to data synchronization should be handled.

[0068] Return to reference Figure 2 The storage service, acting on behalf of the application, can contact the synchronization group server assigned to the new synchronization group (206) to inform it that the new synchronization group has been created and exists. In one embodiment, the storage service can use one or more remote procedure calls (RPCs) to send the notification. If the synchronization group already exists, or if the application lacks the appropriate permissions to create the synchronization group, the storage service server can return an error. If the storage service receives an error from the synchronization group server, it may not create the requested synchronization group and may inform the requesting application of the error.

[0069] In one embodiment, the storage service may be unable to contact the synchronization group server because it is unreachable. For example, the device associated with the storage service and / or the synchronization group server may be offline. In this case, the storage service can remember the pending contact request until the synchronization group server becomes accessible and continue creating the synchronization group offline. The storage service can attempt to contact the synchronization group server later to synchronize the new synchronization group and associated metadata. For example, when the storage service detects internet or other network communication, it can send a request to the synchronization group server to create a synchronization group. The synchronization group server can create the synchronization group and synchronize the applicable objects and metadata with the appropriate devices.

[0070] In one embodiment, the storage service may publish the name of device 208 at a dynamic name server specified by the synchronization group. The storage service may also publish the name of the created synchronization group 210 on a nearby dynamic name server so that offline joiners can locate the synchronization group.

[0071] Once members join a synchronization group, the storage service can synchronize access permissions for objects to be shared among members, so that these objects can be accessed through one or more members' electronic devices.

[0072] If the storage service is offline, near-field communication technologies, such as Near Field Communication (NFC), Bluetooth, Bluetooth Low Energy, Radio Frequency Identification (RFID), or other technologies, can be used to share the object with the devices of one or more members. For example, electronic devices may include transmitters and / or receivers that allow them to communicate with other devices within the range of a near-field protocol. In some embodiments, one or more devices of one or more members may also be offline but capable of communicating using near-field communication technologies.

[0073] Join the sync group

[0074] To join a sync group, an electronic device either needs to obtain the sync group name out of band, or it may already know the sync group name by convention. The storage service may take the following steps when joining a sync group:

[0075] • The application making the verification request has read access to the database.

[0076] • Contact the synchronization group server specified in the synchronization group name on behalf of the application (application approval store) to attempt to join the synchronization group.

[0077] If the synchronization group server cannot be reached, a search is conducted for nearby endpoints corresponding to the synchronization group name. If an endpoint is found, a join request is sent to that endpoint; otherwise, the join attempt fails.

[0078] Note: To prevent nearby devices from impersonating another sync group administrator, the sync group name can include a list of approved (blessing) prefixes for the administrator to check during RPC.

[0079] • Return synchronized group metadata in local storage.

[0080] • Publish the device name in the dynamic name server specified by the synchronization group.

[0081] • If the joiner is a sync group administrator (check ACL), publish the sync group name on a nearby dynamic name server, making that nearby dynamic name server another location for other members to join.

[0082] On the synchronization group server side, when a Join RPC is received, it verifies that the joiner has been allowed to join by the synchronization group's ACL. It adds the device to the joiner list, which is also synchronized with other synchronization group metadata.

[0083] Synchronize group metadata

[0084] Storage services can track known synchronization groups for devices, either as members or as administrators. During p2p synchronization with other devices, for each synchronization group, the synchronization group metadata can be synchronized before data exchange. In other words, synchronization group membership information is actually part of the synchronization group itself, but can be transmitted first. This can be done by fully utilizing the p2p synchronization protocol used to synchronize application data. The metadata for each synchronization group can be tracked using generated vectors and entries in a directed acyclic graph (DAG). The generated vector can be a data structure that identifies how far back a given electronic device has seen the history of other electronic devices (or the history of various electronic devices). This allows devices to quickly identify and exchange the most recent modifications in each synchronization group and detect conflicts to resolve. The synchronization initiator device can send a list of synchronization groups it shares with the responder, along with the generated vectors for those synchronization groups, to the responder. The responder calculates the generated vector differences and replies with changes to the synchronization groups, as well as updated generated vectors for each synchronization group. For each synchronization group in the reply, the initiator can update its DAG, detect conflicts, and take the following actions:

[0085] Conflict detected The initiator is the administrator. action Fake -- Accept changes and update local SG copy. real Fake Delayed solution, no local SG changes real real Resolve conflicts and update the local SG copy.

[0086] By merging the three parties that made these changes, conflict resolution can be automated:

[0087] • Prefix: Cannot be changed.

[0088] • Conflict resolver strategy: Cannot be changed.

[0089] Privacy: Cannot be changed.

[0090] • Description: The previous timestamp indicates victory.

[0091] • Permission: For each “Allow” and “Deny” set, merge entries from the 3-way differences by each (tag, pattern), and apply the additions and deletions from both differences.

[0092] • Dynamic name server: Each record from the three-party differences is merged, and additions and deletions from the two differences are applied.

[0093] • Membership set: Each member record from the three differences is merged, applying the additions and deletions from the two differences.

[0094] The synchronization of group metadata first occurs during the synchronization cycle. This allows the device to know the latest synchronization group ACL and membership set before starting the data synchronization cycle.

[0095] Leave the sync group

[0096] Members can call `LeaveSyncGroup()` to terminate their participation in the synchronization group. The storage service can send an RPC to one of the synchronization group administrators to convey the request and clear the local synchronization group state. The synchronization group data is still stored. If no administrator can be contacted, the storage service can continue to clean up its synchronization group metadata locally and stop participating in synchronization. When others attempt to synchronize with the storage service, it will reject them (unknown synchronization groups), and others can perform their own cleanup, updating their membership set if they are administrators.

[0097] Expel members of the synchronization group

[0098] When a sync group administrator needs to evict a sync group member (e.g., a lost or stolen device), it modifies the sync group ACL to deny access to that member (i.e., remove its approval) and removes the member from the joiner list. This metadata change propagates to other members, and each member stops syncing with that member. If the denied member is reachable, the administrator sends an eviction message instructing that member to clean up its local state. Before the ACL change propagates to all sync group members, the denied member can continue syncing with some members, and its data updates will be accepted. This behavior is similar to the data sync protocol when an ACL denies access to a member.

[0099] Offline vs. Online

[0100] Synchronization groups can be created while the creator is offline, and these groups cannot contact the synchronization group server included in the group name. Contacting the remote server will remain pending until it becomes accessible, at which point the remote server learns the synchronization group. Alternatively, by using the server name of the synchronization group in the group name, the creator can create the synchronization group locally, bypassing the step of the synchronization group needing to contact a remote server to notify it. Other members can join the synchronization group by contacting any available administrator members through a nearby dynamic name server.

[0101] Synchronous group approval

[0102] A synchronization group server can approve new members to indicate that it is now a member of the synchronization group, rather than using application approval during the synchronization process. To enable this approval in multi-host and potentially disconnected settings, and to ensure that the approval originates from a device other than the creator (e.g., Alice / Telephone is creating a synchronization group for a chess club, but wants the approval to be in the form of chessclub / sgserver / ), further steps are needed.

[0103] <sgname>The creator needs to pre-cache the approval from the synchronization group server it intends to use to create the synchronization group.

[0104] Using synchronized group approval offers the following advantages:

[0105] • If a potential sync group member has already joined the sync group, confirm that the potential sync group member can sync with other members.

[0106] • Synchronization can continue even if existing members of the synchronization group are using older ACLs and are unaware of newly joined members. New members can update the ACLs of older members to the latest version.

[0107] • Synchronization group owners who wish to strengthen their control over synchronization groups have the entire approval mechanism at their disposal (warnings, revocations, etc.).

[0108] Synchronize group ACLs and data prefix-ACLs

[0109] Synchronization group ACLs control access to the synchronization group during synchronization operations. They are used to verify that a remote device is a member of the synchronization group. Whether via API or during synchronization data exchange, database ACLs and longest-matching-prefix ACLs (the most specific ACL for the key) control application access to data. When an application accesses the database, the following ACLs may be checked: database ACL, table ACL, and longest-matching-prefix ACL. When a device retrieves synchronization updates, the following ACLs are checked for each synchronization group that the device participates in: synchronization group ACL and longest-matching-prefix ACL.

[0110] In one embodiment, a synchronization group cannot be created if a prefix ACL is not already set at each synchronization group prefix. These prefix ACLs can be synchronized and can be considered "inside" the synchronization group. This helps ensure that all synchronization group members follow the same ACL because all data entries in the synchronization group are controlled by the prefix ACL, which is also part of the synchronization group, rather than being "leaked" from an ACL "outside" the synchronization group.

[0111] Synchronize the interaction between group ACLs and prefix ACLs

[0112] Joining and leaving a synchronization group may not affect local access to the database. Similarly, synchronized access to data within a synchronization group can depend on the metadata synchronized as part of the synchronization group (synchronization group ACL and all data prefix ACLs within the synchronization group scope), and all members of the synchronization group can have the same behavior locally, even if their ACLs are outside the scope of the synchronization group changes (e.g., prefix ACLs shorter than the synchronization group prefix).

[0113] When a prefix ACL is defined with the same prefix as a synchronization group ACL, the prefix ACL can be considered "inside" the synchronization group and can be synchronized. This means it will be considered deeper in the nesting and therefore will override the synchronization group ACL in the "longest match" evaluation.

[0114] A special case handled to preserve consistent behavior across sync group members: what happens if the longest matching prefix ACL for sync group data exceeds the scope of the sync group itself? For example, the sync group is prefixed with "foo," but an application defines a prefix ACL at "f," and this ACL might differ across devices. To preserve consistent behavior, a fallback rule can be used: if the longest matching prefix ACL for a sync group data entry is shorter than the sync group prefix, the sync group ACL is used. This prevents prefix ACLs outside the sync group from leaking their effects into the sync group.

[0115] For example, consider three synchronization groups with overlap and nesting, and two prefix ACLs:

[0116] • SG1 prefixes "foo" and "bar" use SG-ACL1

[0117] • SG2 prefixes "foo" and "baz" use SG-ACL2

[0118] • SG3 prefixed with "foobar" uses SG-ACL3

[0119] • ACL4, the prefix of "foo 1" - ACL

[0120] • ACL5, the prefix for "foobar 1" - ACL

[0121] Devices synchronizing on SG1 can access SG-ACL1. Since there are no further control ACLs, this grants it access to all data under the "bar" prefix. For the "foo" prefix, it needs to go through ACL4 for data under "foo 1" and ACL5 for data under "foobar l," otherwise it receives the remaining data under the "foo" prefix. Similarly, devices synchronizing on SG2 can access SG-ACL2. This will grant it all data under the "baz" prefix and all data under the "foo" prefix except for subsets under "foo l" and "foobar l," with ACL4 and ACL5 required for "foo l" and its subsets respectively. Devices synchronizing on SG3 can access SG-ACL3. This grants it data under "foobar" except for a subset under "foobar l," which also needs to go through ACL5. Devices synchronizing on multiple synchronization groups will receive a combination of allowed data according to the rules described above.

[0122] Automatic addition function

[0123] To provide a seamless sync experience across all user devices, the auto-join feature can be used. Users can choose to enable auto-join during storage service settings. This creates a single auto-join sync group for that user to exchange information about app sync groups. An auto-join agent running on each user's device can be part of this sync group. The auto-join agent on each device can detect when an app creates or joins a sync group and represent it as an entry in the auto-join sync group. Auto-join agents on all other devices for that user react to new entries in the auto-join sync group and automatically join the specified app sync group (if allowed).

[0124] The following examples illustrate various implementation schemes involving creating and joining synchronization groups.

[0125] Use Case 1

[0126] Alice works for Company A and wants to share some documents about a project stored in a storage service with her colleagues Bob and Carol for collaboration. These documents are managed by a File Manager (FM) application. Alice accesses the FM application on one of her electronic devices to select the documents to sync. Alice specifies that she wants to share the selected documents with users for Company A / Bob and Company A / Carol. The FM application uses the storage service to create a sync group on Alice's behalf. The sync group name concatenates the sync group server name with a unique identifier. For example, the sync group name could be " / company A / sgserver / A12HJU". The FM application can set one or more permissions and prefixes for the sync group. Permissions and / or preferences can be based on Alice's preferences. For example, Alice can specify a permission "alldevices" for Carol and Bob, meaning they can join the sync group using any electronic device that is a member of each user's respective "alldevices" ACL group. For example, Alice could include all of Bob's electronic devices and all of Carol's electronic devices. Alternatively, certain electronic devices can be specified. Example licenses are shown below:

[0127]

[0128] Alice can inform Bob and Carol of the sync group name. For example, Alice can inform them of the sync group name via email, NFC communication, code scanning, or simply verbally, among other methods.

[0129] Bob and Carol can join the sync group via the FM app on their electronic devices. For example, Bob can request his electronic device, such as his laptop, to join the sync group via the FM app. Since Alice has granted Bob permission to use any of his devices to join the sync group, Bob is allowed to join the sync group as long as his laptop is a member of Bob's alldevicesACL group. The storage service can receive the names of the devices that have joined the sync group and can initiate sync operations with these devices. After syncing occurs, Bob will be able to view the documents Alice shared with him on his laptop. These files may include "Project" as a prefix.

[0130] Use Case 2

[0131] Alice wants to edit photos with her friends Dave and Carlos during a camping trip. Alice uses the FM app to store the photos she wants to share, and they are all prefixed with "Camping Trip." Alice selects the "Share -> Create" option in the folder containing these photos. The FM app presents Alice with the option to restrict the sharing of these photos to a set of user IDs. She enters v23 / Dave and v23 / Carlos to specify that these photos will be shared with Dave and Carlos. Her v23 / Alice identity is automatically added.

[0132] The FM application can use storage services to create a synchronization group on Alice's behalf. The synchronization group name concatenates the synchronization group server name with a unique identifier. For example, the synchronization group name could be " / domain / sgserver / A12HJU". The FM application can set one or more licenses and prefixes for this synchronization group. Licenses and / or preferences can be based on Alice's preferences. Example licenses are shown below:

[0133]

[0134] Since Alice is offline, the creation of the synchronization group on the synchronization group server will remain pending, and the synchronization group will be created on Alice's electronic devices. Carlos and Dave can join the synchronization group in a manner similar to that in Use Case 1 above. Alice's photos can appear on Carlos and Dave's devices, and they can synchronize their photos as long as Carlos and Dave's devices are within communication range of Alice's devices. Because the three devices have learned each other's names from both nearby and global dynamic name servers, they will continue to share data even if they return to their homes in different countries. When Alice reconnects, the creation of the synchronization group will continue and be completed on the synchronization group server. New members can join using this synchronization group server, and existing members can synchronize their metadata using this server.

[0135] Use Case 3

[0136] Alice, the developer of the Z app, wanted to provide a button that would allow her to make the app compatible with multiple devices. Alice had to indicate through the app's user interface whether she wanted her Z app to be available across her devices.

[0137] The Z application creates a new synchronization group with a name calculated based on Alice's identity (e.g., " / domain / sgserver / applicationz / v23 / Alice"), thereby using the license:<grp:domain / aclgrpserver / alice / alldevices> Use ` / applicationz:RWA` to synchronize this information.

[0138] Synchronization groups can also be created locally on her device so that other devices nearby can discover them. Therefore, if Alice has multiple devices offline (e.g., around a campfire), these devices can create and join a synchronization group without accessing the " / domain / sgserver" service. They should all already have ACL groups cached locally, allowing permission checks without accessing the "domain / aclgrpserver" service. The synchronization group prefix can be chosen by the application based on its schema and the range of entries to be synchronized across devices. On Alice's other devices, she uses the application's user interface to enable multi-device mode, triggering the application to join the synchronization group.

[0139] Use Case 4

[0140] The developer of the Z app, Alice, wanted to configure the app to share the highest score among all players. The developer decided that sharing the highest score among all players was a mandatory feature of the app. The Z app's servers created synchronization groups using a central synchronization group server.

[0141] The sync group name " / domain / sgserver / applicationz / top-scores" can now be part of the Z application after installation. These permissions allow the Z application to join: {v23 / applicationz:RW}. This means that each installed Z application requires approval in the format v23 / applicationz / Alice / D1 from the Z application's server upon registration. It will present this approval to join the sync group. The application joins this sync group the next time it runs online. Before this, this part of its database's "highest scores" table has not been synchronized. For example, the application creates / updates its "top-scores / Alice-Dl" entry to maintain the local top 10 scores. The prefix ACL on this object allows the central server local read-write (RW) access and read-only access (v23 / Alice / D1 / applicationz:RW and v23 / applicationz / applicationzadmin:R). The central server's "highest scores" folder collects the top 10 scores from all players. It is the only sync group member that can read all scores. It calculates a list of the top 10 scores globally and writes it to the "top-scores / applicationzadmin" entry. This entry is accessible to the central server via read-only mode, and all players have read-only access. This means the synchronization group has N+1 members. Alternative options are mentioned below.

[0142] All players will receive the updated global top 10 score entries, which the application will display in the user interface. Players have no control over or participation in how application Z chooses to use this synchronization group or application Z's internal scheme for collecting / reducing / broadcasting the top 10 scores for all players. No out-of-band communication is required between players, and users do not need to configure the synchronization group. All they need to do is install the application.

[0143] In an alternative embodiment, application Z can use two synchronization groups. For example:

[0144] • "Highest Score": Shared by all players, used to broadcast the scores of the top 10 globally; the server has read-only access, and all players have read-only access.

[0145] • "top-scores-Alice-D1": A per-user, per-device synchronization group consisting of the server and device Z, used by the server to collect the local top 10 scores; the server has R access permissions and the device has RW access permissions. In this case, the server will register as N.

[0146] +1 member of the sync group.

[0147] In various embodiments, a conflict may occur if an object is modified independently by two devices substantially simultaneously. The conflict is detected when some devices become aware of these two modifications during cross-device synchronization. The device that detects the conflict will, if its permissions permit, attempt to resolve the conflict by selecting between the two modifications or, presumably in some way, merging them into a new modification.

[0148] In some embodiments, the storage service may have features that allow the storage service to handle conflict resolution in the presence of an ACL. For example, an ACL might require that data written to one device not be synchronized to a second device without sufficient permissions. Instead, sufficient information is transmitted to the device to indicate that data is missing, but not what that data is. A third device might learn these changes from the second device, but not know what those changes are because the second device lacks this information. This allows the third device to detect a conflicting update, but not yet resolve the conflict. A later synchronization between the first and third devices can transmit sufficient information to fill in the gaps in the third device's knowledge and allow conflict resolution. Furthermore, a device that previously lacked permission to view specific data might be granted that permission at some point, potentially leaving information about the most recent version of the data items, but not earlier versions (because the device didn't have permission to access them when they were still up-to-date). In the presence of a modifiable ACL, these considerations result in a set of rules for handling synchronization and conflict resolution.

[0149] The basic synchronization protocol consists of an initiator requesting an increment, which conveys the initiator's current state by sending a generated vector (similar to a version vector) to the responder. Accordingly, the responder compares the initiator's generated vector with its own and sends any missing increments to the initiator, allowing the initiator to catch up to the current state. The storage service synchronizes data specified by key prefixes and allows nested synchronization groups. To support this, the basic protocol is enhanced by sending knowledge vectors instead of version vectors. Knowledge vectors consist of the generated vectors for each prefix being synchronized. Knowledge vectors allow for more efficient increment communication when a node partially updates to the latest version. For example, if a node is already in the current w / r / t prefix "foo" and wants to catch up to the prefix "f", sending a knowledge vector containing both prefixes "foo" and "f" to the node containing data with prefix "f" makes increment exchange more efficient by sending increments belonging to prefix "f" instead of increments belonging to "foo". Because key prefixes are used consistently and their hierarchy is utilized, knowledge vectors are compact.

[0150] This knowledge-based synchronization protocol can be enhanced to support security. Each synchronized data item in the storage service can be associated with a prefix ACL. All ACL objects are sent to the initiator. However, before sending an increment, the responder checks if the initiator has read permissions according to the associated ACL. If permissions are granted, the data is sent. If not, the data portion of the increment is removed (unpacked) and synchronized metadata is sent. The exchanged synchronized metadata allows the initiator to maintain the consistency of the directed acyclic graph (DAG) to detect conflicts without leaking data. Similarly, when the initiator receives an increment, it makes each update effective by verifying that the signer of the mutation has permissions to update the data according to the associated ACL. Therefore, malicious nodes cannot inject updates into the system without access. When the initiator receives data, it performs conflict detection, and if a conflict is detected, it performs conflict resolution. During conflict resolution, the initiator may be unable to access the conflicted data (shell). If the initiator needs this data to resolve the conflict, it postpones resolution and relies on nodes with more permissions to resolve such conflicts. However, if conflict resolution relies solely on synchronizing metadata (the last timestamp wins), the initiator can resolve the conflict and continue updating its storage. Other possible conflicts include ACL data conflicts or ACL-ACL conflicts. ACL-ACL conflicts can be resolved automatically by the storage service through a conservative merge strategy. In ACL data conflicts, potential strategies include acknowledging all concurrent mutations and forcing synchronization group members not to be out of sync for extended periods. Furthermore, when an ACL denies access, the denial may not be permanent. This is possible because the ACL contains groups that were initially denied access but were later allowed; or because a warning went from invalid to valid; or because an approval was renewed after its expiration; or because a new approval was obtained. In this case, each node tracks to see if any ACL changes affect its access, and if so, contacts other nodes to fill in their missing information.

[0151] Data exchange can be driven by version vectors (also known as generation vectors). Version vectors can include the version number of each device participating in the synchronization, which helps support nested and overlapping synchronization groups. During synchronization, a peer requesting an increment uses its version vector to encapsulate its current state. The peer receiving the request can compare the incoming version vector with its own version vector and send the missing version of the data. Requests for increments can be proportional to the number of devices in the system, and responses can be proportional to the increment.

[0152] In one embodiment, each generated vector can be appended to a set of data items, which can be referred to as knowledge fragments. This conveys the current version of these data items. Given that synchronization groups are defined using prefixes, knowledge can also be encoded using prefixes. Prefixes enable a compact representation of knowledge.

[0153] In one embodiment, once an increment is received, the receiver can replay the missing version history of the object and detect if any conflicting updates exist. The object history used for conflict detection can be maintained in the form of a DAG.

[0154] Data exchange protocol

[0155] In one embodiment, local updates on a device can be logged with a unique generation count. Each device can also maintain this received log during synchronization. During synchronization, a peer requesting an increment can encapsulate its current state using its version vector (the generation count for each device). The peer receiving the request can compare the incoming version vector with its own version vector and send any missing log entries.

[0156] Figure 3 An example data exchange according to an embodiment is shown. Figure 3 As shown, the example synchronization group can include devices A, B, and C, and the prefix can be set to "foo". At time t=0, device A has three updates, while devices B and C have no mutated data. Figure 3 As shown, device B (the initiator) communicates with device A (the responder) to learn any updates. Device B uses its generated vector [foo:{B:0}] to inform device A of its current state. Device A uses device B's generated vector to determine updates that device B does not yet have, i.e., by calculating the difference between device B's generated vector and device A's own generated vector. Since device A is at A:3, it can send three log entries to device B. Upon synchronization completion, device B can update its generated vector to [foo:{A:3, B:0}].

[0157] In one embodiment, after device A synchronizes with device B, device A can mutate the key and is now at A:6. B can mutate one of the keys resulting in B:1. Device C can synchronize from device B, which can inform device C of all updates it knows about from both device B itself and device A (A:3, B:1). Therefore, device C can indirectly learn updates from device A through device B.

[0158] When device B initiates communication with device A again using the generated vector [foo:{A:3, B:1}], device A can send incremental updates A:4-A:6. Therefore, communication between devices can be proportional to the size of the increments between them.

[0159] Conflict detection / resolution

[0160] In one embodiment, each synchronization log entry exchanged between devices can specify the key of the mutated object, its globally unique version, and the version from which this globally unique version is derived (i.e., its parent version). These child-parent links can be used to create a Directed Acyclic Graph (DAG) representing the mutation history of each object. Each node in the DAG can represent a version of the object. The DAG can be used to detect conflicts and record conflict resolutions.

[0161] When a parent node has multiple child nodes, conflicts may be detected because each child node represents concurrent mutations on different devices. Once the conflicts are resolved, a new version can be released, such as... Figure 4 The node shown is represented by a node with multiple parent nodes.

[0162] In one embodiment, when a conflict is detected, the resolution strategy can be provided as a triple: (local header, remote header, common ancestor). This allows the resolver to perform a three-way merge and determine a new result. The receiver can respond in one of the following ways: select the local header version, select the remote header version, or return the new version.

[0163] Return to the above reference regarding Figure 3 For example, whenever device B synchronizes with device A, device B locally replays the new updates to reconstruct the version history of the objects involved (i.e., updates the DAG of each object). At the end of the first synchronization, since device B has not changed, all updates from device A are applied without conflict. At the end of the second synchronization, since device A is the only device that has mutated keys "foo2" and "foo3", these keys do not conflict. However, key "foo1" has two simultaneous changes, and a conflict is detected. The resolver obtains data for version (B:1, A:4, A:1) and can return new data for version B:2.

[0164] For conflict resolution to eventually converge to a consistent result, it is crucial that the devices learn and piece together the same DAG structure for each known object. At different times, the devices may know different subsets of the DAG, but when they communicate the DAG fragments to each other, they eventually construct the same DAG from the fragments.

[0165] Depending on the order in which devices communicate with each other, conflict resolution may occur on some devices but not on others. To ensure the system eventually maintains consistency, devices resolve conflicts in a deterministic and convergent manner. For example, if each device chooses its own version when resolving a conflict, it could lead to an endless loop of conflict detection and resolution.

[0166] Deterministic conflict resolution is important because different devices might detect the same conflict simultaneously (e.g., the same triples mentioned above (B:1, A:4, A:1)), and each device resolves it locally before communicating with other devices. This can lead to duplicate conflict resolutions, each with its own unique version counter. When they are later swapped, some devices might still detect them as another conflict rather than a solution between equivalent conflict resolutions (from the same set of parent classes).

[0167] If the conflict resolver is deterministic, it can generate identical solution data for equivalent conflicts. In this case, synchronization can automatically resolve the conflict between duplicate solutions by deterministically selecting one of the two as the winner, without involving the application. However, if the values ​​differ, it may trigger another conflict resolution in the application, potentially leading to an endless loop of erroneous conflicts between concurrent conflict solutions. Therefore, for synchronization to converge, the following condition must be true:

[0168] • For a given object, all devices will eventually learn the same DAG.

[0169] ● All devices resolve conflicts in the same way, specifically:

[0170] ○ Deterministic: Devices that resolve the same conflict will produce exactly the same data.

[0171] ○ Interchangeable: Regardless of the order in which the two conflicting versions are discovered, the result of conflict resolution is the same.

[0172] ○ Related: Regardless of the order in which multiple conflicting changes are discovered and resolved (different intermediate solutions), the conflict resolution outcome is the same.

[0173] ○ Idempotent: The same conflicting data should generate the same resolved data, regardless of variations in the actual version.

[0174] Handling nested / overlapping prefixes

[0175] In various embodiments, the data exchange protocol described above can handle synchronization groups with nested / overlapping prefixes. In these cases, the generated vectors used in communication can be appended to specific prefixes, allowing devices to easily summarize their knowledge across different prefixes. Additionally, version numbers can be per-device, enabling comparisons across prefixes.

[0176] For example, Figure 5 Three devices (A, B, C) with the following synchronization groups are shown:

[0177] ● Synchronization group SG1, with prefix set ["foo"] and members A, B and C.

[0178] ● Synchronization group SG2, with prefix set ["f"] and members A and C.

[0179] At time t=0, device A's update log has three mutations, while device B has a mutation on the key "foo2".

[0180] Device B (the initiator) can communicate with device A (the responder) to receive updates (note that A and B know each other because they are both members of SG1). Device B initiates with a generate vector of [foo:{B:1}]. Since device B is interested in keys that begin with the prefix "foo", device A filters its changelog to obtain updates belonging to the prefix "foo". Therefore, device A replies to device B with 1 log entry (fool@A:3) and a generate vector of [foo:{A:3, B:1}]. In this way, device B keeps up-to-date with updates from device A.

[0181] Device C can initiate a request to device B with a generate vector of [foo:{C:0}]. Note that device C requests from device B the prefixes that are common to both device C and device B (because they are members of the same synchronization group). Since device B participates in SG1, it responds to all updates to the key with the prefix "foo". This includes two log entries (foo1@A:3 and foo2@B:1). Device B responds with a generate vector of [foo:{A:3, B:1, C:0}].

[0182] Device C initiates a response to device A with a generated vector of [f: {C: 0}, foo: {A: 3, B: 1, C: 0}]. For the prefix "f", device A starts from the beginning and calculates the relevant log entries (fl@A: l). For the prefix "foo", it starts calculating the increments from {A: 3, B: 1, C: 0}. Therefore, device A responds with a generated vector of [f: {A: 3, C: 0}, foo: {A: 3, B: 1, C: 0}] to keep device C up-to-date.

[0183] Note that by decomposing the knowledge (dividing it into two generating vectors, one for the prefix "f" and one for "foo"), devices A and C can communicate more efficiently. Instead of retransmitting the key for "foo" that already belongs to device C, device A sends the key for the prefix "f".

[0184] Device A sends a generated vector to device C with the format [f, foo: {A: 3}]. Device C calculates the increment and sends (foo2@B: 1) back to device A with the generated vector [f: {A: 3, C: 0}, foo: {A: 3, B: 1, C: 0}]. Therefore, device A can indirectly catch up with device B's update to the "foo" prefix through device C.

[0185] However, note that even when "foo" is a subset of "f", device C cannot compress the knowledge it has learned (i.e., learn [f, foo: {A: 3, B: 1, C: 0}]). This is because it has no way of knowing what the state of device B is for the prefix f.

[0186] For example, there can be a device D that is a member of SG2. When device D communicates with devices A or C, it learns the segmented knowledge [f: {A: 3, C: 0}, foo: {A: 3, B: 1, C: 0}]. Therefore, when synchronizing with the prefix "f" which has nested synchronization groups on "foo", members of the "f" synchronization group see the generated vector on the subset of "foo". However, members of the "foo" synchronization group will not see the existence of the "f" synchronization group.

[0187] ACL visibility

[0188] Fine-grained ACLs can be defined on a key prefix and applied to a range of keys, including those not yet created. These ACLs can also be synchronized using a p2p protocol to allow execution across all devices. When an ACL denies a device read access to data, no data is sent (see Protocols below). However, the ACL itself can be sent to the device so that it can locally block applications from accessing storage within the ACL's scope, allowing the storage service to provide the expected application behavior.

[0189] If no ACL is sent, the storage service on that device will allow the application to create data objects and other ACLs within that ACL's scope, or even different versions of the same ACL. This will logically split the synchronization group, forming non-converging synchronization sub-branches. This will confuse application developers and make debugging more difficult. For this reason, the protocol can send all ACLs to all devices in the synchronization group and use the ACLs to deny certain devices access to ACL-protected data, while providing visibility into why data access was denied. All devices in the synchronization group will see and enforce the same data access rules. While this scheme may leak the existence of keys to members who are not authorized to access them, the keys are likely to be a series of UUIDs. Row keys have no significance other than their existence.

[0190] Alternatively, for added protection, ACLs can be anonymous, and access denial can be communicated to the device instead of sending the entire ACL.

[0191] Heisen-ACLs

[0192] It is possible to create approvals and ACLs that allow ACL checks to change results even without an ACL or if the approval has been modified. Currently, this can happen in the following ways:

[0193] ●ACL uses groups: Group membership is changed on the ACL group server.

[0194] ●Approval comes with a warning:

[0195] ○ Time-based warnings: For example, approvals are valid from 95 working days in a week.

[0196] ○ Third-party warning: For example, approval is valid when the device is near certain other devices.

[0197] ○Expiration warning: For example, the approval is valid for 24 hours.

[0198] Such ACLS are called Heisen-ACLs. Even warnings such as expiration warnings are not limited to a change from "permitted" to "denied". Expired approvals can be renewed, thus regaining access. Because these ACLs can be subject to uncertainty, the name Heisen-ACL is a pun on Heisenberg's uncertainty principle.

[0199] Enhanced Data Exchange Protocol: "Shell"

[0200] Log records exchanged during synchronization can contain references to the ACL of that object version. If that ACL denies read access to devices belonging to the synchronization group, the object mutation cannot be sent as is. However, some information can be sent to instruct devices to lose access to the object, and as previously mentioned, the DAG structure can also be maintained.

[0201] In this scenario, the sent log record might be stripped to remove object data, thus becoming a shell of the log record itself. This is called sending a DAG shell, rather than a regular full DAG node. The shell can contain one or more of the following:

[0202] ●Object Key

[0203] • Object version

[0204] ●Parent version of the object

[0205] ● References to the specific ACL version controlling this object

[0206] • Indicates it is a Boolean symbol for a shell record.

[0207] The shell can inform the receiving device that the object is no longer visible to its application. The storage service updates the ACL in storage that blocked the application from accessing the object. If the ACL is later changed to re-enable access to the device, the ACL will receive the new mutation as a regular full DAG node, and the storage service will update the object, its new data, and the ACL in storage to make it visible to the application.

[0208] In one embodiment, for objects that are not visible to some devices from the outset, the protocol may send a shell that has been further stripped to remove the object key and its parent version, retain the object version, and references to specific ACL versions controlling the object and boolean flags. This avoids exposing the existence of the object key, which contains application metadata, to devices that are unaware of the key and have not yet gained access. This simplified shell contains enough information (i.e., the object version) to allow the storage service to attempt to re-extract the data to check if it has access rights and to delay sharing the object key until access rights are granted. Figure 6 An example of object visibility / invisibility transformation according to an embodiment is shown.

[0209] Conflict detection and solutions using shells

[0210] The presence of a shell in a DAG can affect conflict detection and resolution. plan This can cause divergence. For example, if the shell is the common ancestor of the conflict, and it is known that the resolver requires the common ancestor, conflict resolution can be skipped on that device. plan Accessing this common ancestor requires the eventual resolution of the conflict. In practice, the object DAG on the device remains "open" with dangling fragments that are not merged by the local header version until another device resolves the conflict and sends back the resulting DAG fragment to be merged with the object DAG. The device can continue to make progress on its own object version and will also learn mutations derived from the other header (dangling fragment), but it cannot bind the two fragments together and resolve the conflict itself.

[0211] As another example, if the shell is a common ancestor, but the conflict resolver does not need it (e.g., the last timestamp won), then conflict resolution is complete.

[0212] As another example, if the shell is a local header or a remote header, there is an ACL data conflict or

[0213] ACL-ACL conflict: One device changes its data or ACL, while another device simultaneously changes its ACL (or possibly its data) to deny read access to this device. The solution is skipped and left to another device that can see both changes to decide how to resolve the conflict.

[0214] Conflict resolution will not occur on objects with incomplete information because it may violate the convergence requirement of resolving the same conflict in the same way on any device. Devices with incomplete knowledge will postpone the solution to other devices.

[0215] Devices can request and accept synchronization updates from other devices allowed in a synchronization group according to the synchronization group ACL (membership authentication). Incoming data, full nodes, and shells can be attached to the DAG. Access to each data object can be protected by setting a prefix ACL object (the object with the longest matching prefix), and the ACL object is also synchronized (similar to data objects using full nodes or shells).

[0216] Conflict resolution between ACL object versions can be addressed first. Given that the storage service has a known ACL scheme, conflict resolution is automatically performed based on the policy selected when creating the synchronization group.

[0217] When resolving conflicts between data objects, consider setting up ACLs to determine whether remote versions should be visible to the local device or ignored.

[0218] Re-extract the shell and elevate it to a complete DAG node.

[0219] Since most sophisticated ACLs are Hessian ACLs, access denials may be transient, and access may be granted if the ACL check is retried later (e.g., a time-based or location-based warning). This is important for shells that play a significant role in a DAG, such as being the head node of a non-conflicting DAG segment, another head node in a DAG conflict, or a common ancestor of a conflict that requires a common ancestor to resolve (as opposed to policies like the last winner not requiring an ancestor).

[0220] The storage service can track a subset of DAG shells it deems important and request the next device it synchronizes with to re-examine access permissions for those specific mutations. The storage service can do this by sending a list of past mutation versions to be extracted, along with a generated vector and the new increment for logging. The responding device can use this generated vector to calculate the increment. If the requesting device passes the ACL check this time, it may add any past logging to this regular response.

[0221] In practice, this action fills in missing information for some shells, promoting them from shells to complete DAG nodes. The receiving device can take appropriate actions, such as resolving still pending conflicts and updating the head node value and the head node in storage. Optionally, the protocol can request all shell nodes, rather than just those deemed important.

[0222] The list of past variants can be encoded to reduce the number of bytes on the line (the size of the request): (1) run length encoding or compression, (2) using a two-round round trip, sending the list of previously rejected ACLs in the first round to determine which are now allowed, and sending the list of past variants that match the newly allowed ACLs in the second round trip.

[0223] Figure 7 A block diagram depicts hardware that can be used to contain or implement program instructions. Bus 700 serves as an information highway interconnecting other illustrated components of the hardware. Processor (CPU) 705 is the central processing unit of the system, performing computational and logical operations to execute programs. CPU 705 is an example of a production device, computing device, or processor, as used in this disclosure. Read-only memory (ROM) 710 and random access memory (RAM) 715 constitute examples of non-transitory computer-readable storage media.

[0224] The controller 720 is connected to the system bus 700 with one or more optional non-transitory computer-readable storage media (i.e., memory devices 725). These storage media may include, for example, external or internal DVD drives, CD-ROM drives, hard disk drives, flash memory, USB drives, etc. As previously mentioned, these various drives and controllers are optional devices.

[0225] Program instructions, software, or interactive modules used to provide an interface and execute any queries or analyses associated with one or more datasets may be stored in ROM 710 and / or RAM 715. Optionally, program instructions may be stored on the storage medium 725 discussed above.

[0226] Optional display interface 730 allows information from bus 700 to be displayed on monitor 735 in audio, visual, graphic, or alphanumeric format. Various communication ports 740 can be used for communication with external devices such as printing equipment. Communication port 740 can be attached to a communication network, such as the Internet or intranet.

[0227] The hardware may also include an interface 745 that allows data to be received from input devices such as a keyboard 750 or other input devices 755 such as a mouse, touchpad, touch screen, remote control, pointing device, video input device and / or audio input device.

[0228] The above-described features and functions, as well as alternatives, can be combined into many other different systems or applications. Various substitutions, modifications, variations, or improvements can be made by those skilled in the art, each of which is also intended to be covered by the disclosed embodiments.< / sgname>

Claims

1. A method for synchronizing offline data in a computing system, characterized by, comprising: receiving, at a server associated with a storage service, a request from an application to create a synchronization group associated with a plurality of member electronic devices; generating, at the server, the synchronization group, the synchronization group having one or more sets of data prefix-access control lists, the one or more data prefix-access control lists providing an indication specifying a subset of data to be synchronized and / or an access control list, receiving, at the server, one or more objects stored by the storage service to be shared by the plurality of member electronic devices; receiving, at the server, an indication that a first member electronic device modified a first object of the one or more objects while the first member electronic device was operating offline, and synchronizing, by the server, one or more storage devices on one or more other member electronic devices of the synchronization group such that the first object of the one or more storage devices is updated to include the modifications made to the first object by the first member electronic device.

2. The method of claim 1, wherein, the first member electronic device maintains a local log recording modifications to the first object while operating offline.

3. The method of claim 2, wherein, the local log associates a unique generation number with a modification of a given data object.

4. The method of claim 3, wherein, the indication received at the server includes the unique generation number.

5. The method of claim 1, wherein, the indication received at the server includes a unique generation number retrieved from local storage on the first member electronic device.

6. The method of claim 1, wherein, the synchronization group includes metadata defining permissions associated with the plurality of member electronic devices.

7. The method of claim 6, wherein, the permissions define membership in the synchronization group based on a particular application.

8. The method of claim 7, wherein, the particular application is one of an online gaming application, a document sharing application, or a photo editing application.

9. A system for synchronizing offline data in a computing system, the system comprising: comprising: a memory storing instructions; one or more computing devices coupled to the memory, the instructions causing the one or more computing devices to operate as a server providing a storage service, the server, when operating using the instructions, to: receive, from an application, a request to create a synchronization group associated with a plurality of member electronic devices, generate the synchronization group, the synchronization group having one or more sets of data prefix-access control lists, the one or more data prefix-access control lists providing an indication specifying a subset of data to be synchronized and / or an access control list, receive one or more objects stored by the storage service to be shared by the plurality of member electronic devices; receive an indication that a first member electronic device modified a first object of the one or more objects while the first member electronic device was operating offline, and synchronize one or more storage devices on one or more other member electronic devices of the synchronization group such that the first object of the one or more storage devices is updated to include the modifications made to the first object by the first member electronic device.

10. The system of claim 9, wherein, the first member electronic device maintains a local log recording modifications to the first object while operating offline.

11. The system of claim 10, wherein, the local log associates a unique generation number with a modification of a given data object.

12. The system of claim 11, wherein, the indication received at the server includes the unique generation number.

13. The system of claim 9, wherein, The indication received at the server includes a uniquely generated number retrieved from local storage on the first member electronic device.

14. The system of claim 9, wherein, The synchronization group includes metadata defining permissions associated with the plurality of member electronic devices.

15. The system of claim 14, wherein, The permissions define membership in the synchronization group based on a particular application.

16. The system of claim 15, wherein, The particular application is one of an online gaming application, a document sharing application, or a photo editing application.

Images