Test cases
Early bird test case
-
Resol: One user starts a peer by
./loser_peer resol.configwith 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 -
Reep: Another user starts a peer by
./loser_peer reep.configwith the config.name = reep peers = resol repo = /home/reep/repo -
By staring two peers, we can see socket files in
/tmp.$ ls /tmp mp2-reep.sock mp2-resol.sock -
Resol: If resol user types
historyorhistory [-a]. Because no commits are made by Resol or Reep, the output is empty. Reep peer behaves similarly. -
Resol: Again, if resol user types
list, no files are present in output but an empty MD5 section.(MD5) -
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.txton local machine, and make a copy in LoserFS namedfirst.txt. Once the command finishes, it prints the message:success -
Reep: At this moment, the reep user types
listand the output goes as follows. It shows the hash22af645d1859cb5ca6da0c484f1f37ea, and of course, if we calculate the MD5 ofsource.txton 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 -
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 -
Reep: If reep user runs
history. Since he or she has do nothing so far, the output is still empty. -
Resol and Reep: If any of resol and reep user runs
history -aat 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 -
Reep: Suppose reep moves a file to repo by
mv /home/reep/another.txt @second.txt. The peer copies the content ofanother.txtfrom machine tosecond.txtin repo. Once the command completes,another.txtis deleted, and it prints the message.success -
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 -
At this moment, the reep’s
historyis updated due to new commit, while resol’shistoryis unchanged. Bothhistory -aoutputs 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.
-
Resol: The resol user decides to get a copy of
second.txtbycp @second.txt /home/resol/copy_of_second.txt. Becausesecond.txtis hosted by reep, file transfer between them may occur. It printssuccessonce it finishes, and the MD5 ofcopy_of_second.txtshould be the same to that in the log.$ md5sum /home/resol/copy_of_second.txt a9f0e61a137d86aa9db53465e0801612 /home/resol/copy_of_second.txt -
Note that resol does a repo to machine copy. There’s no need to make new commits. Thus, the log is unchaged.
-
Reep: The reep user now runs
cp @first.txt /home/reep/copy_of_first.txt. Due to concurrency support, the resol canrm @first.txtbefore reep’s cp completes. According to our spec, reep still continues the copy of original content until it completes. -
Again in 3., even resol user removes
/home/resol/source.txtshould not affect reep’s cp, becuase LoserFS already has the data andsource.txton resol’s machine is irrelevant. -
Resol: At this moment,
first.txtis removed by resol. Resol should update itshistory. 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 -
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) 1541611010000In the mean time, the
liston both sides printssecond.txt (MD5) second.txt a9f0e61a137d86aa9db53465e0801612
Program restart
This test case continues the previous section.
-
Reep: The reep user decides to quit by
exitcommand. If resol is copying a file from reep. The resol peer has to wait until the copy completes. -
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, sincesecond.txtis hosted by reep.txt, the command may fail with the message.failThe 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.
-
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 typeshistory, he’ll get# commit 1 [new_file] second.txt [modified] [copied] [deleted] (MD5) second.txt a9f0e61a137d86aa9db53465e0801612 (timestamp) 1541611005000 -
Reep: The reep user can continue his or her work. For example,
cp @second.txt @third.txtmakes a copy in repositoy. This command affects reep’s private log (history) and the combined log every peer can see (history -a).