Design of Multi-terminal data synchronization mechanism (2) Terminal Data Synchronization

Design of Multi-terminal data synchronization mechanism (2) Terminal Data Synchronization
Design of Multi-terminal data synchronization mechanism (2)

Intro

If you have not read the previous article, we recommend that you first move to here to view the first part. The last step mainly solved the basic incremental synchronization problem, but there are still some problems. Possible main problems:

To solve these two problems, you need to verify the data and perform batch transmission when the data volume exceeds a certain amount.Data VerificationAndBatch Data TransmissionThese two problems.

Synchronization Process Overview

Combined with the previous synchronization process and data verification and batch data transmission, the general process is as follows: the client calls the serverPullThe interface pulls data from the server. If the local version is the latest version number on the server, the latest version is updated. If the local version is earlier than the latest version number on the server, the data to be updated is pulled, when the server returns data, it returns a verification value for the locally transmitted data. When the client obtains the server response, it first calculates the verification value based on the received data, after calculation, it is compared with the check value returned by the server. If the check value calculated locally is the same as the check value returned by the server, the local data of the client is updated. Otherwise, the local data is regarded as invalid data and requested again.PullInterface.

After updating to the latest version, check whether there are unsubmitted versions in the local device. If there is no modification in the local device, the data synchronization is completed. If there is a modification in the local device, submit the local modification, before submitting local data, you must calculate the verification value of the transmitted data. The verification value is sent to the server together with the local data.PushInterface. ServerPushAfter receiving the client request, you must perform data verification. The verification value is calculated based on the transmitted data and compared with the verification value passed by the client. If the two values are inconsistent, if the data is lost or abnormal during transmission, the request is not processed and returned to the client. This request is an abnormal request. If the two values are the same, data will be processed again. After the processing, the data will have a return status and other necessary attributes. The check value is calculated based on the data, which is similar to that when pulling data from the server and will not be repeated, after the client data is verified, the local data is updated based on the processing status of the server.

The following shows the main flowchart after data verification is added:

Obtain data from the server:

 

Client pull data:

 

Update data on the server:

 

The client pushes the update data:

 

Data Verification

For data verification, we use MD5 for verification and the MD5 for data transmission. There are two considerations for using MD5: on the one hand, because the string generated by MD5 is not too long, it does not affect the amount of data transmitted. On the other hand, because MD5 is more common, it is convenient to implement it on the APP side.

Batch Data Transmission

The data is transmitted in batches. I feel that the comparison is implemented here.LOWThis is similar to the paging on the website. I did not expect a better solution. I look forward to sharing a better solution. Returns the index of the current page number requested by the client and the total page number of the current data transmission. If the index of the page number is smaller than the total page number, the index of the page number is + 1, and the interface is requested again to know that the index of the returned page number is equal to the total page.

Summary

Step-by-Step data conversion to MD5

When the data is switched to MD5, we step on a pitfall again and start to do so. We use the MD5 algorithm to calculate the byte array and then useSystem.Text.Encoding.UTF8.GetString()The method is converted to a string, and the result is dumb during debugging. The obtained strings are garbled, garbled, and garbled... [No zuo no die]

Below is the code I have swallowed up with blood [laugh Cry]

1 /// <summary> 2 // convert the object to an MD5 string 3 /// </summary> 4 /// <param name = "obj"> Object </param> 5 /// <param name = "isLowwer"> lowercase </param> 6 /// <returns> </returns> 7 public static string ToMD5String (this object obj, bool isLowwer = false) 8 {9 if (obj = null) 10 {11 return ""; 12} 13 // create MD5 object 14 MD5 md5 = new MD5CryptoServiceProvider (); 15 byte [] byteArray = null; 16 using (MemoryStream MS = new MemoryStream () 17 {18 new System. runtime. serialization. formatters. binary. binaryFormatter (). serialize (ms, obj); 19 byteArray = ms. toArray (); 20} 21 // calculate the hash value of the specified byte array 22 byte [] bMD5 = md5.ComputeHash (byteArray ); 23 // release all resources of the class provided by the encryption service 24 md5.Clear (); 25 System. text. stringBuilder sbMD5Pwd = new System. text. stringBuilder (); 26 if (isLowwer) 27 {28 for (int I = 0; I <bMD5.Length; I ++) 29 {30 // convert each byte data to two lowercase hexadecimal characters 31 sbMD5Pwd. append (bMD5 [I]. toString ("x2"); 32} 33} 34 else35 {36 for (int I = 0; I <bMD5.Length; I ++) 37 {38 // convert each byte data to two uppercase hexadecimal characters 39 sbMD5Pwd. append (bMD5 [I]. toString ("X2"); 40} 41} 42 return sbMD5Pwd. toString (); 43}

 

End

Finally, we provide a flowchart for the entire synchronization process design. Click here to download it.

If you have other plans, we hope that you can give your own opinions and opinions. If there are any mistakes, we hope you can tell them.