Question 1 of 6: Characteristics of Distributed Systems

Question 1: Characteristics of Distributed Systems

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) Concurrency, heterogeneity, scalability. Concurrency arises because many independent clients may invoke the same shared resource (a file, an object, a database record) at overlapping times; the system must coordinate these accesses — typically via mutual exclusion, locking or transactional concurrency control — so results are consistent with some serial ordering rather than corrupted by interleaved updates. Heterogeneity is the diversity of networks, hardware architectures, operating systems, programming languages and implementations that a distributed system must span; it is addressed with standardized protocols (IP, TCP), platform-neutral middleware (CORBA IDL, Web services), and data representation standards (external data representation / marshalling formats) so components built on different platforms still interoperate. Scalability is the requirement that the system remain effective as the number of users, resources, or the geographic span of the network grows, without a proportional degradation in performance or an unbounded increase in administrative cost; techniques include replication, caching, partitioning/sharding of data and hierarchical or decentralized naming (DNS) rather than one central bottleneck.

(b) Three components that may fail on a remote method invocation, and mutual fault tolerance. A client invoking a method on a server object depends on three independently-failing components: (1) the client process — it may crash after sending the request but before receiving the reply (a crash failure), leaving the server holding state for a request whose caller no longer exists. (2) the communication channel/network — the request or reply message may be lost, corrupted, duplicated or delivered out of order (omission and ordering failures), for example a UDP datagram dropped by a congested router. (3) the server process/object — it may crash mid-execution (leaving the invocation partially applied), hang, or simply be too slow (a performance/timing failure) under load. Tolerance is built pairwise: the client tolerates channel/server failure via a timeout-and-retransmit request-reply protocol, made safe against duplicate delivery by designing the invoked operations to be idempotent or by having the server discard duplicates using a request identifier (at-most-once call semantics); the server tolerates client failure by not holding unbounded per-client state and by timing out/garbage-collecting abandoned partial work; and the system as a whole tolerates server failure via replication (a primary-backup or state-machine replicated server so another replica can take over) combined with logging/checkpointing so a restarted server can resume rather than lose the invocation entirely.

(c) Local-service discovery without naming the station. The natural approach is location-based, proximity-triggered service discovery: the phone determines its own physical location — via GPS (weak/unavailable indoors), cell-tower/Wi-Fi-based positioning, or simply by receiving a short-range wireless beacon broadcast locally by the station itself (e.g. Bluetooth Low Energy/Wi-Fi Direct advertising a station identifier and a directory-service address) — and uses that location, not a typed station name, as the key to query a directory/lookup service for "what services and amenities exist near coordinate X" or "what does beacon ID Y map to." This mirrors the classic ubiquitous-computing "active badge"/location-aware service pattern: the mobile device discovers services opportunistically from its surroundings rather than from a name the user must already know. Technical challenges: (i) the discovery/rendezvous problem itself — the phone has no prior knowledge of what services exist or how to address them, so a broadcast/multicast discovery protocol (analogous to SDP, mDNS or UPnP) or a beacon-to-directory lookup is needed; (ii) heterogeneity of the phone's OS/networking stack versus whatever local infrastructure the station runs; (iii) bandwidth, latency and battery constraints of an unfamiliar and possibly congested public wireless environment; (iv) privacy and security — the whole point of the scenario is that the user should not have to reveal identifying information (the station's own name/attributes) just to get a reply, which argues for the beacon carrying an opaque local identifier rather than any personally- or station-identifying string, and for the discovery exchange itself to be unauthenticated/anonymous by design; and (v) scalability of the directory service if many stations across a national rail network must each be independently discoverable this way.

(d) HTML, URLs and HTTP — advantages, disadvantages, general suitability. Advantages: all three are simple, open, human-readable/human-writable standards with universal, mature tool support; the URL gives every resource on the Web a single, uniform, globally resolvable name independent of the resource's physical location; HTTP is a simple, stateless request-reply protocol, which makes it easy to scale (any request can be served by any replica, and intermediate caches/CDNs can transparently short-circuit repeated requests) and easy to traverse firewalls (it runs on well-known ports 80/443). Disadvantages: HTML was designed as a document/hypertext markup language, not as a data-interchange or remote-invocation format, so building a typed, structured client-server protocol on top of it needs extra layers (JSON/XML payloads, REST conventions, or SOAP); HTTP's statelessness, an advantage for scaling, is a disadvantage for session-oriented applications, which must bolt state back on via cookies or tokens; plain HTTP has no built-in confidentiality or integrity (needs TLS/HTTPS); and URLs are fragile — a resource that moves or is deleted silently breaks every existing link ("link rot"), since there is no built-in redirection/renaming mechanism. Suitability as a general client-server basis: yes — despite the mismatch above, HTTP(S)/URL/JSON (the REST style) has in practice become the dominant basis for general-purpose client-server and even service-to-service computing, precisely because its statelessness, cacheability, universal firewall traversal and enormous tooling ecosystem outweigh the lack of a native typed RPC model; where a strongly-typed, high-performance RPC is needed instead, systems still layer a binary protocol (gRPC, Java RMI, CORBA IIOP) either alongside or underneath the same HTTP/2 transport rather than abandoning it outright.