Hi,
I have several questions,
- Could you clarify what is the use of PaxosSeqID field in the Paxos messages?
I can not find any mention of it in the specification. I think it should indicate which block this paxos message corresponds to, right?
- In case we index a new file, is it correct that this new file should not be added to SearchReply or GetIndexedFiles before its name is recorded in the blockchain?
- Assume we have a local file called file A, but the consensus say that it should be called file B.
Should we change the name of the local file (the actual file on the disk), or is it enough that we only change its name inside our implementation?
- Are we still required to ensure that the implementation can gracefully restart after crash?
I just want to make sure I really understand the specification before I start coding.
Best,
Reka
Hi,
Good questions!
1. Could you clarify what is the use of PaxosSeqID field in the Paxos messages?
I can not find any mention of it in the specification. I think it should indicate which block this paxos message corresponds to, right?
That's correct.
2. In case we index a new file, is it correct that this new file should not be added to SearchReply or GetIndexedFiles before its name is recorded in the blockchain?
Yes, that's correct. The node first waits for consensus on the <file name, metahash> pair and only after that shares the file as described in hw2.
3. Assume we have a local file called file A, but the consensus say that it should be called file B.
Should we change the name of the local file (the actual file on the disk), or is it enough that we only change its name inside our implementation?
The file - metahash mapping is a bijection: a file has one and only one metahash mapping, and vice versa, a metahash has one and only one file mapping.
I'm not sure what "we have a local file" means. Are you saying that the blockchain already contains the pair <file B, metahash 1> and a node wants to share <file A, same metahash 1>? In this case, the node cannot share file A, because metahash1 collides with <file B, metahash 1> already stored in the blockchain.
Or are you saying that a node shared file A first, and now the consensus says it should be called file B? In this case, because file A is shared first, the blockchain already contains <file A, metahash1> and nobody else could share the same <file B, metahash1>. So the consensus cannot change
As you can see, it depends on what happens first: either file A being shared or file B. The blockchain defines a total order, so that's the order we use to decide what happens first.
4. Are we still required to ensure that the implementation can gracefully restart after crash?
Not for consensus. For the consensus component, we assume a crash-stop model, which means that once a node fails, it never restarts. Paxos can work with restarts, but we don't ask you to implement that version, because it's more complex.
The share functionality in hw2 already assumes a more generic crash-recover model, so no change is required there.
Let us know if something is still unclear.
Cristina
Thank you for your answers, it really helps.
For question 3, it is actually more about how should I store the file in the shared folder. For example, if I run IndexFile("decentralized.txt") on the node A. Then afterwards this node A learns that this file is already given a name "centralized.txt". Should I rename the file "decentralized.txt" on the shared folder to "centralized.txt"? Or I should just kept it as it is.
Best,
Reka
For question 3, it is actually more about how should I store the file in the shared folder. For example, if I run IndexFile("decentralized.txt") on the node A. Then afterwards this node A learns that this file is already given a name "centralized.txt". Should I rename the file "decentralized.txt" on the shared folder to "centralized.txt"? Or I should just kept it as it is.
Best,
Reka
On your example: node A doesn't index the file "decentralized.txt" until it sees consensus on the name. In your case, "decentralized.txt" will be rejected by consensus, so node A will never index the file.
What you could do is to have node A observe, as you said, that the file exists under a different name and index the file as "centralized.txt". You can safely do that if you want, but it's also ok if node A gives up and doesn't index the file at all.
Does this help?
Cristina
Perfect, everything is clear now. Thanks
Best,
Reka
