25-Comp-B10 Distributed Systems · May 2013
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
(a) Choosing an IPC mechanism for multimedia conferencing. Datagram sockets (raw UDP) are the right choice. Audio and video conferencing generates a continuous, time-sensitive stream of small samples in which a late arrival is far more damaging to the user's experience than an occasional lost one — a dropped video frame or a brief audio glitch is tolerable and often concealed by the codec, while a frame delivered 300 ms late is simply useless once its playout time has passed. This rules out stream sockets (TCP): TCP's reliable, in-order delivery means a single lost segment blocks (head-of-line blocks) every byte behind it until it is retransmitted, which for a live stream injects exactly the kind of unbounded latency spike the application cannot tolerate, and TCP's congestion control will throttle the stream's rate in ways a fixed-rate codec does not expect. It also rules out both RPC options (over stream or datagram sockets): RPC's request-reply-and-block semantics fit a discrete, synchronous "ask a question, get an answer" interaction (e.g. querying a directory service), not a continuous, one-way, isochronous flow of media samples where there is no natural "reply" to wait for. Datagram sockets let the application make its own tradeoffs directly — sending each sample as soon as it is ready, choosing its own retransmission-vs-conceal policy, and pacing itself to the codec's real-time clock rather than a transport protocol's.
(b) Decreasing server-held reply data — the RRA protocol. With the plain request-reply (RR) protocol, a server cannot tell whether a client actually received its reply: if the client's own retransmission timer fires because the reply (or the original request) was lost, the server sees a duplicate request. To answer that duplicate correctly without re-executing a non-idempotent operation, the server must keep a copy of every reply it has sent, filed by request identifier, for as long as a duplicate might plausibly still arrive — and because a client's retransmission timeout is its own local, often adaptive value that the server cannot observe, this retention period is effectively unbounded (a server relying on RR alone cannot safely discard a reply until it is willing to risk failing a very late duplicate).
The request-reply-acknowledge (RRA) protocol fixes this by having the client send an explicit, small acknowledgement message as soon as it receives the reply. This directly answers both parts of the question: (1) the length of time a server must retain an unacknowledged reply is bounded by, and ends exactly at, the arrival of that acknowledgement — the server discards the cached reply the moment the ack arrives, rather than guessing at a client-side timeout it cannot observe; if the ack is itself lost, the server instead learns the reply needs resending when it sees the client's request retransmitted (a duplicate request is proof the client never got the reply), so in practice retention only needs to last until either the ack or a duplicate request is seen, both of which are bounded by the same round-trip-time-based timeout the client itself uses. (2) Servers do not have to continually resend the reply hoping for an acknowledgement: the RRA exchange is reactive, not proactive — the server sends the reply once and then simply waits; it only resends if a duplicate of the original request arrives (signalling the earlier reply was lost), and it never needs its own retry timer driving repeated, speculative resends. This design keeps server-side state small (one cached reply per outstanding, unacknowledged call) and pushes the cost of detecting loss onto the client, which is the party that already must run a retransmission timer to know when to give up.
