25-Comp-B10 Distributed Systems · December 2019
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
U: x = write(i,55); write(j,66);” — assigning the result of a write to a variable is not meaningful pseudocode. Since the assigned name x is never subsequently read by U, this does not change the analysis below; U is treated as the two-operation transaction write(i,55); write(j,66), and T as x = read(i); write(j,44), exactly as printed.
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) Middleware limitations, and CORBA vs. Java RMI vs. Web services. Middleware's convenience comes at a cost: it adds an extra abstraction/translation layer (marshalling, stub/skeleton generation) that costs latency and CPU relative to hand-written networking code; it can hide the reality of partial failure so thoroughly that programmers write remote calls as if they were local, then are surprised by the different failure modes (network partitions, partial completion) that local calls never have; heavyweight middleware (classical CORBA) has significant learning curve and deployment complexity; and different middleware products are frequently not interoperable with one another, creating platform/vendor lock-in.
| Aspect | CORBA | Java RMI | Web services (SOAP/REST) |
|---|---|---|---|
| Language/platform | Language- and platform-neutral (IDL + ORB) | Java-only, homogeneous | Language- and platform-neutral (text protocol) |
| Wire format | Binary (GIOP/IIOP) | Binary (Java serialization) | Text (XML/SOAP or JSON/REST) over HTTP |
| Performance | Efficient binary, but heavy ORB infrastructure | Efficient for pure-Java systems | Higher parsing/transport overhead, but simplest to deploy over the open Internet |
| Interoperability | Cross-language via IDL, but implementations vary; largely legacy today | Very limited outside the JVM | Best Internet-scale interoperability; the de facto modern default |
(b) Three limitations of IPv4. 1. Address exhaustion. IPv4's 32-bit address space provides only about 4.3 billion addresses, long since insufficient for the number of Internet-connected devices, forcing widespread use of NAT and address-conservation techniques as stop-gaps rather than every device having a unique global address. 2. No built-in security. The base IPv4 header carries no authentication or encryption; confidentiality and integrity must be added by a separate layer (IPsec, or higher-layer TLS), so a plain IPv4 packet is trivially spoofable/eavesdroppable. 3. Weak support for QoS and modern traffic patterns. IPv4's header has no adequate flow-labelling for real-time/multimedia traffic, and its variable-length options field is rarely hardware-accelerated, making fine-grained quality-of-service and fast router processing harder than in IPv6's fixed, streamlined header.
(c) Network Address Translation. A NAT-capable border router/gateway maintains a translation table mapping each internal (private, RFC 1918) address and source port to a single public IP address and a (usually router-chosen) public port. As a packet leaves the private network, the router rewrites the source address/port to the public mapping and records the mapping; on the return packet it looks up the destination address/port in the table and rewrites it back to the original internal address/port before forwarding it inward. This lets many internal hosts share one (or a small pool of) public IPv4 address, directly mitigating the address-exhaustion problem from part (b), and as a side effect hides the internal network's topology and addressing from the outside (a modest security benefit), at the cost of breaking pure end-to-end connectivity for protocols that expect inbound connections to be initiated from outside (requiring port forwarding, STUN/TURN, or application-layer gateways for VoIP/P2P/some FTP modes).
(d) The five TCP/IP layers.
| Layer | Function | Example protocols |
|---|---|---|
| 5. Application | Application-specific message formats and semantics (naming, content, sessions) presented to the user program | HTTP, FTP, SMTP, DNS, Telnet, SSH |
| 4. Transport | End-to-end delivery between processes on two hosts: reliable, ordered, flow-controlled streams (TCP) or lightweight best-effort datagrams (UDP); port numbers multiplex processes | TCP, UDP |
| 3. Internet (Network) | Best-effort routing of packets across multiple networks between hosts, using a global logical address; fragmentation, TTL, error reporting | IP, ICMP, IGMP |
| 2. Data link | Framing and reliable-enough delivery of bits across one physical link/local network segment; addressing at the hardware (MAC) level and resolving IP addresses to it | Ethernet, Wi-Fi (802.11), PPP, ARP |
| 1. Physical | Transmission of raw bits over the physical medium — voltages, radio signals, optical pulses, connectors and timing | Ethernet physical-layer standards (10/100/1000BASE-T), DSL, fibre-optic standards |