ds_sample_quiz

.pdf

School

Columbia University *

*We aren’t endorsed by this school

Course

4113

Subject

Computer Science

Date

Jan 9, 2024

Type

pdf

Pages

Uploaded by ChiefGorilla3742

Distributed Systems Sample Quiz (Time: 110 minutes) NAME: __________________________________________________ UNI: __________________________________________________ Grading notes: - All questions are graded on a scale of 0-2: - 0 = no answer, answer contains a major flaw, answer is beside the point, or answer lacks required explanation or example. - 1 = answer is not faulty but is beating around the bush or not quite nailing the point; - 2 = answer is correct, to the point, and reflects understanding of the concepts. - For questions that require an explanation or example will be counted as 0 (zero) if no explanation or example is provided, even if the answer is technically correct (e.g., answers such as “Yes,” “No,” “Correct,” “Incorrect,” in the questions below will get a zero). - Please keep your answers brief and to the point. For reference, you shouldn’t need more than the allotted space to fit your answer even if you use big font. CONSISTENCY 1. [2 points] Give one concrete example of an execution history for a distributed storage system that is causally consistent but not sequentially consistent. Do NOT use the same example as in class, invent your own. 1

TWO-PHASE COMMIT Ben Bitdiddle and Alyssa Hacker are reflecting on the properties of the two-phase commit protocol. For concreteness, they examine a scenario where client C initiates a single transaction involving two servers A and B. 2. [2 points]: Suppose the one way delay between any pair of nodes is r, how long does it take for client C to learn of the transaction’s result using the two-phase commit protocol? (Draw a message time diagram to illustrate the situation.) 3. [2 points]: Give an example scenario under which two-phase commit protocol fails to make progress (i.e. the transaction neither succeeds nor aborts). 2

PAXOS The Paxos protocol as presented in class is static: the set of nodes participating in the protocol are assumed not to change over time. Ben Bitdiddle needs a dynamic version of Paxos, which would allow him to add/remove nodes to address load changes, failures, etc. Ben settles on the following protocol for dynamic Paxos. When a node X wants to join, it will initiate Paxos by becoming a proposer itself and seeks a majority of ”accept” messages from the nodes in the current group plus itself. For example, if the current group is {A,B} and node X joins, the Paxos protocol initiated by X will succeed in deciding on the new group when any majority of nodes in {A,B,X} accepts the new group. 5. [2 points]: Is Ben’s new join protocol correct? If yes, give a proof sketch. If no, give a concrete counter-example where his protocol gives an incorrect result. 3

6. [2 points]: Ben decides to simplify the Paxos protocol and speed up the decision process. He proposes to change Paxos by having a proposing node use its node identifier as the proposal number. As a result, the node with the biggest node identifier will always be able to win over other potential proposers. In contrast, in the original Paxos design, a proposer generates a proposal number by concatenating an (increasing) integer together its node identifier instead of just using the node identifier alone. Therefore, unlike Ben’s design, the original Paxos does not ensure that any one node will always win over other potential proposers. Is Ben’s change desirable? If yes, explain its advantages over the original Paxos. If no, give a concrete example to explain why the original Paxos is preferable. 4

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version