KR102084014B1 - Method and system for data type based multi-device synchronization - Google Patents

Abstract

A method and system for data type based multi-device data synchronization is disclosed. The data synchronization method in a computer-implemented server may include performing data synchronization using a data type synchronized with an operation for a plurality of clients sharing a data type in a multi-device environment. The performing of the data synchronization may include managing the operation of the data type by reflecting a physical time according to the generation of the operation.

Description

METHOD AND SYSTEM FOR DATA TYPE BASED MULTI-DEVICE SYNCHRONIZATION}

The description below relates to a technique for data synchronization of multiple devices.

As mobile and IoT devices become widespread, frequent data synchronization with databases on the server side is essential. Data synchronization is important for the quality of the application and requires many lines of code on the server as well as on the client.

For example, Korean Patent No. 10-1140603 (Registration Date April 20, 2012) discloses a technology for performing data synchronization between a database of a client and a database of a server.

Traditional systems, such as databases, are not suitable solutions for data synchronization across multiple devices because they focus primarily on storing large amounts of data on the server side and querying on the client side.

When using a data system such as a database for data synchronization of multiple devices, application or service developers should periodically read values from the server and manage conflict issues directly against local changes.

If the server fails to read every time a change is made, it is difficult to synchronize as desired because it does not consider all the changes made by multiple clients or because it does not know what operations the client has performed.

By exchanging (pushing / pulling) operations between clients and servers, you can resolve conflict issues by considering operations that occur at the same time. Provided are a method and a system for synchronizing data to have a state of a data type.

A data synchronization method in a computer-implemented server, the method comprising: performing data synchronization using a data type synchronized with an operation to a plurality of clients sharing a data type in a multi-device environment The data synchronization method may include the step of managing the operation of the data type by reflecting a physical time according to the generation of the operation.

According to an aspect, the performing of the data synchronization may perform data synchronization by exchanging an operation of the data type with the client.

According to another aspect, a push-pull operation on an operation of the data type occurs as the client attaches the data type, and the client detaches the data type as the data type is detached. There is no push-pull action for the operation.

According to another aspect, the performing of data synchronization may include: receiving operations of the data type from the client in a generation order; And filtering a duplicate operation among the received operations.

According to another aspect, the performing of data synchronization may include: a client sequence updated each time the client generates an operation of the data type, and each time the server receives an operation of the data type from the client. Identifying the operation of the data type using the updated server sequence.

According to another aspect, the step of performing data synchronization is a push operation for an operation of the data type, the server sequence most recently received from the server by the client from the client and the client most recently updated at the client. Receiving a checkpoint comprising the sequence; And transmitting a checkpoint to the client, the checkpoint comprising a server sequence most recently updated by the server and a server sequence most recently received from the client in a pull operation for the operation of the data type. have.

According to another aspect, the client may transmit the missing operation to the server along with the next operation based on the checkpoint received from the server.

According to another aspect, the performing of the data synchronization may further include filtering a duplicate operation among operations received from the client by comparing a checkpoint exchanged with the client at the server.

According to another aspect, the performing of the data synchronization may include transmitting a snapshot of the data type to the client for data synchronization at the request of the client.

According to another aspect, the physical time may increase when at least one of a condition in which a predetermined number of operations are newly received for each data type and a condition in which a predetermined time is physically passed.

According to another aspect, the performing of the data synchronization may include: managing the operation of the data type by reflecting the physical time together with the logical time according to the operation generation; And determining the priority of the operation by considering the physical time prior to the logical time with respect to the operation of the data type.

In combination with a computer there is provided a computer program stored on a computer readable recording medium for carrying out the method on the computer.

A data synchronization system of a computer-implemented server, comprising: at least one processor configured to execute computer-readable instructions, the at least one processor to a plurality of clients sharing data types in a multi-device environment. For example, the process of performing data synchronization using a data type synchronized with an operation may be performed. The process of performing data synchronization may include managing the operation of the data type by reflecting a physical time resulting from an operation. To provide a data synchronization system of a server implemented by a computer.

According to embodiments of the present invention, by exchanging (pushing / pulling) operations between a client and a server, a conflict problem may be solved by considering operations that occur at the same time. Can have state.

According to embodiments of the present invention, the nature of the consistent data type synchronized with the operation allows the client to synchronize the replicated data type with the operation to ensure high availability and ultimate consistency and back-end end) A server implemented as a service can effectively exchange many data type operations with large clients.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention.
2 is a block diagram illustrating an internal configuration of an electronic device and a server according to an embodiment of the present invention.
3 illustrates an example of a client architecture for data type based data synchronization according to an embodiment of the present invention.
4 illustrates an example of a server architecture for data type based data synchronization according to an embodiment of the present invention.
5 through 6 illustrate examples of push-pull operations that follow a push rule and a pull rule in an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

Embodiments of the present invention relate to techniques for data synchronization of multiple devices.

Embodiments, including those specifically disclosed herein, may implement a data type based data synchronization technology for facilitating the creation of an application or a service requiring data synchronization in a multi-device, thereby providing usability and convenience. Significant advantages are achieved in terms of accuracy, efficiency, and cost savings.

1 is a diagram illustrating an example of a network environment according to an embodiment of the present invention. The network environment of FIG. 1 illustrates an example including a plurality of electronic devices 110, 120, 130, and 140, a plurality of servers 150 and 160, and a network 170. 1 is an example for describing the present invention, and the number of electronic devices or the number of servers is not limited as shown in FIG. 1.

The plurality of electronic devices 110, 120, 130, and 140 may be fixed terminals or mobile terminals implemented as computer devices. Examples of the plurality of electronic devices 110, 120, 130, and 140 include smart phones, mobile phones, tablet PCs, navigation systems, computers, notebook computers, digital broadcasting terminals, personal digital assistants (PDAs), and PMPs ( Portable Multimedia Player). For example, the first electronic device 110 may communicate with other electronic devices 120, 130, 140 and / or the server 150, 160 through the network 170 using a wireless or wired communication scheme.

The communication method is not limited, and may include not only a communication method using a communication network (for example, a mobile communication network, a wired internet, a wireless internet, and a broadcasting network) that the network 170 may include, but also a short range wireless communication between devices. For example, the network 170 may include a personal area network (PAN), a local area network (LAN), a campus area network (CAN), a metropolitan area network (MAN), a wide area network (WAN), and a broadband network (BBN). And one or more of networks such as the Internet. The network 170 may also include any one or more of network topologies, including bus networks, star networks, ring networks, mesh networks, star-bus networks, trees, or hierarchical networks, but It is not limited.

Each of the servers 150 and 160 communicates with the plurality of electronic devices 110, 120, 130, and 140 through the network 170 to provide a command, code, file, content, service, or the like. It may be implemented in devices.

For example, the server 160 may provide a file for installing an application to the first electronic device 110 connected through the network 170. In this case, the first electronic device 110 may install an application using a file provided from the server 160. In addition, the server 150 is provided by accessing the server 150 under the control of an operating system (OS) included in the first electronic device 110 or at least one program (for example, a browser or the installed application). Can be provided with services or content. For example, when the first electronic device 110 transmits a service request message to the server 150 through the network 170 under the control of the application, the server 150 transmits a code corresponding to the service request message to the first. The electronic device 110 may transmit the content to the electronic device 110, and the first electronic device 110 may provide content to the user by configuring and displaying a screen according to a code under the control of an application.

2 is a block diagram illustrating an internal configuration of an electronic device and a server according to an embodiment of the present invention. 2 illustrates an internal configuration of the first electronic device 110 as an example of one electronic device and the server 150 as an example of one server. Other electronic devices 120, 130, 140 or server 160 may also have the same or similar internal configuration.

The first electronic device 110 and the server 150 may include memories 211 and 221, processors 212 and 222, communication modules 213 and 223, and input / output interfaces 214 and 224. The memories 211 and 221 may be computer-readable recording media, and may include a permanent mass storage device such as random access memory (RAM), read only memory (ROM), and a disk drive. In addition, the memory 211 and 221 may store an operating system or at least one program code (for example, a code for an application installed in the first electronic device 110 and driven). These software components may be loaded from a computer readable recording medium separate from the memories 211 and 221. Such a separate computer-readable recording medium may include a computer-readable recording medium such as a floppy drive, a disk, a tape, a DVD / CD-ROM drive, a memory card, and the like. In other embodiments, the software components may be loaded into the memory 211, 221 through the communication module 213, 223 rather than a computer readable recording medium. For example, the at least one program is a program installed by files provided by the file distribution system (for example, the server 160 described above) through the network 170 for distributing installation files of developers or applications (for example, It can be loaded into the memory (211, 221) based on the above-described application).

Processors 212 and 222 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input / output operations. Instructions may be provided to the processors 212, 222 by the memory 211, 221 or the communication modules 213, 223. For example, processors 212 and 222 may be configured to execute instructions received in accordance with program codes stored in recording devices such as memories 211 and 221.

The communication modules 213 and 223 may provide a function for the first electronic device 110 and the server 150 to communicate with each other through the network 170. The other electronic device (eg, the second electronic device 120) may be provided. ) Or other server (eg, server 160). In one example, a request (eg, a search request) generated by the processor 212 of the first electronic device 110 according to a program code stored in a recording device such as the memory 211 is controlled by the communication module 213. It may be delivered to the server 150 through 170. Conversely, control signals, commands, contents, files, and the like provided according to the control of the processor 222 of the server 150 are transmitted to the communication module of the first electronic device 110 via the communication module 223 and the network 170. It may be received by the first electronic device 110 through 213. For example, the control signal or command of the server 150 received through the communication module 213 may be transmitted to the processor 212 or the memory 211, and the content or the file may be transmitted to the first electronic device 110. May be stored as a storage medium that may further include.

The input / output interface 214 may be a means for interfacing with the input / output device 215. For example, the input device may include a device such as a keyboard or mouse, and the output device may include a device such as a display for displaying a communication session of the application. As another example, the input / output interface 214 may be a means for interfacing with a device in which functions for input and output are integrated into one, such as a touch screen. More specifically, the processor 212 of the first electronic device 110 uses data provided by the server 150 or the second electronic device 120 in processing a command of a computer program loaded in the memory 211. The service screen or content configured to be displayed on the display may be displayed through the input / output interface 214. Similarly, the input / output interface 224 may output information configured using data provided by the server 150 when the processor 222 of the server 150 processes a command of a computer program loaded in the memory 221. have.

In addition, in other embodiments, the first electronic device 110 and the server 150 may include more components than those of FIG. 2. However, there is no need to clearly show most prior art components. For example, the first electronic device 110 may be implemented to include at least a part of the above-described input / output device 215 or may be other such as a transceiver, a Global Positioning System (GPS) module, a camera, various sensors, a database, or the like. It may further include components. More specifically, when the first electronic device 110 is a smartphone, an acceleration sensor, a gyro sensor, a camera, various physical buttons, a button using a touch panel, an input / output port, and vibration for a smartphone generally include It can be appreciated that various components such as a vibrator may be implemented to be further included in the first electronic device 110.

Hereinafter, a specific embodiment of a method and a system capable of performing data type based data synchronization in a multi-device environment will be described.

The data synchronization system according to the present invention is implemented in a multi-device environment, and may include a plurality of clients and servers 150 implemented in the electronic devices 110, 120, 130, and 140 as multi-devices.

The server 150 allows multiple clients of multiple devices to synchronize different types of data types. Clients can replicate data types locally and read only their own replicas. If some local operation modifies the data type, the data type is executed immediately and pushed to the server 150. On the other hand, if some remote operation is released from the server 150, the data type is executed as soon as possible. Replicated data types from multiple clients must execute the same set of operations, but they do not have to be executed in the same order unless a causal relationship is violated during the operation. In order to maintain consistency for mismatched operation sequences, data types may be implemented according to the theory of Conflict-free Replicated Data Type (CRDT), which will be described below.

Persistent repositories such as databases follow the CRUD model, which provides four basic functions: create, read, update, and delete. These functions are defined between a single client and server and tend to move from the client to the server where the original data is located.

In the present invention, an APPD (attach, push-pull, detach) model is introduced and applied to data type sharing, and this model facilitates dual transmission of operations for efficient multi-device synchronization of replicated data.

In the data synchronization system according to the present invention, a client must attach a data type in order to create new data or share a data type stored in the server 150. Attaching a data type means that all operations on the data type are subsequently pushed-pull. Push-pull no longer occurs when a client detaches an attached data type. Comparing the CRUD model, the APPD model does not provide a read function to the server 150 because the client always reads the locally attached replica. In addition, the present invention pushes the create operation after attaching to perform the 'create' function, and push the delete operation to replace the 'delete' function with detaching (detaching).

In the data synchronization system according to the present invention, the client may be designed to maintain high availability with low latency, and the server 150 may be designed to have high scalability. Due to the nature of the CRDT, clients can access the attached (replicated) data type offline, which can naturally result in low latency. The client is stateful, while the server is stateless to support scale out to handle huge push-pull of clients.

The data synchronization system according to the present invention may implement a CRDT. CRDTs can maintain eventual consistency without intervention to resolve conflicting issues, even if replicated data types execute operations in different orders. Depending on how to maintain consistency, CRDTs can be divided into operation-based and state-based CRDTs. Despite network partitions, CRDT can guarantee high availability and low latency, and the same set of operations can be consistent as a result.

Most theories of CRDT assume that the operation is delivered in a peer-to-peer (P2P) manner, but the present invention provides a stable push-to-client between the client and server because the applications and services used must guarantee responsibility and stability for shared data. It can be implemented as a back-end service through a pull mechanism.

In the present invention, various multi-device data synchronization implementations can be improved. For example, when a user adds a bookmark to a browser of a specific device, the bookmark should be displayed in all user browsers of another device. Browser developers can accomplish this by using code that applies some operations to the data types that manage bookmarks, thereby pushing or pooling the operations associated with adding bookmarks.

In the present invention, a few including replicated fixed-size arrays (RFAs), replicated hash tables (RHTs), and replicated growable arrays (RGAs) belonging to an operation-based CRDT. There are several kinds of data types you can implement. Operations of these data types can be designed according to two consistency principles: (1) operation commutativity and (2) precedence transitivity. In order to use this, the present invention uses a logical logical time.

The concept of snapshot and epoch may be applied to introduce a CRDT to the data synchronization system according to the present invention. First, even though CRDT is derived from real-time collaborative editing, snapshots can be used to allow intermittent (or periodic) synchronization as well as real time. If synchronization of data types is very frequent or lasts a long time, a large amount of operations can accumulate. If all synchronization is done only with accumulated operations, it is inefficient, so you can use a snapshot of the data type to reduce this inefficiency. Second, because the logical time itself in data synchronization sometimes distorts intermittent synchronization, the logical time can be corrected to a physical time called epoch. Epoch can also be used for garbage-collect of tombstones required for RHTs and RGAs for deleted elements.

First, a detailed system architecture for exchanging (pushing / pulling) operations between a client and a server is described.

3 illustrates an example of a client architecture for data type based data synchronization according to an embodiment of the present invention.

The server 150 or 160 may provide a client software development kit (SDK) that can be used to implement various applications that share data types in multiple devices. As shown in FIG. 3, a number of data types 310 are attached to the client 300, and the client 300 may store local or remote operations of the data type 310 in the local storage 302. Store them in and synchronize them with the server 150. For efficient management, the client 300 may include one sync agent 301 and a local repository 302 that are shared by several data types 310.

When data type 310 creates a local operation through the operation APIs, it is converted into an operation instance with the parameters required for execution. All operations separately define the behavior of local and remote executions based on the characteristics of the CRDT. The locally created operation instance may be executed by an operation executor of data type 310 and then stored in a local operation buffer of limited size and also stored in local storage 302 of client 300. .

The local store 302 keeps the client state for data synchronization, which means that the client 300 has offline capabilities. Since a snapshot of all data types 310 is stored at a specific point and subsequent operations are also stored in local storage 302, client 300 can restore the last state of data type 310 without synchronization with server 150. Can be.

The sink agent 301 is responsible for synchronizing with the server 150. The newly created operation of the data type 310 attached to the client 300 is compressed into a single push data, which is collected in the local operation buffer or local storage 302 of that data type 310. Whenever the sink agent 301 sends push data to the server 150, pulled data for the attached data type 310 is received in response. This may deliver the remote operation to the corresponding data type 310 which executes the remote operation in order. The sink agent 301 executes all remote operations pulled from the server 150 and then informs all registered handlers of the event and stores it in the local repository 302.

The client 300 may provide the sink agent 301 of the passive type and the real time type, and may selectively apply one of the two types. The client 300 having the passive type sink agent 301 performs the push-pull operation of the above process every time a sync function is called. Meanwhile, the real-time type sink agent 301 may perform a push-pull operation as soon as some local operations are newly generated. In addition, push-pull operation is invoked whenever the real-time type of sink agent 301 receives a notification indicating that some remote operation is pushed out of the server 150.

4 illustrates an example of a server architecture for data type based data synchronization according to an embodiment of the present invention.

The server 150 is a data synchronization system for data synchronization of multiple devices, and is designed to handle a huge amount of push-pull operations. In the present invention, the server 150 may be implemented in a stateless state to achieve horizontal scalability, that is, scale-out. Server 150 must respond to the pull data as output for push by reading and storing state from scalable database 401.

As shown in FIG. 4, when push data is distributed to any server node 410 through a network switch (eg, L4), the aggregator thread of the server node 410 is push data of various data types. Are separated into push data of separate data types, and each thread can be processed in parallel. In each push operation, the operation is stored in the database 401 and some operations taken from the database 401 are compressed into pull data. The compressed pool data is then aggregated and sent to the client 300.

The server 150 can process in one push-pull operation in parallel belonging to different data types. However, because push operations that occur concurrently for the same data type can affect each other in pulling operations, the present invention handles serializing push data for the same data type using a distributed lock. can do.

Server 150 should keep snapshots of all data types as current as possible. Accordingly, each server node 410 may periodically update a snapshot of the data type that receives the new operation.

Next, a detailed operation exchange (push-pull) process between the client 300 and the server 150 will be described.

Since the client 300 maintains a state, the client 300 may determine an operation to be push-pulled according to the state. Accordingly, the server 150 should track the push-pull status with respect to the data type attached by the client 300. That is, the server 150 should record information about which client attaches which data type and the number of operations pushed or pulled from the client. Based on this, the push-pull mechanism must satisfy the following two conditions.

(1) The server 150 and the client 300 must receive all the operations generated by all the clients in order.

(2) The server 150 and the client 300 should filter out duplicate operations.

To satisfy the above two conditions, each data type of every client must maintain a client sequence (cseq), and the server 150 must maintain a server sequence (sseq) for each data type. Each time an operation is associated with a client 300 or a server 150, the client sequence cseq and the server sequence sseq are updated and the operation may be identified by the sequences described above. The client sequence (cseq) is incremented by 1 each time the data type of the client 300 generates a local operation, and the server sequence (sseq) is incremented by 1 each time the server 150 receives an operation on the data type. do.

To track push-pull data, a check point (CP), which is a pair of client sequences (cseq) and server sequence (sseq) (cseq, sseq), can be used. For all data types attached, server 150 and client 300 may maintain a CP _server and a CP _client indicating a push-pull state as follows: CP _server [sseq] indicates that server 150 is a client. The most recent sequence sent to the 300, CP _server [cseq] is the most recent sequence that the server 150 received from the client 300, CP _client [sseq] is the most recent client 300 received from the server 150 The latest sequence, CP _client [cseq] means the most recent sequence that the server 150 confirms receipt.

Depending on the client sequence (cseq), server sequence (sseq), client checkpoint (CP _client ), and server checkpoint (CP _server ), each push and pull action loads some operations and pushes a push checkpoint (CP _PUSH) as shown below. ) And the full check point (CP _PULL ).

(1) push rules

Push operation loads operations from CP _client [cseq] +1 to cseq.

The check point (CP _PUSH ) for the cseq of the most recent operation in this push operation is (CP _client [sseq], cseq).

(2) full rules

The pull operation loads the remote operation for the client 300 from CP _PUSH [sseq] +1 to cseq.

The check point CP _PULL for the sseq of the server 150 immediately after the corresponding push operation is (sseq, CP _server [cseq]).

5 illustrates an example of a push-pull operation that follows a push rule and a pull rule according to an embodiment of the present invention.

Referring to FIG. 5, the client 300 first updates the client sequence (cseq = 1) when the data type generates an operation and calculates a checkpoint (CP _{PUSH # 1} : (0,1)) for the operation. To push to the server 150.

Accordingly, when the server 150 receives an operation for a data type from the client 300, the server 150 updates the server sequence (sseq + 1) and checkpoint (CP _{PULL # 1} :() for the corresponding server sequence (sseq + 1). 1) and 1)) to respond to the pull for the push of the client 300 by passing it to the client 300.

It can be seen that the push rule and the pull rule applied in the above process guarantee two conditions of the aforementioned push-pull mechanism.

As shown in FIG. 5, even though some pushes PUSH # 2 are lost, subsequent pushes PUSH # 3 do not have a PULL that is a response to the push PUSH # 3, and thus the client checkpoint CP _client is not updated. In this case, two operations (cseq = 2, 3) can be sent together in a subsequent push (PUSH # 3). In other words, if some PULLs are missing, the next PUSH derives a PULL containing the operation of the missing PULL.

In the push-pull mechanism according to the present invention, redundant operation transmission may be considered. For example, as illustrated in FIG. 5, PUSH # 4,5 may be repeatedly transmitted for an operation of cseq = 4 (cseq = 4). At this time, when the server 150 receives the PUSH # 5, the operation of cseq = 4 is rejected because the server check point CP _server [cseq] is already 4. Nevertheless, PUSH # 5 loads operations based on CP _{PULL # 5} [sseq] = 4. When the client 300 receives CP _{PULL # 5} , only one operation of sseq = 7 is allowed by comparing CP _{PULL # 5} : (7,4) with CP _client : (6,4).

The data synchronization system according to the present invention supports real time synchronization, which means that the server 150 should be able to inform each client 300 of the arrival of a new operation. It is simple for the server 150 to know the arrival of a new operation based on the server checkpoint (CP _server ) and the server sequence (sseq). CP _server [sseq] <sseq. Therefore, upon receiving a new operation, the server 150 transmits CP _notify = (sseq, CP _server [sseq]) to each client 300 as a notification of the reception of the operation. Accordingly, as soon as the sink agent 301 of the client 300 receives the notification from the server 150, the push agent may be called.

In general, CRDTs operate according to operation and logic time, but are not always reasonably efficient in a real service. Accordingly, the present invention proposes two concepts, a snapshot and an epoch.

Because of the hassle of maintaining all operations for all data types in the server 150, the server 150 may manage operations cut-off in chronological order. When the client 300 resumes push-pull after the client 300 attaches a new data type or a large number of operations have been pushed, an operation older than the one stored in the server history as shown in FIG. '+1 <n) may be required. In this case, the server 150 returns the latest snapshot (SNAP _{# 1} ) to CP _{PULL # 1} and the client 300 receives the data type with the snapshot (SNAP _{# 1} ) received from the server 150. Can be replaced. The client 300 must then reproduce the local operation from what was pushed.

In addition, some data types generally allow commutativity to establish non-causal operations based on logical time stamps. The logical time is in accordance with the occurrence of the operation, so the actual time is not important. When the client 300 supports the passive sink agent 301, there is a possibility that a physically old operation is considered a new operation. For this reason, the present invention may apply a physical time unit called an epoch that increases in the server 150 together with a logical time concept. For each data type, increase the epoch if at least one of the following conditions has been met since the last increase of the epoch: (1) more than a certain number (k) operations are pushed anew and (2) a fixed time (h hour) This physically increases the epoch. As shown in FIG. 6, all of the PUSH is in the epoch of the client 300, but the corresponding PULL returns the epoch of the server 150 updating the client 300. The epoch may be considered in advance to determine the operation priority before comparing the logical time stamps of the operations.

Two operations of some different epoch mean that several operations have been pushed in between, so the operation of the previous epoch may not be appropriate for the situation. In this sense, the server 150 rejects the operation of the epoch less than the current server epoch (ep) minus the fixed integer (E) (ep-E). Instead, as shown in PUSH _{# 2} -PULL _{# 2} shown in FIG. 6, the server 150 may send PULL back to the latest snapshot and reset the snapshot of the client 300.

The policy of rejecting old epoch operations can be used for garbage collect tombstones of tombstones. Tombstones can be safely collected by ensuring that future operations on data types originating from RHTs and RGAs no longer reference tombstones.

As described above, according to the embodiments of the present invention, the data synchronization system may be configured as a back-end server to efficiently support the synchronization of a large client operating in multiple devices. Moreover, according to embodiments of the present invention, it is possible to provide a reliable operation transport mechanism by push-pulling operations without omission and duplication for large data types in the server-client model. In addition, according to embodiments of the present invention, by adding a physical time concept (epoch) to the logical time, it is possible to solve the conflict problem between operations occurring during synchronization and to eliminate unnecessary metadata of the data type.

The apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components. For example, the devices and components described in the embodiments may include a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable PLU (programmable). It can be implemented using one or more general purpose or special purpose computers, such as logic units, microprocessors, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to the execution of the software. For convenience of explanation, one processing device may be described as being used, but one of ordinary skill in the art will appreciate that the processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as parallel processors.

The software may include a computer program, code, instructions, or a combination of one or more of the above, and may configure the processing device to operate as desired, or process independently or collectively. You can command the device. The software and / or data may be embodied in any type of machine, component, physical device, computer storage medium or device in order to be interpreted by or provided to the processing device or to provide instructions or data to the processing device. have. The software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner. The software and data may be stored on one or more computer readable recording media.

The method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium. In this case, the medium may be to continuously store a computer executable program or to temporarily store the program for execution or download. In addition, the medium may be a variety of recording means or storage means in the form of a single or several hardware combined, not limited to a medium directly connected to any computer system, it may be distributed on the network. Examples of media include magnetic media such as hard disks, floppy disks and magnetic tape, optical recording media such as CD-ROMs and DVDs, magneto-optical media such as floptical disks, And ROM, RAM, flash memory, and the like, configured to store program instructions. In addition, examples of another medium may include a recording medium or a storage medium managed by an app store that distributes an application, a site that supplies or distributes various software, a server, or the like.

Although the embodiments have been described by the limited embodiments and the drawings as described above, various modifications and variations are possible to those skilled in the art from the above description. For example, the described techniques may be performed in a different order than the described method, and / or components of the described systems, structures, devices, circuits, etc. may be combined or combined in a different form than the described method, or other components. Or, even if replaced or substituted by equivalents, an appropriate result can be achieved.

Therefore, other implementations, other embodiments, and equivalents to the claims are within the scope of the claims that follow.

Claims (13)

In the data synchronization method in a computer implemented server,
Performing data synchronization on a plurality of clients sharing a data type in a multi-device environment by using a data type synchronized with an operation;
Including,
Performing the data synchronization,
Managing the operation of the data type by reflecting a physical time increasing in the server along with a logical time according to an operation generation; And
Determining the priority of the operation in consideration of the physical time for the operation of the data type;
A data synchronization method in a computer-implemented server comprising a. The method of claim 1,
Performing the data synchronization,
Performing data synchronization by exchanging an operation of the data type with the client
Characterized in that, the data synchronization method in a computer-implemented server. The method of claim 1,
As the client attaches the data type, a push-pull operation occurs for the operation of the data type,
No push-pull operation for the operation of the data type occurs as the client detaches the data type
Characterized in that, the data synchronization method in a computer-implemented server. The method of claim 1,
Performing the data synchronization,
Receiving the operations of the data type from the client in the order of generation; And
Filtering duplicate operations among the received operations
A data synchronization method in a computer-implemented server comprising a. The method of claim 1,
Performing the data synchronization,
Identifying the operation of the data type using a client sequence that is updated each time the client generates an operation of the data type, and a server sequence that is updated each time the server receives an operation of the data type from the client step
A data synchronization method in a computer-implemented server comprising a. The method of claim 1,
Performing the data synchronization,
In a push operation for an operation of the data type, receiving from the client a checkpoint comprising a server sequence the client has received most recently from the server and a client sequence most recently updated by the client; And
In a pull operation on an operation of the data type, sending a checkpoint to the client that includes a server sequence most recently updated by the server and a server sequence most recently received by the server
A data synchronization method in a computer-implemented server comprising a. The method of claim 6,
The client transmits the missing operation to the server along with the next operation based on the checkpoint received from the server.
Characterized in that, the data synchronization method in a computer-implemented server. The method of claim 6,
Performing the data synchronization,
Filtering duplicate operations among operations received from the client by comparing checkpoints exchanged with the client at the server;
Further comprising a data synchronization method in a computer-implemented server. The method of claim 1,
Performing the data synchronization,
Transmitting a snapshot of the data type to the client for data synchronization according to the client's request
A data synchronization method in a computer-implemented server comprising a. The method of claim 1,
The physical time is increased when at least one of a condition in which a predetermined number of operations are newly received for each data type and a condition in which the predetermined time physically elapses are satisfied.
Characterized in that, the data synchronization method in a computer-implemented server. The method of claim 1,
The determining step,
Prioritizing operations by considering the physical time first before comparing the logical time for the operation of the data type
Characterized in that, the data synchronization method in a computer-implemented server. A computer program stored in a computer readable recording medium in combination with a computer for executing the method of any one of claims 1 to 11 on a computer. In the data synchronization system of a computer implemented server,
At least one processor implemented to execute computer-readable instructions
Including,
The at least one processor,
Process of data synchronization using a data type synchronized with an operation for a plurality of clients sharing a data type in a multi-device environment
To process
The process of performing the data synchronization,
The operation of the data type is managed by reflecting the physical time increasing in the server along with the logical time according to the operation generation,
Determining the priority of the operation in consideration of the physical time for the operation of the data type
Characterized in that, the computer data synchronization system of the server implemented.

Images