Design Project 2: Frequently Asked Questions (FAQ)

Q: The Chord paper presents, in Table 1, a key/value API. Can we use this interface?

A: You should use the lookup(key) interface described in the DP2 assignment.

Q: How sophisticated does my authorization system have to be? Do I need to have ACLs to control who is allowed to read and write data?

A: You need to make sure that only the original publisher of a document is allowed to change or replace that document. You don't need any other form of authorization. Note that consumers must be able to authenticate the contents of documents they retrieve, to make sure the data they get are the data the publisher published. This is a distinct idea from authorization, though you may find it convenient to have overlap between the mechanisms for the two.

Q: Can we demand that volunteer servers dedicate some amount of memory or disk space to our peer-to-peer system?

A: Yes, you may demand that each server dedicate some fixed minimum resources.

Q: Why can't we just use the FreeNet design for DP2?

A: FreeNet is a bad fit to the goals of DP2. For example, all copies of a document stored on FreeNet could rapidly disappear from the system if the document weren't popular. It's also difficult to show why the cost of finding a document is less than linear in the total number of FreeNet servers.

Q: Can we use naming ideas from FreeNet in our design?

A: You are welcome to use naming (or other) ideas from anywhere, just be careful not to claim them as your own. In your writeup, mention the source of the idea and provide a citation.

Q: Do we have to use the Chord API exactly as given in the assignment, or are we allowed to modify it?

A: You are allowed to modify it, as long as you show that your modifications are easy to implement. For example, you can look at the local node's finger table.

Q: How robust should our system be in the face of nodes failing?

A: Your system should work perfectly (i.e. lose no data) if any number of nodes fail one by one, with a reasonably long period of time between each successive failure. Your system should have a high probability of being able to serve any particular piece of data even after a randomly chosen 5% of the nodes simultaneously fail.

Q: The assignment mentions that we are not required to preserve data forever. Are there any rules at all for how long we have to to store data?

A: You should provide a service that makes it easy for publishers to keep their data stored for as long as desired. For example, you could promise to store data for at least a week; then publishers would know to refresh their data weekly.

Q: We can't figure out how a node can initially join the system in a fully decentralized way. How can we provide a decentralized way for users to download an authentic copy of our software? Or an authentic set of nodes to contact for the initial join()?

A: It's OK if you can't think of a great way to do this.

Q: To what do the id and addr arguments to fn refer in the description of event_register()?

A: They are the Chord ID and IP address of the node that just joined or left.

Q: Can we use a certificate authority or public key infrastructure in our design?

A: Please don't use a centralized PKI (such as Verisign) in your peer-to-peer system! If you want to design your own peer-to-peer PKI, that's OK, though it's probably more difficult than the original design project. If you do include a PKI in your design, make sure you explain how adding the level of indirection between names and public keys is better than direct use of keys. Further, explain enough about the PKI's operating procedures to convince us that having to trust it does not weaken the system's security.