none
Deep insight on how sync knowledge is structured RRS feed

  • Question

  • Hi,

    i've found on the web always the same examples on sync knowledge: ie. at the start up of initial synch  .Below is the example i've found everywhere in books and online docs....

    i would like to get a more deep view on what happens in more complex scenarios... where can i find more exaustive examples documented?

    the example is very clear but instead of the simple example  etc...can anyone, for example, explain me what happens if (see below... being the two replicas in the state A5B4) i change on the replica B the item I1. The metadata on B will change in...


    Item
    Update
    Tick Count
    Update
    Replica ID
    Creation
    Tick Count
    Creation
    Replica ID
    I104 2 B 1 B
    I105 4 B 3 B
    I3 3 A 2 A
    I2 4 A 4 A
    I1 5 B 1 A

    and the subsequent knowledge of replica B becoming B5A4 (or am i wrong????)

    i try to simulate the sync algorithm i find this change (only made on replica B) as a conflict due to the fact that the knowledge of replica B seem to lost (not includes) the A5 change. Where i'm wrong????   in knowledge structure there is a direct relation with item ids? In metadata store the knowledge field is an image: what kind of structure the knowledge is? where can i find  docs about it?

    Can anyone show me  a non trivial example of knowlegde operation such as project, exclude,  in a graphical way?

    thanks in advance

    ********************************************************************************************

    ********************************************************************************************

    ********************************************************************************************

    Synchronization Example

    Using the synchronization flow described in the previous section, we will walk through an example of how Sync Framework enumerates changes and ultimately applies item data.

    In this example there will be two replicas; Replica A and Replica B. Replica A will initiate synchronization to Replica B (meaning Replica A is the source and Replica B is the destination).

    For example, imagine we wanted to synchronize files between these two replicas. A single file in a folder will be the item that will be tracked and is described a In (for example, I1, I2,I3…). When a new file (I1) is created, the metadata associated with that file also needs to be updated as follows:


    Item
    Update
    Tick Count
    Update
    Replica ID
    Creation
    Tick Count
    Creation
    Replica ID
    I1 1 A 1 A

    If that file was updated again, the version table might look as follows:


    Item
    Update
    Tick Count
    Update
    Replica ID
    Creation
    Tick Count
    Creation
    Replica ID
    I1 5 A 1 A

    There are likely multiple files being tracked so let's bring in multiple items. As you can see the version information grows as more and more items are created. Sync Framework does not require previous update versions to be stored. It only needs to know of the most recent update version.


    Item
    Update
    Tick Count
    Update
    Replica ID
    Creation
    Tick Count
    Creation
    Replica ID
    I2 3 A 2 A
    I3 4 A 4 A
    I1 5 A 1 A

    If we take the current state of the items for this replica, we would represent the knowledge of Replica A as

    Replica A Knowledge = A5

    A is the Replica ID and 5 is the current tick count that this replica knows changes up to.

    On Replica B, there may also be a number of files. This replica looks as follows:

    Replica B


    Item
    Update
    Tick Count
    Update
    Replica ID
    Creation
    Tick Count
    Creation
    Replica ID
    I104 2 B 1 B
    I105 4 B 3 B

    The current knowledge for Replica B is:

    Replica B Knowledge = B4

    At this point we choose to initiate synchronization between the two replicas. Replica A will be the source (the one initiating synchronization) and Replica B will be the destination.

    During synchronization the destination sends the source its knowledge. As mentioned earlier, the knowledge for the two replicas look as follows:

    Replica A Knowledge = A5

    Replica B Knowledge = B4

    The source (Replica A) receives this knowledge and uses it to determine which versions to send to the destination. Since Replica B is not aware of any of the items in Replica A, the entire contents of Replica A are sent. In this case, it would include the following versions.


    Item
    Update
    Tick Count
    Update
    Replica ID
    Creation
    Tick Count
    Creation
    Replica ID
    I2 3 A 2 A
    I3 4 A 4 A
    I1 5 A 1 A

    The destination receives these versions and enumerates through them to determine which items are to be requested from the source. It also uses this information to determine if there are any conflicts (for example, the same file was updated on both replicas).

    Once that is complete the destination requests the source to send the items it is not aware of. In this case, Replica A would send the files that are associated with I1, I2 and I3

    The destination receives these files and adds them to its folder.

    At the end of this synchronization session, the process is executed one more time, but this time the source becomes the destination and the destination becomes the source. This allows Replica A to receive any of the files that were created or changed on Replica B (I104 and I105)

    At the end of synchronization both replica have the following updated knowledge.

    Replica A Knowledge = A5 B4

    Replica B Knowledge = A5 B4


    ********************************************************************************************

    ********************************************************************************************

    ********************************************************************************************




    Friday, September 25, 2015 4:10 PM