The Exam

The Exam at a Glance exam

Before you can plan revision or pace yourself in the room, you need the hard facts: when the exam is, what you may bring, how the 60 marks are split and how long each mark is worth spending. Everything in this section comes from the Week 12 "final exam preparation" lecture and the cover page of the official 2026 practice exam, plus three posts from staff on Ed, the subject's discussion forum.

The last row is the one to carry into the room. At three minutes a mark, a 5-mark question deserves about 15 minutes including thinking time, one 0.5-mark multiple-choice item a minute or two, and the 10-mark coding question about 30 minutes. The figure lays the whole paper out on one time line, so you can see where each block of minutes goes.

The 2016 paper put two more rules on its cover that are worth keeping in mind: "No materials are authorized", and candidates should attempt all questions, because partial credit is available. According to the slide in the admin lecture (L0), the guest lectures and the advanced topics (content delivery networks, cloud, blockchain and the Internet of Things) are not examinable.

What staff have confirmed on Ed

The lecture left a few questions open, and three posts from staff settle them. Together they tell you what counts as examinable, how much to trust the worked answers on this page, and where to get an official opinion. The time line places them, and the other dates that matter, between the release of the practice exam and the exam itself.

1. Both lecture and tutorial content are in scope (30 October). The tutorial answers marked official on this site, including the revision tutorial's answers in 11.11, are therefore examinable material in their own right, not just practice.
2. No solutions will be released for the practice exam (27 October), so that students can test their readiness honestly, and because many of its questions have more than one correct approach. The worked answers in 11.9 and 11.10 are therefore the study guide's own reference answers, not official ones: read each as one good answer rather than the only one. The same post invites you to post a specific question with your draft answer on Ed, and staff will review it. That is the way to get an official view on any practice-exam answer you are unsure of.
3. An exam consultation on Zoom was announced on 2 November for 3:00–5:00 PM on Tuesday 3 November, with the advice to bring the questions where your own draft and the worked answers disagree. That session took place on 3 November; for anything still unresolved, Ed is the channel that remains.

What to study, according to the Week 12 lecture

The lecturer gave a list of suggested study points for each lecture, together with the textbook reading. He described it as "not an exhaustive list, nor is it a list of exam questions": everything from Weeks 1–12 is examinable unless stated otherwise. He also said to study each lecture together with its tutorial, which was usually held the following week, and to attempt the practice final exam. The table maps each lecture's study points onto the Part of this site that teaches them. The textbook throughout is CDK: Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design, 5th edition.

Notice that the lecture order and the Part order differ: sockets (L2) and threads (L3) were taught before system models (L4), but system models come first on this site (Part II) because they give you the vocabulary for everything else.

What to read last

The lecturer added that some concepts are only in the slides, and that you can safely skip textbook content the slides don't mention. That makes a handful of brief topics, which sit outside both the study points and the reading list, the lowest priority. Read them only once everything else is solid:

• overlay networks and MPI (CDK §4.5–4.6), in Part III;
• invocation performance and OS-level virtualization (CDK §7.5 and §7.7), in Part V;
• AFS and later developments in distributed file systems (CDK §12.4–12.5), in Part VIII;
• the Global Name Service (CDK §13.4), in Part IX;
• cryptography pragmatics (CDK §11.5), in Part X.

The 2016 paper did ask a 1-mark question on virtualization, but that was under a different lecturer.

Check yourselfYou reach the exam's Q7, a 5-mark question, after 100 minutes of writing. Are you ahead of or behind schedule?

Q1 to Q6 are 30 marks, which at 3 minutes a mark should take 90 minutes, so Q7 should start at minute 90. Starting at minute 100 you are 10 minutes behind. You still have 80 minutes for 30 marks (Q7–Q11), which is under 3 minutes a mark, so shorten each remaining answer to its essentials rather than skipping a question: partial credit is available.

Check yourselfWhich of these is examinable?

1. A guest lecture from Week 11
2. The blockchain material from the advanced topics
3. An official tutorial answer posted on Ed
4. Nothing outside the lecture slides

C. Staff confirmed on Ed on 30 October that both lecture and tutorial content are in scope. Guest lectures (A) and the advanced topics (B) are explicitly not examinable, and D is wrong because the tutorials are examinable too.

Check yourselfYour answer to a practice-exam question takes a different route from the worked answer on this page. What should you conclude?

Nothing yet. The practice exam has no official solutions, the worked answers here are the study guide's, and staff pointed out that many questions have more than one correct approach. Check your points against the Part that teaches the topic, and if you are still unsure, post the question with your draft on Ed for staff to review.

What the Questions Look Like exam

Knowing the material is only half of scoring well; the other half is giving each question the shape of answer its marker is looking for. A "compare" question wants matched differences, a "design" question wants a diagram and a message flow, and a definition wants one precise sentence and an example. This section names the six question types of the 2016 paper, the four extra types the 2026 practice exam adds, and the technique that scores on all of them.

The six types of the 2016 paper

Every question on the 2016 paper falls into one of six types, and each type has a typical answer shape worth learning. The table summarises them; the figure then draws each answer shape as a chain of moves, and the notes after it give the 2016 wording.

Applying a list to a scenario

2016 Q1(a) read "List and briefly explain, with respect to this example [a university computer lab], five challenges of DS". Write one line per item: name the item, define it in one clause, and apply it to the scenario. The words "with respect to this example" are where most marks are lost, because a textbook definition with no lab in it answers a different question.

Classifying and justifying

Q1(b) asked which architectural model best describes a browser-based cloud spreadsheet, to give three reasons that support it, and to give an application for which it is not suitable. Name the model precisely, then give the exact number of reasons asked, each as a separate bullet. The counter-example must explain why the model fails for it, not just name an application.

Defining or explaining a concept

Examples are Q3(b), "What is meant by a timing failure?", and Q7(b), "What is challenge-response? Give an example". Give a crisp definition in textbook wording, then a concrete example in a distributed system.

Comparing

Q4(a) asked for three differences between UDP and TCP, Q4(b) for the benefit of XML over JSON and vice versa, and Q6(a) for worker pool versus thread-per-connection, "including concurrency control and queueing". Use a mini-table or paired bullets ("TCP …; UDP …"), and make each difference name the dimension it is about: reliability, ordering, connection, and so on.

Designing with a paradigm

Q5(a) asked you to choose a tuple space, a message queue or publish-subscribe for a "music popularity" app, explain the choice and draw a diagram; Q5(b) to design a distributed shared memory (DSM) middleware, with its protocol, messages and OS support; and Q8(c) to design a name space and name format for the fastest object access. State your choice and draw the diagram, with boxes and labelled arrows. Then walk through the message flow step by step, justify the design against the requirement, and mention one trade-off.

Your project

Q2 asked, about the first project, what problem would arise if the design changed in a given way, how you would fix it, and what failure model you had assumed. This needs precise reasoning about your own assignment design; 11.4 answers the 2016 version and 11.5 prepares the 2026 assignments.

Four types new in the 2026 practice exam

The 2026 practice exam keeps several of the six types: Q2 applies the transparencies to a scenario, Q3 compares TCP and UDP, Q5, Q7 and Q10 ask you to explain a concept, and Q6 asks for a labelled diagram with an explanation. It has no project question, but it adds four types the 2016 paper did not have.

The answer technique that consistently scores

Whatever the type, the same seven habits earn marks. They are worth rehearsing until they are automatic, because under time pressure you fall back on habit.

1. Answer exactly the number asked. If the question asks for "three differences", give three, clearly separated. Extra items are not marked, and they cost time.
2. Bold or underline the key term at the start of each bullet, so that the marker finds it.
3. Always tie back to the scenario when one is given. Generic textbook text earns roughly half marks.
4. Draw when asked, and when it helps: architecture boxes, message sequence arrows, the Kerberos or Needham–Schroeder exchange. Label every arrow with the message content.
5. Justify choices with trade-offs, along the lines of "X because R1, R2; the cost is C, acceptable here because …".
6. Use the course's vocabulary, such as "at-most-once semantics", "space and time uncoupling", "freshness interval", "authenticator" and "omission failure", because markers scan for it.
7. Write concisely and legibly. The Week 12 lecture asks for clear, concise, to-the-point answers, accepts bullet points, and warns that unreadable parts are marked as incorrect. Keep each answer inside its box, and if you must continue in an overflow box, say so in the original box.

Weak and strong answers, side by side

The habits are easiest to see in action. Below, the same two questions are answered twice. The weak answers are illustrations written for this page, of the kind that loses marks; the strong ones are the study guide's worked answers, shortened. Look at what changes: the scenario appears in every line, and every difference names its dimension.

Check yourselfWhich type is "Choose a tuple space, a message queue or publish-subscribe for this app, explain, and draw a diagram"? What five moves should the answer make?

It is design with a paradigm. The answer should state the choice, draw the diagram (boxes and labelled arrows), walk through the message flow step by step, justify the design against the requirement, and mention one trade-off.

Check yourselfA question asks for "two benefits of a broker network". You know four. What do you write?

Exactly two, clearly separated, each opening with a bold key term (for example Scalability and Fault tolerance), and each tied to the question's scenario if it has one. Extra items are not marked and they cost time you need elsewhere.

Topic Coverage of the 2016 Paper

If you have limited time, it helps to know how the marks have been spread over the topics in the past. This section maps each 2016 question onto the Part of this site that covers it, and then sets the 2016 spread beside the 2026 practice exam's, so you can see what has changed.

Every lecture topic was examined in 2016, weighted roughly by lecture time. No 2016 question asked you to write code, though questions that ask you to read code or to "outline the steps" on sockets, threads or RMI were always plausible given lectures L2, L3 and L6. The 2026 format differs on exactly this point: the Week 12 lecture announced one 10-mark coding question, and in the practice exam it is a complete Java RMI program.

Two things stand out about the 2026 practice paper as a whole. Every lecture from L1 to L10 is represented, so no lecture is safe to skip. And it rewards precise definitions and mechanisms more than open-ended design: the multiple-choice items each turn on a single distinction, and the only question that asks you to build something is the RMI program.

Check yourselfWhich Part carried the most marks in 2016, and which carries the most in the 2026 practice exam? Why the change?

In 2016, system models (Part II) carried about 12 marks, across the architecture question, the project's failure model, channel performance and timing failures. In the 2026 practice exam, remote invocation (Part VI) carries 15: the 5-mark definitions in Q4 plus the 10-mark RMI program in Q11. The new coding question is what moved the weight.

The 2016 Paper, Question by Question

The 2016 final is the only full past paper, so it is the best extra practice after the 2026 practice exam, especially for scenario and design questions. Do the 2026 paper first (11.9), because it is closer to the real one. Model answers for every 2016 question except Q2 are in the self-tests of the Parts that teach them, where they are tagged as 2016 past-exam questions. Q2, the project question, is answered in full below. Use the table as an index: find a question, see what it asks and what it is worth, and go to its model answer.

Q2: the project question (2016 version) 2016 Q2

The 2016 project was a network of servers that broadcast messages to each other. A broadcast here means a message that every server in the network must receive. Each new server joined by connecting to exactly one existing server, so the servers always formed a tree: a connected network with no loops. The broadcast rule was simple: forward every message to all your neighbours except the one you received it from. On a tree that rule reaches every server exactly once, because there is only one path between any two servers.

The stepper shows what goes wrong. Server E joins by connecting to two servers, C and D, and the unchanged forwarding rule does the rest.

(a) What breaks, and how to fix it

• The server graph can now contain cycles. With the forwarding rule unchanged, a broadcast travels round each cycle and comes back to servers that have already handled it, which forward it again, indefinitely. The result is duplicate delivery and an unbounded broadcast storm.
• Fix 1 is duplicate suppression. Give every message a globally unique ID, such as the originating server's ID plus a per-server sequence number. Each server keeps a set of the IDs it has already seen, with expiry, and forwards and delivers a message only the first time it sees its ID, dropping any later copies. This is the standard fix for flooding, and it works on any topology.
• Fix 2 is a spanning tree. A spanning tree is a subset of the links that still connects every server but contains no cycle. Keep the extra links for redundancy, but broadcast only over a spanning tree computed by the servers. This needs a distributed spanning-tree protocol, and the tree has to be recomputed when servers fail.
• A hop count or TTL (time-to-live: a counter in the message, decremented at each hop, with the message dropped at zero) is not sufficient on its own. It bounds the storm, but it still delivers duplicates.

(b) The failure model assumed

A failure model states which ways each component may fail, and which it is assumed never to fail in. State it per component and per interaction, in the vocabulary of Part II:

• The channels are TCP connections, assumed reliable. TCP (the Transmission Control Protocol) masks omission, duplication and reordering of segments, so while a connection is up the application sees no channel omission failures. In other words, the channels have validity (every message sent is eventually delivered) and integrity (what is delivered is what was sent, once).
• The server processes are assumed not to crash, and to show no arbitrary (Byzantine) behaviour, meaning no failure in which a process does something other than what its program says: all the servers are correct and trusted. Clients may disconnect, and that is handled as a normal event.
• The network has no partitions, so the server tree stays connected.
• The timing model is asynchronous: no bounds on message delay were assumed, and none were needed.

Check yourselfA classmate proposes fixing the storm by giving each broadcast a hop limit of 10. Is that enough?

No. A hop limit (TTL) stops each copy after 10 hops, so it bounds the storm, but copies still go round the cycle within those 10 hops and servers still receive and deliver duplicates. Only duplicate suppression with unique message IDs, or broadcasting over a spanning tree, removes the duplicates.

Check yourselfWhy does the original rule ("forward to all neighbours except the sender") work on a tree but not on a graph with cycles?

On a tree there is exactly one path between any two servers, so each server is reached once and the rule never sends a message back towards where it has been. A cycle adds a second path: copies arrive along both, and since the rule does not remember which messages a server has already handled, each copy is forwarded again, round the cycle, without end.

Assignment-Based Questions for 2026

The 2016 exam spent 5 marks on the project, so questions on the 2026 assignments are possible. A1 was a multi-threaded subject enrolment server, built with TCP sockets, threads, a read-write lock per subject, and persistence (saving state to disk). A2 was the Turf War multiplayer game. Be aware, though, that the 2026 practice exam has no assignment question: its 10-mark question asks you to write a Java RMI program from scratch instead. The concepts the assignments exercise, namely sockets, threads, locking and failure models, are examined directly either way.

The A1 answers below are the study guide's, built on course concepts, so they apply even if your own implementation differed. Each names the Part that teaches the concept behind it.

A1-1. Which server threading architecture did you use, and why? Part IV

A threading architecture is the rule a server uses to decide which thread handles which piece of work. Three are candidates for A1 (see Part IV).

With thread-per-connection, a dedicated thread reads requests from one client's socket and handles them sequentially. This is natural for long-lived interactive command-line sessions, and it preserves the order of requests on each connection. The downsides are that every idle client still takes up a thread, and that there is no bound on the number of threads.

With a worker pool, the acceptor or reader threads put requests on a shared, synchronised queue, and a fixed number of workers take them off. This bounds resource use and avoids the cost of creating threads. But it needs a thread-safe queue, and requests from one client may be processed out of order unless you route them carefully.

Thread-per-request is the simplest to write, but it pays the thread-creation cost on every request and has no bound. It is a poor fit when one connection carries many small requests.

Whichever you choose, the shared subject data still needs concurrency control: the threading architecture and the locking are separate decisions.

A1-2. How do you prevent two clients both taking the last seat? Part IV

This is a check-then-act race: a bug in which a thread checks a condition and then acts on it, but another thread changes the data in between, so the check is stale by the time the action happens. Two threads both read enrolled < capacity before either of them writes, so both enrol and the subject ends up over capacity. The fix is to hold the subject's write lock across the whole check-and-update, so that the check and the update form one atomic critical section (a stretch of code only one thread may run at a time). The second thread then blocks until the first releases the lock; when it re-checks, it sees that the subject is full and returns FULL.

A1-3. How does TRANSFER avoid deadlock? Part IV

A deadlock is a state in which a set of threads each wait for a lock held by another thread in the set, so none can ever proceed. It could arise in A1 like this. T1 transfers from A to B and locks A, while T2 transfers from B to A and locks B. Each then waits for the other's lock, which gives a circular wait. The fix is to acquire both write locks in a single global order, such as ascending subject code, whatever the direction of the transfer. That breaks the circular-wait condition, so no cycle in the wait-for graph (the graph of which thread waits for which) is possible. Release the locks in finally blocks, so that an exception never leaves a lock held.

A1-4. Why a read-write lock per subject, rather than one global lock or synchronized on the whole map? Part IV

A read-write lock has two modes: any number of threads may hold it for reading at once, but a thread that holds it for writing holds it alone. The first reason for this design is granularity, meaning how much data one lock protects. Per-subject locks let operations on different subjects run in parallel, whereas a global lock serialises everything. The second is that a read-write lock lets many concurrent QUERYs on the same subject proceed together, while writes stay exclusive. The cost is more locks to manage, and multi-lock operations like TRANSFER need lock ordering (A1-3).

A1-5. State A1's failure model. Part II

As in 2016 Q2(b) (11.4), state the assumptions per component, in the failure-model vocabulary of Part II.

• The channels are TCP, assumed reliable: loss, duplication and reordering are masked while the connection lasts.
• The server may crash, which means it simply stops (a fail-stop or crash failure). Durability is achieved by persisting state after every successful write, so committed writes survive a restart. There are no arbitrary failures.
• Clients may crash or disconnect. The server detects this as EOF (end of file on the socket's input) or an IOException, closes the socket and frees the thread. Reconnection is not required.
• There is one failure the client cannot resolve. If the connection drops after a request is sent but before the reply arrives, the client cannot tell whether the operation was executed. Because there is no retry with duplicate filtering, a failure that the client sees means the operation ran either once or not at all, which is at-most-once semantics at best (Part VI).

A1-6. Why newline-delimited JSON? What is the "message boundary" problem? Part III

TCP is a byte stream and does not preserve message boundaries: the receiver sees one long sequence of bytes, so one read may return half a message, or two messages. The receiver therefore needs framing, a way to find where each message ends: either a delimiter (a newline, read with BufferedReader.readLine()) or a length prefix. JSON (JavaScript Object Notation) is text, language-independent and human-readable, which makes debugging and interoperability easy. The cost is larger messages and more parsing work than a binary format would need.

A1-7. Why TCP rather than UDP for A1? Part III

Every request must be executed exactly once and its reply received. TCP gives reliable, ordered delivery and a connection lifecycle, so a dead client is detected via EOF. UDP (the User Datagram Protocol, which sends independent datagrams with no guarantees) would force the application to implement timeouts, retransmission, duplicate filtering and fragmentation for large replies. Duplicate filtering would be essential because ENROL is not idempotent: an operation is idempotent if doing it twice has the same effect as doing it once, and enrolling twice does not.

Assignment 2 (Turf War)

Expect exam questions that ask you to explain and justify your own A2 design using course concepts. Likely topics are:

• keeping every client consistent under simultaneous actions (Part II, and ordering in group communication in Part VII);
• choosing between sockets, UDP and RMI, and choosing the protocol (Part III, Part VI);
• detecting crashed or disconnected players (the failure model and failure detection, Part II);
• why the server keeps the clock rather than each client (the interaction model, Part II);
• bringing a late joiner up to date;
• your threading model (multithreaded server architectures, Part IV);
• why client-server rather than peer-to-peer (Part II).

Write a model answer to each of these from your own implementation, in the same style as the A1 answers above.

Check yourselfWhich of the four conditions for deadlock does acquiring locks in ascending subject-code order remove?

1. Mutual exclusion
2. Hold and wait
3. No preemption
4. Circular wait

D, circular wait. Threads still hold locks exclusively (A), may hold one while waiting for another (B), and cannot have locks taken from them (C). But if every thread acquires in the same global order, a thread holding a later lock never waits for an earlier one, so no cycle can form in the wait-for graph.

Check yourselfYour A1 server uses synchronized on the whole subject map. Is the last-seat race fixed? What does it cost?

Yes, provided the check and the update are both inside the same synchronised block, because then they are one atomic critical section. The cost is granularity: every operation on every subject is serialised, so QUERYs on the same subject cannot run together and operations on different subjects cannot run in parallel. Per-subject read-write locks keep correctness and recover that parallelism.

Check yourselfIf A1 had used UDP and the client simply resent ENROL after a timeout, what could go wrong?

If the first request was executed but its reply was lost, the resent ENROL would be executed again. ENROL is not idempotent, so repeating it changes the state again (a double enrolment, or a seat taken twice). The server would need request IDs and duplicate filtering to prevent this; TCP avoids the problem for messages within a live connection.

Must-Know Lists exam

Many exam questions begin "list and explain", and you cannot explain items you cannot first name. These are the enumerations the exam can ask for, grouped by the Part that explains them. Check that you can reproduce every one from memory: cover the middle column, say the items aloud, then look.

Check yourselfName all eight transparencies, and say which two make up network transparency.

Access, location, concurrency, replication, failure, mobility, performance and scaling. Access + location together are network transparency. One way to remember them is in the order above: the first two are about reaching a resource, the next three about sharing and surviving, the last three about change (moving, load, growth).

Check yourselfAn NFS client cached a block with T_c = 100 s, the freshness interval is t = 3 s, and now T = 105 s. What must the client do before using the block?

T − T_c = 5 s, which is not less than t = 3 s, so the first test fails and the client must ask the server for the file's modification time (T_{m server}). If it equals the cached T_{m client}, the entry is still valid; otherwise the client discards the cached block and fetches it again.

Check yourselfList the three invocation semantics, plus what local calls give, and the three exchange protocols.

Invocation semantics: maybe, at-least-once, at-most-once; local calls give exactly once. Exchange protocols: R (request only), RR (request, reply) and RRA (request, reply, acknowledge reply). Part VI explains each.

Final-Week Plan

With a week to go, the risk is spending it re-reading, which feels productive but builds little recall. The study guide's plan spreads the last week over seven days, moving from section-by-section recall to full exam practice and then to light review. The exam is on Tuesday 10 November at 8:30 AM; counting back seven days puts Day 1 on Tuesday 3 November and Day 7 on Monday 9 November.

1. Days 1–3: one section a day. Read the section, close it, and write the answers to its self-test from memory. Then compare, and repeat the ones you missed.
2. Day 4: the 2026 practice exam under exam conditions: 15 minutes of reading with no writing, then 3 hours, closed book, handwritten, in pen. Write the RMI program in Q11 by hand from memory. Mark the paper against the worked answers in 11.9 and 11.10, post any draft you are unsure of on Ed for staff to review, and then do the 2016 paper if you have time.
3. Day 5: the must-know lists (11.6). Write each list from memory, and then do the same with the comparison tables.
4. Day 6: assignments. Rehearse 11.5 aloud for A1, and work through the same questions for your own A2 design: threading model, locking, failure model, protocol and consistency.
5. Day 7: light review only. Go over the mechanism walk-throughs: Kerberos, the TLS handshake, the NFS cache check, iterative versus recursive DNS resolution, an RMI call, and request-reply with duplicate filtering.

The plan placed the Zoom exam consultation (Tuesday 3 November, 3:00–5:00 PM) early in the week, so that questions from an untimed first attempt at the practice exam could be brought to it. It took place on 3 November; posting those questions on Ed with your draft answer is the route that stays open.

Tutorial Question Bank official

The weekly tutorial questions are short-answer questions in the same style as the 2016 paper, and staff have confirmed that tutorial content is examinable. Their official answers, written by the tutors and posted on Ed, are given at the end of the Part that teaches each topic. Use the table as a closed-book drill: answer each question aloud or on paper, then check the Part.

There was no tutorial on indirect communication, so for that topic use the self-test in Part VII.

Check yourselfWhich weeks' tutorials cover remote invocation, and what is the last question in that set?

Weeks 7–8 (Tutorials 6–7). The set ends with building a system with Java RMI, the same question the revision tutorial asks again as T11-5 (11.11), and the one the practice exam turns into a 10-mark program.

The 2026 Practice Exam: Q1 Multiple Choice 2026 practice

The official practice final exam for 2026 (COMP90015_26_SM2_SampleExam, posted on 20 October) is laid out exactly like the real paper: a cover page with the venue rules and permitted materials, then 11 questions with an answer box each, and two overflow boxes at the end. It is the best guide you have to the real paper, so this section and the next work through it question by question.

The table is the index: find a question, see what it asks and what it is worth, and follow the link to the Part that teaches it.

As 11.3 showed, every lecture from L1 to L10 is represented, so no lecture is safe to skip, and the paper rewards precise definitions and mechanisms more than open-ended design.

Q1: ten multiple-choice items 10 × 0.5 marks

In the exam you write only the letter of the one correct option for each item. Each item is given here as its scenario; open it to see the correct option, its reason and a picture of the mechanism. The reason is what lets you get a new item right, because the wrong options are near-misses built from the same vocabulary.

Q1 item 1Four replicated web servers sit behind a load balancer. One server's disk crashes, the load balancer stops sending it requests, and users notice no change. Which statement is correct?

(b) The disk crash is a fault, and because the website still meets its specification, the website did not fail. A failure is a deviation from the specification, and hiding a fault like this is what fault tolerance means (Part I).

Q1 item 2A UDP client sends a request to port 6789 on a server machine that is switched off, then calls receive(reply) without setting a timeout. What happens?

(d) send() returns normally and receive() blocks indefinitely. UDP has no connection to refuse and no acknowledgements, so send returns once the datagram has been handed over, and the loss is never reported. receive blocks until a datagram arrives, which here is never, because no timeout was set with setSoTimeout() (Part III).

Q1 item 3A server listens with new ServerSocket(5000), and a client whose operating system assigned it port 51234 connects. Which statement about the socket that accept() returns is correct?

(a) The socket that accept() returns is bound to server port 5000, and the server can keep accepting other clients on the original ServerSocket. TCP tells connections apart by the 4-tuple of both addresses and both ports, so many sockets can share local port 5000; 51234 is the client's port. Option (b) is the "different port" claim from Buyya's chapter, which Part III warns against.

Q1 item 4A client sends 100 requests over one TCP connection. How many threads does the server create under thread-per-connection, and how many under thread-per-request?

(c) 1 and 100. Thread-per-connection creates one thread when the client connects and serves every request on that connection with it, whereas thread-per-request creates a new thread for each request (Part IV).

Q1 item 5A price-comparison program runs at one retailer's server, then moves, with its code and the results so far, to the next retailer's server. What is it?

(b) A mobile agent: a running program, code and data, that travels between computers doing a task on someone's behalf. An applet is mobile code, which is downloaded once and runs only at the client. Price comparison across vendors is one of the standard uses of agents (Part II).

Q1 item 6No reply has arrived after 2 seconds, and the Internet is modelled as an asynchronous system. What can the client conclude?

(a) Nothing certain. An asynchronous system has no bounds on process speed or message delay, so a timeout means only "not responding yet": the server may have crashed, or the request, the reply or the server may simply be slow (Part II).

Q1 item 7Sensors that never join the group must get every alert to all three logging servers. What kind of group do the logging servers need to form?

(d) An open group, which accepts messages from processes outside it. A closed group accepts multicasts only from its own members (Part VII).

Q1 item 8An acknowledgement is lost, so the broker resends the notification and the order is processed twice. Which delivery guarantee is the broker providing?

(c) At-least-once delivery: resending until an acknowledgement arrives guarantees delivery but allows duplicates (Part VII, and Part VI for the same trade-off in remote procedure calls).

Q1 item 9Applications should receive an error after a few retries when the NFS server is unreachable, rather than wait. How should the file system be mounted?

(a) Soft-mounted. With a hard mount, the process blocks while the client retries until the server is reachable again (Part VIII).

Q1 item 10Once the NFS server has replied to a write, the data must survive a server crash, even if the client never sends a commit request. Which server write policy is needed?

(d) Write-through, which writes the data to disk before replying. Under the commit policy the data is safe only after a commit request, and a delayed write gives no guarantee at all (Part VIII).

The 2026 Practice Exam: Q2–Q11 2026 practice

The written questions follow. Each starts with the question as set, then gives the study guide's worked answer (again: not official, and not the only good answer), with a picture of the mechanism the question is about and a link to the Part that teaches it. Try each one on paper first; then compare not only the content but the length, which is pitched to fit the answer box.

Q2: Distribution transparency 5 marks Part I

Q3: TCP and UDP 5 marks Part III

Q4: Remote invocation definitions 5 × 1 mark Part VI

Two pictures carry the five definitions. The first shows how the two invocation semantics differ when a request is retransmitted; the second shows where the remote interface, the stub and the registry sit in a Java RMI system.

Q5: Microkernels and extensibility 5 marks Part V

Q6: The file service architecture 5 marks Part VIII

Q7: Uncoupling in publish-subscribe 5 marks Part VII

Q8: DNS caching and TTLs 5 marks Part IX

A TTL (time to live) on a DNS record says how many seconds a server may keep a cached copy before discarding it. An authoritative server is one that holds the master data for a name; a local server's cached copy is non-authoritative. The stepper traces the question's numbers on one time line.

Q9: A ticket exchange and its weakness 5 marks Part X

Notation: {M}K means message M encrypted with key K. A ticket is an item encrypted by a trusted server in the key of the service it is for, so only that service can open it. A session key is a fresh secret key for one conversation.

Q10: Digital signatures and certificate chains 5 marks Part X

Q11: A Java RMI dictionary service 10 marks Part VI

The answer follows the shape of the standard Hello example in Part VI, and the comment at the top of each file shows which part of the marking scheme it earns. The five files compile and run as written (the study guide checked them with Java 21). In the exam you can shorten the imports and comments, but keep extends Remote, throws RemoteException, the registry calls and the catch blocks, because those are what the marks are for. First, the shape of the program:

1. The remote interface interfaces: 2 marks

// DictionaryService.java -- remote interface, needed by BOTH sides   [interfaces: 2 marks]
import java.rmi.Remote;
import java.rmi.RemoteException;

public interface DictionaryService extends Remote {
    boolean add(String word, String meaning) throws RemoteException;   // ADD: false if present
    String search(String word)                                         // SEARCH: the meaning
            throws RemoteException, WordNotFoundException;
    boolean delete(String word) throws RemoteException;                // DELETE: false if absent
}

The interface is the contract both programs share. It extends Remote, which marks it as callable from another JVM, and every method declares RemoteException, because any remote call can fail in transit. SEARCH also declares an application exception, which RMI marshals back to the client and re-throws there.

2. The application exception

// WordNotFoundException.java -- application exception, sent back to the client by RMI
public class WordNotFoundException extends Exception {   // Exception is Serializable
    public WordNotFoundException(String word) {
        super("No such word: " + word);
    }
}

Because Exception is Serializable, an instance thrown in the server can be marshalled into the reply and thrown again in the client.

3. The servant implementation: 3 marks

// DictionaryServant.java -- implements the remote interface   [implementation: 3 marks]
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
import java.util.concurrent.ConcurrentHashMap;

public class DictionaryServant extends UnicastRemoteObject implements DictionaryService {
    // RMI may run calls from different clients on different threads: use a thread-safe map
    private final ConcurrentHashMap<String, String> words = new ConcurrentHashMap<>();

    public DictionaryServant() throws RemoteException {
        super();                                   // exports the object to receive remote calls
    }

    @Override
    public boolean add(String word, String meaning) {
        return words.putIfAbsent(word.toLowerCase(), meaning) == null;  // atomic check-then-add
    }

    @Override
    public String search(String word) throws WordNotFoundException {
        String meaning = words.get(word.toLowerCase());
        if (meaning == null) throw new WordNotFoundException(word);      // re-thrown at client
        return meaning;
    }

    @Override
    public boolean delete(String word) {
        return words.remove(word.toLowerCase()) != null;
    }
}

• extends UnicastRemoteObject: the superclass constructor, called by super(), exports the object, meaning it starts listening so that it can receive remote calls. That is why the constructor itself declares RemoteException.
• ConcurrentHashMap: the RMI runtime may run calls from different clients on different threads at the same time, so the words are kept in a thread-safe map.
• putIfAbsent does the check ("is the word already there?") and the insert as one atomic step, which avoids exactly the check-then-act race of A1-2 (11.5). It returns null only if nothing was there, so add returns true for a new word.
• search throws WordNotFoundException for an unknown word; delete returns whether something was removed. Words are lower-cased so that look-ups ignore case.

4. The server binding: 1 mark

// DictionaryServer.java -- creates the servant and binds it   [binding: 1 mark]
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class DictionaryServer {
    public static void main(String[] args) {
        try {
            Registry registry = LocateRegistry.createRegistry(1099);  // registry in this JVM
            DictionaryService dict = new DictionaryServant();         // create and export
            registry.rebind("Dictionary", dict);                      // name -> remote ref
            System.out.println("Dictionary server ready");
        } catch (RemoteException e) {            // e.g. port 1099 in use, export failed
            System.err.println("Server failed to start: " + e.getMessage());
        }
    }
}

The server starts a registry inside its own JVM with createRegistry, so no separate rmiregistry process is needed, and binds the servant under the name "Dictionary". The Naming.rebind("//localhost/Dictionary", dict) form from Part VI is equally acceptable. The program keeps running after main returns, because the exported servant keeps the JVM alive.

5. The client lookup and invocation: 2 marks · exceptions: 2 marks

// DictionaryClient.java   [lookup and invocation: 2 marks; errors and exceptions: 2 marks]
import java.rmi.NotBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class DictionaryClient {
    public static void main(String[] args) {
        String host = (args.length > 0) ? args[0] : "localhost";
        try {
            Registry registry = LocateRegistry.getRegistry(host, 1099);
            DictionaryService dict =
                    (DictionaryService) registry.lookup("Dictionary");  // returns a stub
            System.out.println(dict.add("socket", "an endpoint of a two-way link")
                               ? "Added" : "Already in the dictionary");
            System.out.println("socket: " + dict.search("socket"));
            System.out.println(dict.delete("socket") ? "Deleted" : "Not in the dictionary");
            System.out.println("socket: " + dict.search("socket"));  // throws: word gone
        } catch (WordNotFoundException e) {  // application error: no such word
            System.err.println(e.getMessage());
        } catch (NotBoundException e) {      // naming error: nothing bound as "Dictionary"
            System.err.println("Service not registered: " + e.getMessage());
        } catch (RemoteException e) {        // communication failure: server or registry down
            System.err.println("Remote failure: " + e.getMessage());
        }
    }
}

The client gets a reference to the registry on the server's host, and lookup returns a stub, cast to the interface type. From then on it calls ADD, SEARCH and DELETE on the stub as if it were a local object. The stepper runs the program from start to finish.

Check yourselfWhy must catch (WordNotFoundException e) come before catch (RemoteException e) in this client? Would the order matter for NotBoundException?

In this program none of the three is a subclass of another (WordNotFoundException extends Exception directly, and NotBoundException is not a RemoteException), so the order does not actually matter here: Java only rejects a catch block that comes after a catch of its own superclass. Order matters when one exception extends another, in which case the more specific one must come first. What matters for the marks is that the catch blocks handle distinct kinds of error.

Check yourselfA classmate's servant uses a plain HashMap and writes if (!words.containsKey(w)) words.put(w, m); for ADD. What two problems might a marker point out?

First, HashMap is not thread-safe, and the RMI runtime may run calls from different clients on different threads at once. Second, the check-then-act sequence is not atomic: two clients adding the same word could both pass the check and the second put would overwrite the first. ConcurrentHashMap.putIfAbsent fixes both (or a synchronized method around a HashMap).

Revision Tutorial: Official Answers official

Tutorial 11, in Week 12, was a recap of the whole subject, and its seven questions are a compact checklist of what staff consider central. The tutors' official solutions were posted on Ed on 23 October, and staff have confirmed that tutorial content is examinable, so these are answers to learn, not just practice. (The question slides open with a "Recap of Distributed Systems" item where question 1 would be and number the rest from 2 to 7, which is why earlier versions of the study guide said there was no question 1; the official solutions settle that the set runs from 1 to 7.)

Each answer below opens with the official answer, the points the tutors' solution slides make, and then gives the study guide's fuller explanation wherever it helps, saying where that goes beyond what the tutors expected. Where the guide's earlier answer disagreed with the official one, the answer says so. Each is about the size of a 5-mark exam answer.

T11-1. What is a distributed system? Part I

Give both, because they stress different things. CDK's definition is about the mechanism, and its word "only" rules out shared memory, while Tanenbaum's is about the user's view, the single-system image that transparency provides (Part I). This is the same question as Tutorial 1's first question. The tutors' answer stops at the two definitions, so if a question carries more marks, the natural extension goes beyond it: the three consequences that follow from CDK's definition, which are concurrency, no global clock and independent failures.

T11-2. What are the goals of distributed systems? Part I

The L1 slide on goals has a sixth, concurrency, and the study guide's earlier answer gave all six. Concurrency is not wrong, since it is on the lecture slide, but the tutors left it out, so if a question asks for the goals, lead with their five and add concurrency only as an extra. The official answer is just the list; the one-line explanations below go beyond it, and they are what turn a list into an answer worth the marks:

• Connecting users and resources, so that users can access and share remote resources such as printers, files, data and services. Resource sharing is the main motivation for building a distributed system.
• Transparency: hiding the distribution of the resources, so that the system is perceived as a whole rather than as a collection of independent components (the eight forms in 11.6).
• Openness: publishing the key interfaces, so that the system can be extended and re-implemented, and components from different vendors can work together.
• Scalability: remaining effective when the number of users and resources grows significantly.
• Enhanced availability: keeping the service usable when some components fail, through redundancy and replication.
• Concurrency, which is on the L1 slide but not in the tutors' list: letting many users and processes use shared resources at the same time, safely.

T11-3. What are the differences between TCP and UDP? Part III

The official answer covers only connection, reliability and ordering. The matched pairs below go further, and they are what a "give three differences" question needs, as in 2016 Q4(a) and the practice exam's Q3. So open with the official definitions and then give the differences as matched pairs, each naming its dimension (Part III has the full table).

T11-4. What is the life cycle of a thread? Part IV

This is the diagram to draw in the exam. The guide's version also has the dashed arrow from running back to ready, for yield() or an expired time slice, which the tutors' slide leaves out; drawing it is correct and costs nothing. And although stop(), suspend() and resume() are deprecated in modern Java, they are on the slide, so label the arrows as the slide does.

The guide's earlier answer used the five-state model from Tutorial 3, which describes the same life cycle with less detail. Its Runnable state is the slide's ready state, and its single Non-Runnable state merges sleeping, waiting and blocked. It is still a correct answer, and quicker to draw under time pressure, but since the tutors chose the seven-state diagram for the revision tutorial, learn that one first. In five-state terms a thread passes through:

• New: the Thread object has been created, but start() has not yet been called.
• Runnable: after start(), the thread is ready and waiting for the scheduler to give it a processor.
• Running: the scheduler has dispatched it, and it is executing run().
• Non-Runnable (Blocked): it is sleeping, waiting for I/O, waiting for a lock, or waiting to be notified. When the cause ends (the sleep finishes, the I/O completes, the lock becomes free or another thread calls notify) it goes back to Runnable, not straight to Running.
• Terminated: run() has finished, and the thread cannot be started again.

T11-5. Java RMI overview Part VI

Explain how one goes about using Java RMI to build a distributed system, what needs to be compiled, and the important parts of the system that must be used. No code is required.

The question asks what needs to be compiled, and the guide's earlier answer did not say. The official answer is that compiling the interface produces the proxy, dispatcher and skeleton classes. In current Java there is no separate rmic step, because proxies are generated at run time and reflection has made skeletons unnecessary, so it is worth saying both. The earlier answer also traced each call through the server's dispatcher, whereas the tutors' diagram shows a skeleton. In CDK's model both are there, with the dispatcher selecting the method and the skeleton unmarshalling the arguments and invoking the servant, so name the skeleton when you draw the tutors' figure.

The guide's points below go beyond the tutors' answer, but the remote interface, the stub and the registry are exactly what the practice exam's Q4 definitions test, so they are worth knowing. Java RMI lets an object in one JVM invoke methods on an object in another JVM, usually on another computer, with the same syntax as a local call.

• Model. The client holds a stub (proxy) that implements the remote interface, and the server holds the servant, the object that really implements it. The RMI runtime marshals calls with Java object serialization, carries them over TCP (using its protocol, JRMP), and gives at-most-once semantics.
• Remote interface. It extends java.rmi.Remote, and every method throws RemoteException. Remote objects are passed by reference, as remote object references, and other serializable objects by value, as copies.
• RMI registry. This is the binder. The server binds a name to its remote object, and the client looks the name up to get its first stub.
• Steps. First define the remote interface. Then implement the servant, usually by extending UnicastRemoteObject. The server creates the servant and binds it in the registry, and the client looks it up and invokes its methods, handling RemoteException.
• Behind each call. The call goes from the stub, as a request over the network, to the server's skeleton, which the dispatcher has selected, and on to the servant; the result comes back by the same route.

The 2026 practice exam asks you to write such a program in full: Q11 in 11.10.

T11-6. What are the classes of cryptographic algorithms? Part X

This detail goes beyond what the tutors expected, but it earns its place in a longer answer (Part X):

• Secret-key (symmetric) algorithms use one shared key both to encrypt and to decrypt, and are built from simple operations such as XOR, shifts and transpositions. They are fast, so they are used for bulk data, but the key has to be distributed securely. The block ciphers TEA, DES, 3DES, IDEA and AES are examples, and RC4 is a stream cipher.
• Public-key (asymmetric) algorithms use a key pair: what one key encrypts, only the other can decrypt, and the private key cannot feasibly be derived from the public one. They rest on trap-door functions (easy to compute one way, infeasible to invert without a secret), such as the difficulty of factoring large numbers in RSA. They make key distribution and signatures easy, but they are 100–1000 times slower.
• Hybrid protocols combine the two classes rather than forming a third. They use public-key cryptography to authenticate the parties and exchange a secret session key, and then symmetric encryption for the data. TLS and PGP work this way.
• Alongside these are secure digest (hash) functions, such as SHA-2 and MD5, which are one-way and collision-resistant. They are what digital signatures and MACs (message authentication codes) are built on.

T11-7. What are non-recursive and recursive server-controlled navigation? Part IX

Both are ways of resolving a name whose data is spread over several name servers, in which the client contacts a single server and leaves the navigation to the servers (Part IX). The explanation and trade-off below go beyond the official answer, but the point about tying up a thread in every server is what turns a definition into a 5-mark answer.

• In non-recursive server-controlled navigation, the server the client contacted acts as a client to the other servers, querying them iteratively or by multicast, and each one sends the next step back to it. That first server stays in charge of the whole lookup and finally returns the attributes to the client.
• In recursive server-controlled navigation, a server that cannot resolve the name passes the request on to another server, one that holds a larger prefix of the name, which does the same in turn. The result comes back along the same chain, and the client never learns which server resolved the name.

The trade-off: recursive navigation works across administrative domains that will not let outsiders see where their naming data is stored, but it ties up a thread in every server on the chain until the answer comes back. The non-recursive form keeps the navigation work in one server, which can then cache results for many clients. That first property is why, as the official answer says, DNS uses recursion in domains that restrict access to their data, even though iterative navigation is its standard.

Check yourselfHow many classes of cryptographic algorithm are there, according to the official answer?

1. One: public-key
2. Two: shared secret key and public/private key pair
3. Three: secret-key, public-key and hybrid
4. Four: secret-key, public-key, hybrid and hash

B. Hybrid protocols combine the two classes (C is the guide's old, corrected answer), and hash functions are a different kind of algorithm used alongside encryption (D).

Check yourselfA sleeping thread's time expires. Which state does it enter next, and why not running?

Ready. Leaving sleeping, waiting or blocked only makes the thread eligible to run again; it must wait for the scheduler to dispatch it, because another thread may be using the processor.

Check yourselfIn the recursive navigation diagram, which servers hold a thread busy while NS3 is working, and why does that matter?

NS1 and NS2. Each forwarded the request and waits for the reply to come back along the chain. With many concurrent look-ups, every server on every chain ties up resources, which is the cost of recursion; the non-recursive form keeps that waiting in NS1 alone.