Question 2 of 6: Fundamental Concepts and Mechanisms

Question 2: Fundamental Concepts and Mechanisms (20 marks)

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) UDP vs. TCP for FTP, HTTP and RPC. File transfer (FTP) moves a complete, often large, file where every byte must arrive intact and in order: TCP's connection-oriented, reliable, ordered, flow-controlled byte stream is the natural fit, since a lost or reordered segment would silently corrupt the file if left to the application to detect and fix; using UDP here would force FTP to reinvent TCP's sequencing/retransmission logic itself, which is wasted effort. Information browsing (HTTP) traditionally also runs over TCP for the same "reliable, complete document" reason, but each request-reply exchange is typically short-lived; TCP's per-connection handshake and slow-start overhead is a real (if usually small) cost for many brief transactions, which is one motivation behind connection reuse (HTTP keep-alive/HTTP-2 multiplexing) and, in HTTP/3, a move to UDP-based QUIC, which implements TCP-like reliability itself but avoids head-of-line blocking across independent streams. Remote procedure calls are usually small, latency-sensitive request-reply exchanges: UDP is attractive because it avoids the connection-setup round trip and per-connection state of TCP, and the RPC layer itself already needs its own request-reply/retransmission logic (to handle lost requests/replies, detect duplicates and provide at-least-once/at-most-once semantics) regardless of transport, so TCP's reliability is partly redundant; conversely, TCP is chosen instead when the RPC's argument/result payload can exceed a single datagram's practical size, or when passing through firewalls/NATs that only reliably allow established TCP connections.

(b) Discovering local server IP addresses, and resolving IP to Ethernet addresses. A newly installed PC has no IP configuration of its own; it broadcasts a DHCP (Dynamic Host Configuration Protocol) discovery request on the local Ethernet segment. A DHCP server on that segment replies with an IP address lease for the PC itself, plus configuration parameters — the default gateway, the subnet mask, and critically the addresses of local DNS servers. The PC can then use DNS to resolve the human-readable names of local servers to their IP addresses. Once the PC knows a target's IP address, it still needs the target's Ethernet (MAC) hardware address to actually frame and deliver a packet on the local network: it uses ARP (Address Resolution Protocol), broadcasting "who has IP address X" on the local segment; the host owning that IP address replies directly with its MAC address, which the requester caches (in its ARP table) for subsequent frames, avoiding repeating the broadcast for every packet.

(c) Three main advances embodied in IPv6. 1. Vastly larger address space. IPv6's 128-bit addresses (vs. IPv4's 32-bit) provide effectively unlimited unique global addresses, eliminating the address-exhaustion pressure that forces IPv4 into NAT and address-conservation workarounds, and restoring true end-to-end addressability for every device. 2. Simplified, more efficient header. IPv6's fixed-length, streamlined header (with optional extension headers carried separately rather than inline) removes fields IPv4 routers must otherwise inspect/process on every packet (e.g. the header checksum, since higher layers already checksum), speeding up router forwarding and hardware processing. 3. Built-in support for security and auto-configuration. IPsec was designed as an integral, mandatory-to-implement part of the IPv6 protocol suite (rather than IPv4's bolted-on optional extension), and IPv6 supports stateless address auto-configuration, letting a host derive a usable global address from local router advertisements without needing a DHCP server at all.

(d) The five TCP/IP layers.