Test cases

Early bird test case

  1. Resol: One user starts a peer by ./loser_peer resol.config with this config file. The peer is named resol. It assumes the existences the the repo directory /home/resol/repo.

     name = resol
     peers = reep
     repo = /home/resol/repo
    
  2. Reep: Another user starts a peer by ./loser_peer reep.config with the config.

     name = reep
     peers = resol
     repo = /home/reep/repo
    
  3. By staring two peers, we can see socket files in /tmp.

     $ ls /tmp
     mp2-reep.sock
     mp2-resol.sock
    
  4. Resol: If resol user types history or history [-a]. Because no commits are made by Resol or Reep, the output is empty. Reep peer behaves similarly.

  5. Resol: Again, if resol user types list, no files are present in output but an empty MD5 section.

     (MD5)
    
  6. Resol: The resol user decides to create first file by copying a file into LoserFS by the command cp /home/resol/source.txt @first.txt. the peer program reads /home/resol/source.txt on local machine, and make a copy in LoserFS named first.txt. Once the command finishes, it prints the message:

     success
    
  7. Reep: At this moment, the reep user types list and the output goes as follows. It shows the hash 22af645d1859cb5ca6da0c484f1f37ea, and of course, if we calculate the MD5 of source.txt on Resol machine, it should be the same. The judge also tests if the output is updated in 0.5 second after the copy.

     first.txt
     (MD5)
     first.txt 22af645d1859cb5ca6da0c484f1f37ea
    
  8. Resol: The resol user check out its log by history. It has at least one commit about creating a file.

     # commit 1
     [new_file]
     first.txt
     [modified]
     [copied]
     [deleted]
     (MD5)
     first.txt 22af645d1859cb5ca6da0c484f1f37ea
     (timestamp)
     1541611000000
    
  9. Reep: If reep user runs history. Since he or she has do nothing so far, the output is still empty.

  10. Resol and Reep: If any of resol and reep user runs history -a at the same time, it should print combined log from both. Hence, we have

    # commit 1
    [new_file]
    first.txt
    [modified]
    [copied]
    [deleted]
    (MD5)
    first.txt 22af645d1859cb5ca6da0c484f1f37ea
    (timestamp)
    1541611000000
    
  11. Reep: Suppose reep moves a file to repo by mv /home/reep/another.txt @second.txt. The peer copies the content of another.txt from machine to second.txt in repo. Once the command completes, another.txt is deleted, and it prints the message.

    success
    
  12. Resol and Reep: At this moment, both users can see identical logical view by list.

    first.txt
    second.txt
    (MD5)
    first.txt 22af645d1859cb5ca6da0c484f1f37ea
    second.txt a9f0e61a137d86aa9db53465e0801612
    
  13. At this moment, the reep’s history is updated due to new commit, while resol’s history is unchanged. Both history -a outputs are identical as follows.

    # commit 1
    [new_file]
    first.txt
    [modified]
    [copied]
    [deleted]
    (MD5)
    first.txt 22af645d1859cb5ca6da0c484f1f37ea
    (timestamp)
    1541611000000
    
    # commit 2
    [new_file]
    second.txt
    [modified]
    [copied]
    [deleted]
    (MD5)
    second.txt a9f0e61a137d86aa9db53465e0801612
    (timestamp)
    1541611005000
    

In early bird test case, no cross-peer file transfer is needed. They only need to share their logs to setup identical logical view.

Cross-peer file transfer

This test case continues the early bird test case.

  1. Resol: The resol user decides to get a copy of second.txt by cp @second.txt /home/resol/copy_of_second.txt. Because second.txt is hosted by reep, file transfer between them may occur. It prints success once it finishes, and the MD5 of copy_of_second.txt should be the same to that in the log.

     $ md5sum /home/resol/copy_of_second.txt
     a9f0e61a137d86aa9db53465e0801612  /home/resol/copy_of_second.txt
    
  2. Note that resol does a repo to machine copy. There’s no need to make new commits. Thus, the log is unchaged.

  3. Reep: The reep user now runs cp @first.txt /home/reep/copy_of_first.txt. Due to concurrency support, the resol can rm @first.txt before reep’s cp completes. According to our spec, reep still continues the copy of original content until it completes.

  4. Again in 3., even resol user removes /home/resol/source.txt should not affect reep’s cp, becuase LoserFS already has the data and source.txt on resol’s machine is irrelevant.

  5. Resol: At this moment, first.txt is removed by resol. Resol should update its history. Note that MD5 is not needed for file deletion.

     # commit 1
     [new_file]
     first.txt
     [modified]
     [copied]
     [deleted]
     (MD5)
     first.txt 22af645d1859cb5ca6da0c484f1f37ea
     (timestamp)
     1541611000000
    
     # commit 2
     [new_file]
     [modified]
     [copied]
     [deleted]
     first.txt
     (MD5)
     (timestamp)
     1541611010000
    
  6. Resol and Reep: Both can see combined log as follows, which commits are ordered by timestamps.

     # commit 1
     [new_file]
     first.txt
     [modified]
     [copied]
     [deleted]
     (MD5)
     first.txt 22af645d1859cb5ca6da0c484f1f37ea
     (timestamp)
     1541611000000
    
     # commit 2
     [new_file]
     second.txt
     [modified]
     [copied]
     [deleted]
     (MD5)
     second.txt a9f0e61a137d86aa9db53465e0801612
     (timestamp)
     1541611005000
    
     # commit 3
     [new_file]
     [modified]
     [copied]
     [deleted]
     first.txt
     (MD5)
     (timestamp)
     1541611010000
    

    In the mean time, the list on both sides prints

     second.txt
     (MD5)
     second.txt a9f0e61a137d86aa9db53465e0801612
    

Program restart

This test case continues the previous section.

  1. Reep: The reep user decides to quit by exit command. If resol is copying a file from reep. The resol peer has to wait until the copy completes.

  2. Resol: After reep exits, resol can still see recent log by history -a. However, if resol user runs cp @second.txt /home/resol/another_copy.txt, since second.txt is hosted by reep.txt, the command may fail with the message.

     fail
    

    The judge can accept command failure in this case. However, it’s still possible that resol already has a copy and the command suceeds. It’s up to your protocol design. The judge can accept is and will not bother with your implementation.

  3. Reep: Now the reep user restarts the program by ./loser_peer reep.config. It should restore its files and log from repository. Hence, if reep user types history, he’ll get

     # commit 1
     [new_file]
     second.txt
     [modified]
     [copied]
     [deleted]
     (MD5)
     second.txt a9f0e61a137d86aa9db53465e0801612
     (timestamp)
     1541611005000
    
  4. Reep: The reep user can continue his or her work. For example, cp @second.txt @third.txt makes a copy in repositoy. This command affects reep’s private log (history) and the combined log every peer can see (history -a).