Introduction

Start from the question this lecture ends on. A client sends images to a pipeline that resizes each image, detects objects and draws bounding boxes. Where should each step run: on the client device, on a nearby edge box, on a fog node or in a distant cloud data center? And which latency number backs that choice? The last part of this lecture builds exactly that answer, and every idea before it supplies one piece.

The outline looks like a list, but read it as a chain in which each item answers a question the previous one raises. Take the running example of the lecture, a lamp you switch on from a web browser. To build it you first need a model of the system: which parts exist and who talks to whom. That model immediately asks how bytes move between machines, which is the job of the TCP/IP stack. Moving bytes is not enough; the browser and the lamp need a shared language for asking something to happen, and that language is HTTP. Your code then needs a programming interface for sending and receiving over the network, the socket. With those in place you can write an actual application, with a frontend in the browser and a backend on a server.

Only now can you ask the question the course is named after: where should that server run? The range of places between a device and the cloud where computation can live is the edge-to-cloud (E2C) continuum. The tool for choosing a place on it is the latency budget, the ceiling τ that a request's end-to-end response time must stay under. Placement is a latency decision, and latency comes from the network, which is why the lecture cannot skip the networking material to get to the interesting part faster.

A syllabus is a contract about scope: it tells you what can appear in exams and what counts as fair ground for your research project. COE 558 has two versions of that contract, and knowing both saves you from picking a project topic that is too narrow.

The slides describe what is taught this term. The official KFUPM catalog entry is the formal scope: it lists COE 558 as 3-0-3 (three lecture hours, no lab, three credits) with Graduate Standing as the prerequisite, and its description is broader than the nine topics taught in class.

The practical rule: study the taught topics for exams, but when you pick a research topic, anything in either list is in scope. Storage models and big-data frameworks get only one short line in class, yet they are rich research areas.

The foundations: three questions about the same application

The nine topics split into two blocks. The first three are the foundations, and they read as three questions about the lamp application from the lecture arc.

1. How do things communicate? Topic 1, this lecture: the TCP/IP stack, client and server roles, sockets, frontend and backend, and how latency shapes a web service on the edge-to-cloud continuum.
2. Where can it run, and how is it packaged? Topic 2: system thinking applied to the edge, fog and cloud layers, then virtualization: virtual machines, hypervisors and Docker containers.
3. Where should it run? Topic 3: what makes something a cloud, what edge computing adds, and when to combine both.

Packaging is the first place the course gets concrete. Docker's own documentation gives three short definitions worth memorizing now. An image is a read-only template with instructions for creating a container. A container is a runnable instance of an image. A registry stores images, and Docker Hub is a public registry. A virtual machine, by contrast, runs a whole guest operating system on virtualized hardware managed by a hypervisor, which is why containers are said to deploy faster. Treat that claim as a simplification. Docker says a container is relatively well isolated by default, but containers share the host kernel while each VM runs its own, so faster startup comes with weaker isolation than a VM, a trade-off you will study in topic 2.

Once something is packaged, the next question is what it means to run it in a cloud. The standard definition comes from NIST Special Publication 800-145. It names five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. The course emphasizes self-service, scalability and elasticity. NIST describes rapid elasticity as capabilities that can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand.

Build and operate: the remaining six topics

With the foundations in place, the other six topics move from understanding to building and operating real services. In order: what you rent from a provider (service and deployment models), a real open-source cloud you can run yourself (OpenStack), how services talk to each other (HTTP, REST and JSON through a Web API), how to run them at scale (containers, orchestration, monitoring), how to handle data at Internet scale, and how to keep all of it secure.

The thread running through them is the service. Service-oriented architecture builds an application from separate services that talk over the network. Microservices push that idea further: many small services, each deployed on its own. REST (REpresentational State Transfer, capitalized to spell out the acronym) is the usual way those services expose a web API: each thing is a resource with a URL, and clients act on it with standard HTTP methods such as GET and POST.

What you rent determines how much of that service stack is yours to manage. NIST defines three service models. With Infrastructure as a Service you rent virtual machines, storage and networks and manage everything above them. With Platform as a Service you deploy your code onto a managed runtime. With Software as a Service you simply use a finished application. NIST also defines four deployment models, which describe who the cloud is for: private, community, public and hybrid.

OpenStack makes those models tangible: it is an open-source platform for building your own cloud, assembled from separate services that talk to each other through APIs. In other words, it is itself a service-oriented system. The course names four of its services, and the official documentation describes each in one line.

Where the scope meets your project

Two of the build-and-operate items connect straight back to the placement problem at the end of this lecture. Client-service interaction for cloud and edge deployments is about requests crossing the continuum, and end-to-end processing pipelines are chains of steps that can each run in a different place (a service pipeline). Deciding which step runs on the edge and which in the cloud, under a latency limit, is a natural research direction, for example latency-aware task placement. Start a list of candidate topics now; the next concept explains why that list needs to exist in week one.

Start with the numbers, because they decide how you should spend your semester. The course has five assessments, and the research project inside them is split into three components.

Read the rubric as a pipeline

The three project components are graded separately, but they work best as stages of one pipeline, much like the image pipeline this lecture ends on: each stage consumes the output of the one before it.

• Reviews and critiques (8%). Critical reading, identifying a research gap (a question or setting existing papers leave open), analysing the methodology, weighing strengths and weaknesses, and finally proposing an initial research question. The question is the output of this stage.
• Seminar (7%). Technical understanding, presentation quality, critical discussion and Q&A. You are graded on whether you can defend a paper under questions, not only summarize it, so present a paper close to your research question.
• Final research study (20%). Problem formulation, literature review, proposed methodology, implementation or simulation, results and the final report. That is months of work, not the last two weeks.

Feeding the pipeline: reading papers in three passes

The first stage only works if you can read many papers without drowning in them. S. Keshav's widely used method reads a paper in up to three passes, each deeper than the last, so you spend real time only on the papers that earn it. The first pass takes about 5 to 10 minutes: title, abstract, introduction, section headings and conclusions. It should let you answer the five Cs: category, context, correctness, contributions and clarity. The second pass takes up to an hour: read carefully, skip proofs, study the figures and mark references you have not read.

The third pass means virtually re-implementing the paper, making the same assumptions and recreating the work in your head. Keshav estimates about four or five hours for beginners and about an hour for an experienced reader. By the end you can name implicit assumptions and weak points, which is exactly what the critique rubric asks for. For a literature survey he suggests finding three to five recent papers, reading their related-work sections, then following the citations and venues they share.

Protecting the pipeline: office hours

A pipeline is only as good as its earliest decisions, and in a research project the expensive ones are scope and method. A concept you did not follow can be re-read here. A research question that is too broad, or a methodology the instructor considers infeasible, costs weeks if you discover it at the seminar. That is what office hours are for.

The venue is written as Building #24 244, which reads as Building 24, Room 244. If you are unsure on the first day, check the room number on the registrar schedule.

Before you wire anything for a lamp you want to control from a browser, you already carry a picture in your head: the browser talks to something, and that something talks to the lamp. That picture is a mental model, and the first claim of this part is that good design starts there, not with code and not with hardware.

The claim is really about order. You do not jump from the problem straight to a solution; you first build a simplified representation of how the system works, and then derive the solution from it. The tool for building that representation is system thinking: describe the problem as parts, the connections between them, and the levels they sit on. A system seen this way is made of components, each one box with a job, and layers, each one a grouping of things that sit at the same level of abstraction.

The problem: a lamp, a browser, and a mysterious arrow

Now make it concrete. Draw Chrome on one side, a light bulb on the other, and one double-headed arrow between them. The browser is the client you already know. The lamp is the device. The arrow is where everything interesting hides. A browser tab cannot switch mains power; it can only send and receive messages over a network. So something must sit between the tab and the bulb, receive those messages, and turn them into electricity flowing or not flowing. The rest of this part is an answer to one question: what is inside that arrow?

The tempting answer: ad hoc

The first answer most people give is a part: "use a sensor", "buy a smart plug", "write a script". That is ad-hoc design, a component chosen before anyone has asked what the system actually is. The phrase comes from Latin ad (to) and hoc (this): for this specific purpose, a sense recorded in English from 1879. An ad-hoc design answers the immediate situation without previous planning.

For one lamp in one room, that can work. Now scale it: 50 lamps, a phone app next to the browser, a monthly energy report. With no named components and no agreed interfaces, each addition is another one-off wire or script, and nothing fits together. Ad-hoc designs may work for small isolated tasks, but they fail to scale or to integrate with larger systems.

The better answer: structured design

Structured design takes the same lamp but fixes the order of work: questions first, components second, code last. Design becomes a process, not a random walk. Notice what comes out of that process. It is not a sensor, a script or a board: it is a system, a named set of parts with defined connections. Named parts are what let a phone app or a second lamp plug in later without rework, and that is why structured design holds up under complexity, scalability and integration.

The structured process in this lecture is not mysterious. It is four questions, asked in a fixed order, and their highlighted words are the whole vocabulary of system thinking.

The order is forced by dependency. You cannot name relationships before you have components to relate, and you cannot group things into layers before you know what the things are. Treat the list as a reusable checklist: your research project architecture section must answer exactly these questions, and so must any exam answer that asks you to design or critique a system. This concept answers the first two for the lamp; the rest of the part answers the other two.

Question one: what is a system?

For the lamp, the boundary is the room plus the network, the parts are the browser and the lamp, and the things that happen between them are "switch on" and "how much energy have you used?". Generalize that and you get the definition: a system is an environment in which interactions occur between components. Three ingredients, each one necessary. The environment draws the boundary. The components are the boxes inside it. Each interaction is an arrow.

Question two: what are the components?

The lamp is decomposed in two refinement steps, and each step adds one idea. First, separate software from thing: browser and bulb become Application and Device, where the application is everything that is software and the device is the physical lamp. Second, split the application in two. The client is the user-facing interface, the part you touch. The server processes client requests and communicates with the device. That second component is the answer to the mystery of the arrow: it is the thing that sits between the tab and the bulb.

Read the visual left to right: the click starts at the client, the server relays it, and only when the path reaches the device does the lamp glow. No box can be skipped.

Why split the application: offloading

Why not let the browser do everything? Because a browser tab is a poor place to keep things. It is not running while the tab is closed, so it cannot record energy readings around the clock, and a phone and a laptop would each hold their own copy of the lamp state. The server is always on and shared, so it can do both.

That is offloading: the client hands functions it cannot or should not perform to the server, because the server has the processing and storage. The server hosts those functions as services, such as "set the lamp state" and "read energy use", and the client simply calls them. Deciding what to offload, and to where, is exactly what the task mapping later in the lecture varies: a task can run on the device, at the edge, in the fog or in the cloud.

Question three asks what connects the components. Start concrete: between client and server the lamp needs at least two exchanges, "set the state" and "read the energy".

Each exchange is one interaction, and the relationship is the whole set of them. In set notation, an interaction d is an element of a relationship R. That framing is useful because it tells you how to specify a relationship: list its interactions, and then say what every one of them has in common.

What they have in common splits into two halves. The protocol is the grammar both sides agree on: message format, order and meaning. For the Web that is HTTP, with its message format, methods, headers and status codes. The interface is the list of operations the server offers: the endpoints, each a method plus a path, that a client may call. Neither half is enough on its own. A shared language with nothing to ask for is useless, and a menu of operations nobody can phrase is equally useless.

The relationship we deliberately ignore

There is a second arrow in the lamp system, between server and device, and the lecture is blunt about it: it is not our concern. That is a design decision, not laziness. You may assume the server runs on a microcontroller board wired to the lamp. Inside that board, the program calls a hardware library; the library switches a pin; the pin drives a relay; the relay switches the lamp. That chain is a separate, lower-level relationship with its own protocol and its own interface.

The web client never sees any of it. It sees only the interface the server exposes. This is the payoff of defining a relationship by protocol and interface: each side can ignore the other side's internals, which is abstraction doing its job. Swap the relay for a smart bulb and the client does not change at all.

A relationship is a set of interactions, so the next step in specifying the lamp is to write that set down. It has two members, and each is a pair: a request from the client and a reply from the server. The client always speaks first.

In the visual, each interaction is a request drawn toward the server followed by a reply drawn back to the client, and the meter inside the server fills once the kilowatt-hour reply lands. The device sits behind the server, never talking to the client directly, exactly as the previous concept required.

One design detail matters more than it looks. Set_on_off should carry the value you want (on, or off), not mean "toggle". If the network drops the reply and the client sends the request again, a toggle flips the lamp back, while "set on" twice still leaves it on. Hold on to that thought: the next concept gives the property a name and shows that HTTP builds it into its methods.

What the energy reply actually means

The read interaction returns energy, and that is where many students slip. A watt measures power, which is a rate: how fast energy is being used. A watt-hour measures energy: power kept up for a length of time. A kilowatt-hour is 1 kW (1,000 W) used for one hour, and the usual appliance formula is wattage times hours, divided by 1000.

So far the interactions are abstract. On the Web they become concrete: set becomes HTTP PUT, and read becomes HTTP GET. The arrows carrying them are the protocol, HTTP, and the set and read operations exposed on the server edge are the interface, a Web API. The formula from earlier now has a real instance.

In the visual, the PUT and GET lines are the protocol, and the two sockets they seat into, set and read, are the interface. Only when both halves meet does the relationship work.

The actual messages

Here is what the two interactions could look like on the wire. Host and paths are illustrative.

The 204 No Content reply is the HTTP form of the abstract ok: RFC 9110 defines it as the server having fulfilled the request with no additional content to send.

Why GET fits read: safe

RFC 9110 calls a method safe when its semantics are essentially read-only: the client does not request, and does not expect, any state change on the server. Reading energy changes nothing, so GET is the natural fit. RFC 9205 adds a practical reason: implementations can and do retry GET requests that fail, so GET handling should not change application state.

Why PUT fits set: idempotent

Recall the toggle problem from the interaction list. HTTP has a name for the property that solves it. A method is idempotent when the intended effect of several identical requests is the same as the effect of one. PUT, DELETE and the safe methods are idempotent. PUT asks for the target resource to be created or replaced with the state enclosed in the request, so sending {"on": true} twice still leaves the lamp on.

This matters on real links. RFC 9110 says an idempotent request can be repeated automatically if the connection fails before the client reads the response, while a client should not automatically retry a non-idempotent request unless it knows the request is actually idempotent, or that the original request was never applied. Edge devices often sit on flaky wireless links, so this choice decides whether a retry is harmless or a bug.

Question four asks for the layers. For this system the answer is a single layer, the one where processing and storage happen: the server layer. Answering it forces you to notice that the word "server" has been doing two jobs.

The server component is the program, for example the Python or C code that answers requests for the lamp state. The server layer is that program together with everything it needs to run: the processor executing it, the network carrying requests, the memory holding the current state, and the disk keeping energy history. The component is what you write; the layer is what you must provision.

The visual starts with just the program lit, which is the component. The resources rise beneath it and the outline closes around all five: that outline is the layer.

The modern names for the server layer

Now the question the whole course answers: what do we call this layer today? Cloud, fog or edge, depending on where it is placed. Close the lamp story with that in mind. If the program runs on a board next to the lamp, the layer sits on the device side of the continuum (mist, or edge on a nearby gateway). If it runs in a distant data center, it is the cloud.

The standard definitions line up with the layer you just built. NIST defines cloud computing as on-demand network access to a shared pool of configurable computing resources, such as networks, servers, storage, applications and services, that can be rapidly provisioned and released: the same resources as the server layer, pooled at scale. NIST also describes fog computing as a layered model for access to a shared continuum of scalable computing resources, built from fog nodes that sit between smart end devices and centralized cloud services. Cloud, fog and edge together form the edge-to-cloud (E2C) continuum that the rest of the lecture studies.

In part 02 a browser controlled a lamp with HTTP requests: PUT /lamp/state to switch it and GET /lamp/energy to read its energy. Each request started on a laptop on KFUPM Wi-Fi and had to reach a server that might sit in a data center on another continent. Neither program knew the path in between, and neither needed to. That is the whole point of the TCP/IP stack.

Every host runs the same set of layers, so a client and a server can exchange bytes as if a private pipe joined them. The stack has a single purpose: connectivity. A program should only have to say who it wants to talk to and what it wants to send. Everything else in this part (layers, PDUs, addresses, sockets) is simply how that one job gets done.

Why split connectivity into layers

Hiding the path is a large job, far too large for one piece of software. Think about an air journey. You buy a ticket, check a bag, pass a gate, the plane takes off from a runway and air traffic control routes it. Each step relies on the step below it and offers a service to the step above. Kurose and Ross use exactly this example to motivate network layering.

The Internet divides connectivity the same way. The stack has five layers, and each layer provides one well-defined service using its own protocols. The payoff is explicit structure and modularity: a layer can change how it works internally without the rest of the system noticing. Wi-Fi can be swapped for 5G, and HTTP does not change a single byte.

Read the plus signs as composition, not arithmetic. No single layer delivers a web page. Connectivity emerges only when all five cooperate, the same way no single airport worker delivers you to another city.

Five layers versus seven

Part 02 used OSI as its example of a layered system, so it is worth lining the two models up. The OSI reference model (ITU-T X.200) defines seven layers. The Internet stack has no separate session or presentation layer. RFC 1122 says the Internet application layer essentially combines OSI presentation and application, and Kurose and Ross note that any such services must be implemented by the application itself.

The stack as the band between people and the physical world

Now zoom out to a whole system. Picture a distance sensor such as the HC-SR04 wired to a Raspberry Pi Pico. The Pico reads a distance, a Wi-Fi-capable board sends it across the network, and a dashboard in a control room shows it to a person. A command can travel the other way, down to an actuator.

The five layers form a band in the middle of that picture. Users sit above it and the physical world of sensing and actuation sits below it. The dashboard does not need to know how bits cross the air, and the device does not need to know how the dashboard draws its charts. This is modularity again, now at the scale of an entire system.

This is the same shape as the lamp system from part 02, and it is also the shape of your research project. In parts 08 to 10 the same pipeline is stretched across the edge to cloud continuum, and the question becomes where along it each piece of processing should run.

Layers cooperate by handing data to each other, and the way they do it is the single most useful mechanism in this part. Take a simple read request, GET /lamp HTTP/1.1. The application layer hands it down as a message. Transport puts a TCP header in front and it becomes a segment. Network adds an IP header and it becomes a packet. Data link adds a MAC header in front and a frame check sequence (a CRC) trailer behind, making a frame. Physical sends that frame as bits.

Each layer's unit of data is its protocol data unit (PDU). The process of wrapping is encapsulation, and it follows one rule: a PDU is this layer's header plus a payload, and the payload is the entire PDU of the layer above. On the receiving host the steps run in reverse. Each layer reads and removes its own header, then passes the payload up. Step through it yourself before reading on.

Who reads which header

Encapsulation is also what lets the middle of the network stay simple. Kurose and Ross label the headers Ht (transport), Hn (network) and Hl (link). A switch processes only the link and physical layers. A router processes network, link and physical. Only the two end hosts open the transport header and the application message. The IP header even carries a Protocol field that names the next-level protocol in its data (RFC 791, section 3.1), which is how the receiver knows whether to hand the payload to TCP or UDP.

These sizes come from RFC 791, RFC 9293 and RFC 768, and together they are the 40 bytes of layering overhead mentioned earlier. They also reveal a division of labor: IP has no acknowledgments, no retransmissions and no flow control (RFC 791, section 1.4). Reliability is added one layer up, by TCP, and only at the end hosts.

The header table ended with an address column, and that column is not decoration. Each header names something different because each layer connects something different. Your laptop on campus loads a page from a cloud server. The path goes over one Wi-Fi hop to the access point, through several routers, and finally over a data-center link to the server. Along that path there is one conversation between two programs, one route between two machines, and many separate links.

These are the three connection scopes. The transport layer provides an end-to-end (E2E) connection between two application processes. The network layer provides a host-to-host (H2H) path between two machines, however many routers lie between them. The data link layer handles point-to-point (P2P) transfer across a single hop between two directly attached interfaces.

The rule to take away: the higher the layer, the wider its scope and the more virtual its connection. Only the P2P links are real cables or radio channels. The E2E connection is not a wire at all. It is state held in the two end hosts: RFC 9293 (section 3.3.1) describes the TCP control block that stores the local and remote IP addresses and ports. TCP creates that state with the three-way handshake (section 3.5), while IP itself is connectionless. UDP keeps no connection state at all, yet its datagrams are still delivered process to process.

One address per scope

If each scope connects a different kind of thing, each needs its own way to name that thing. Look back at the encapsulation stepper. The server is 3.120.0.10, the service on it is port 443, and the next hop's interface is f4:8c:50:2b:e1:04. Three addresses, one per scope.

E2E names a process with a port number. H2H names a machine with an IP address. P2P names a network interface on the local link with a MAC address. (The course materials write "Mac"; the standard spelling is MAC, for Media Access Control.)

Ports are 16-bit fields in both TCP (RFC 9293) and UDP (RFC 768). IPv4 addresses are a fixed four octets (RFC 791, section 2.3). MAC addresses are 48 bits, burned into the NIC but sometimes settable in software, written like 1A-2F-BB-76-09-AD.

What changes at each hop

Putting scopes and addresses together gives the most useful insight of this concept. Along the whole path, ignoring NAT, the source and destination IP addresses and ports stay the same, because their scopes span the whole path. The MAC addresses are replaced at every hop, because their scope is one link: each router strips the old frame and builds a new one for the next link. To build it, the router uses ARP (RFC 826) to map the next hop's IP address to its 48-bit Ethernet address.

Addresses name endpoints, but a conversation needs more than one name. Open two browser tabs to the same server. Both tabs run on one laptop with one IP address, and both talk to one server port. Yet every reply lands in the right tab. Something must tell the two conversations apart.

The general rule builds up in three steps. A socket is one endpoint, an IP address plus a port number. A connection is a pair of sockets, one at each end, which is exactly how RFC 9293 defines it. When networks need to tell flows apart, they add the protocol and use the 5-tuple, which RFC 6437 (section 3) lists as destination address, source address, protocol, destination port and source port. The protocol field is what separates a TCP flow from a UDP flow that happens to share the same addresses and ports.

Notice how this ties back to the scopes. The 5-tuple uses only the E2E and H2H addresses, the ones that survive the whole path. The MAC address plays no part in identifying a connection, because it covers only one hop and would change before the reply ever came back.

So far the layers have been abstractions. The last step is to find them inside a real computer. A Node.js server asks the operating system for a socket and gets back a file descriptor. It writes bytes to that descriptor. Inside the kernel, TCP and IP headers are added. A driver hands the finished frame to the network card, which turns it into electrical or radio signals.

That story maps the layers onto three parts of one machine. The application layer lives in application space: the browser or server process, including its HTTP library. The transport layer and network layer live in the operating system kernel. The data link layer and physical layer live in the network interface and its driver.

Two seams separate these spaces. The socket API is the door between application and OS, which is why the socket of the previous concept is also a programming object. The Linux socket(7) manual calls sockets the uniform interface between the user process and the network protocol stacks in the kernel. Drivers are the door between OS and hardware. For the Web, the concrete stack reads: browser or server, HTTP, socket API, TCP, IP, Ethernet, then wired or wireless media.

The seams are also boundaries of privilege. An application cannot forge TCP state directly; it has to go through the socket API. This matters later in the course. Latency is added at every crossing, and virtual machines and containers in lecture 2 virtualize exactly these seams.

Picture two things you do before lunch. You open a KFUPM page in a browser. Then your mail program hands a message to the KFUPM mail server over SMTP. Both need the Internet. Only the first one is the Web. Getting this distinction right is the first step to thinking clearly about applications.

Infrastructure and the services built on it

The Internet is the infrastructure: the TCP/IP stack, the routers and the providers that carry packets. The World Wide Web (WWW) is one application built on top of that infrastructure. What makes something "the Web" is that it fetches linked resources using HTTP. MDN puts it plainly: "The Internet is an infrastructure, whereas the Web is a service built on top of the infrastructure."

History makes the order of events obvious. The Internet was carrying remote logins, email and file transfers for years before anyone had heard of a web page.

What counts as a network application

Once the Web is seen as one application among many, the natural next question is what the whole family looks like. Open HungerStation on your phone and order dinner. The app on your phone (the Client) sends the order across the Internet to the company's backend (the Server), which passes it to the restaurant and a courier. Without the network the app is just a menu picture.

The lecture's definition of a Network application is broad on purpose: any application that uses the Internet as its transport medium. That phrase has a precise meaning in the stack you met in part 03. The application hands its messages to the Transport layer through the Socket API, and everything below that line is someone else's job. What the messages mean is decided by the application.

Familiar apps hide an interesting mix. Some run inside a browser, some are native programs, and one exchanges its files with other users instead of a company server. Try sorting them yourself before reading the table.

uTorrent is the odd one out. It speaks the BitTorrent protocol, where the specification says that when many people download the same file at once, "the downloaders upload to each other". Each copy of the program acts as a client and a server at the same time. This arrangement is called peer-to-peer, and it returns in the next concept when we ask what decentralized means.

The protocol decides the circle

A useful picture, adapted from Connolly and Hoar's Fundamentals of Web Development, draws the Internet as a large circle with several smaller circles inside it: the Web, email, online gaming and FTP.

The rule for deciding which circle an application belongs to is its Application layer Protocol. If it speaks HTTP to fetch web resources, it is in the Web circle. If it speaks SMTP to move mail between servers, FTP to move files, or a custom game protocol, it sits in a sibling circle. Siblings share the Internet but not the Web. The circle sizes are illustrative only; they make no claim about traffic shares.

Email is a good exam trap. When you read Gmail in a browser tab, your browser talks HTTP to Google, which is the Web. When Google then delivers your message to a KFUPM mail server, the two mail servers speak SMTP, which is not the Web. One everyday "email" experience touches two circles.

Take one calculator and build it three ways. First, a desktop calculator: one program on one machine. Second, a browser page that sends "2+3" over HTTP to a separate server program, which sends back 5. Third, the same service, but the server's work and data are spread over several machines, with addition on one node and the history database on another.

By the lecture's definitions, the first build is neither decentralized nor distributed. The second is a Decentralized application: the application is split into two standalone components (Client and Server), usually on different machines, that talk through a Protocol using sockets. It is also a Distributed application in the lecture's sense, because computation is shared between client and server and state lives on both. The third build pushes distribution further: the server's own computation and data are spread over several machines.

Keep these two questions apart, because they become the two axes of the design space in the next concept: decentralization is the vertical axis, distribution the horizontal one.

The lecture's examples fit. BitTorrent and Bitcoin have no single controlling center: the Bitcoin paper opens with the goal of sending payments "directly from one party to another without going through a financial institution". Google Cloud is one provider that spreads computation and state across its own machines in many regions and zones around the world.

So far "the server" has been a single word. Look inside the calculator's server side and it turns out to be several separate pieces, and that discovery is what makes edge computing possible: separate pieces can live in separate places.

The server side is a set of components

Follow one request. The Client sends "multiply 6 by 7". It does not know or care how the server side is organized. It simply knocks on one door. That door is the API gateway, a single entry point that receives every client request and routes it to the right service. AWS describes its own gateway product as a "front door" for applications to reach backend services. Behind it sit four operation services (Add, Sub, Mul, Div), each exposing its own Interface, like a small Web API, and each able to read or write a Database.

Everything except the client forms the Server layer, typically hosted in the Cloud. But nothing forces those components to live together. Because each one is a separate program with its own interface, Mul could run close to the user while the Database stays in a large data center. The question becomes: can we assign server components to different layers, and if so, how do we describe and justify the assignment?

Two coordinates for every component

The answer is a grid that works like a seating chart. "Mul sits on Layer 1 using Compute 1." "The Database sits on Layer 3 using Compute 2 plus Storage." Every component gets two coordinates.

The two-dimensional design space separates two independent decisions about each Component, and they are exactly the two questions from the previous concept. Moving a box up or down changes its Layer: that is the decentralization axis, how far the server side is split across layers. Moving a box left or right changes the resource it uses on that layer: Compute 1, or Compute 2, which can also offer storage (only the Database uses it). That is the distribution axis, how computation and state are spread across resources.

A column is a type, each layer has its own instance

One subtlety makes the grid precise. A column names a resource type, not a machine. Each layer has its own copies of those types, and the lecture marks them with suffixes: Compute 2_a + Storage_a on the Database, Compute 1_b on Add, and Compute 2_b on Sub. The letter tells you which layer's copy: _a belongs to Layer 3 and _b belongs to Layer 2. So Add and Sub share a layer, but run on two different instances.

This is what makes the application a Distributed application in practice: the same kind of resource exists as several instances in different places, and the application's computation and state are spread across them. "Compute 2" could be a virtual machine type in a Cloud region, a server in a Fog micro data center, or a box at the Edge.

Criteria for assigning components to layers

The grid tells you how to write a placement down. It does not tell you which placement is good. For that the lecture asks: what criteria decide which layer a component goes on? There is no single right answer, only trade-offs. Each criterion pushes a component in a direction.

The evidence behind the table comes from the edge computing literature. Satyanarayanan writes that "reliance on a cloud datacenter is not advisable for applications that require end-to-end delays to be tightly controlled to less than a few tens of milliseconds." NIST adds that Fog computing "minimizes the request-response time" by working close to end devices. So a time-critical component moves toward the Edge, lowering Latency and Response time (RT).

The pull goes the other way too. Heavy computation and durable, shared data need resources that shrink as you go down the layers, which is why the Database sits on the top layer. Satyanarayanan also notes that analyzing raw data near its source cuts the bandwidth sent to the cloud, that a nearby cloudlet "can enforce the privacy policies of its owner prior to release of the data to the cloud", and that local resources give the "ability to mask transient cloud outages". Google Cloud, for its part, sells regions partly so data can stay resident inside a country's borders.

Placing components on layers only works because they can talk to each other across a network. So zoom in on one conversation. Open the calculator in a browser and press equals. The front-end JavaScript sends GET /add?a=2&b=3. A Node.js back-end reads that request from its socket, computes 5, and writes the response back. Along the way the bytes travel through routers you will never see.

Three levels in one conversation

At the top is the application conversation: an HTTP request and response. In the middle are the endpoints, the sockets. At the bottom is the network path through the Internet. The Frontend runs in the browser, and the Backend runs in Node.js.

RFC 9110, the HTTP standard, defines the roles by behavior. A Client "is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests". A Server "is a program that accepts connections in order to service HTTP requests by sending HTTP responses". And HTTP itself "is a stateless request/response protocol for exchanging messages across a connection".

Sockets are endpoints, connections are pairs

A socket is named by an IP address plus a Port number. The connection is the pair of sockets, one at each end, as in this example using documentation addresses:

The HTTP arrow is logical, the bytes move vertically

Protocol pictures usually draw a dashed arrow between the two HTTP boxes, as if browser and server talked to each other directly. They do, but only logically. No HTTP byte ever travels sideways along that arrow.

The real journey is vertical. The browser writes an HTTP message. It goes down through TCP on the client and the Socket, into the TCP/IP network (the "pipe"), and back up through TCP on the server until Node.js reads it. This is Encapsulation from part 03: each layer wraps the data on the way down and unwraps it on the way up. Peer layers "talk" to each other only through that round trip.

The same picture also shows who owns what. The Application layer (AL) is the web application, written by developers: HTML, CSS and JavaScript in the Frontend, and Node.js in the Backend. The Transport layer (TL), Network layer (NL), Data link layer (DLL) and Physical layer (PL) are infrastructure, provided by the operating system, network cards, cables and routers. That split is the same line that defined a network application in the first concept: the app owns meaning, the infrastructure owns delivery.

Step back from a single message to the rhythm of the whole exchange. Your browser asks the calculator for a result. The server wakes up, spends processor time computing it, reads and writes the history, and sends bytes back. Then it waits for the next request. It never phones you first.

That cycle is the Request-response loop. The Client initiates, and the Server only responds. RFC 9110 builds HTTP around exactly this pattern: a client sends a request message, and a server answers it with a response message.

Every response has a price

This is where the part comes full circle. Preparing each response costs the server three resources. Compute is the processor time, which you will later measure as Processing time (PT). Storage is reading and writing data. Communication is sending the response back over the network. For one user that is trivial. Multiply it by, say, 10,000 users pressing equals at once, and those three costs decide where each component in the design space should live.

It is also why placement matters to users. The time a user waits, the Response time (RT), is the trip to the server, the processing, and the trip back. NIST describes Fog computing as a way to minimize the request-response time. Moving the right component closer shortens the loop.

Think about what your browser does when you open the KFUPM portal. It cannot put signals on the Wi-Fi radio or build TCP segments by itself. Instead it makes a few requests to the operating system: open a connection to this address and port, send these bytes, give me whatever comes back. The operating system does everything below that. Understanding exactly what that request looks like is the foundation for everything else in this part.

An API is a menu, and the socket API is the networking menu

The set of operations one piece of software offers to another is an Application Programming Interface, or API. Earlier in this lecture you saw that a relationship between components is a protocol plus an Interface. Here the interface sits between the Application layer (your program) and the Transport layer (TCP and UDP inside the operating system). For networking, that interface is the Socket API.

Kurose and Ross describe the socket as the door between the application process and TCP. As a developer you control everything on the application side of that door, and you have very little control over the transport side. The rest of this concept opens the door and looks at what is actually there.

What a program actually holds: a file descriptor

Make it concrete. In C, calling socket() returns a small integer, for example 3. From then on the program writes write(3, ...) exactly as it would for an open file. POSIX states that when the descriptor refers to a socket, write() is equivalent to send() with no flags, and the Linux manual says the only difference between recv() and read() is the flags argument.

So to a program, a Socket is an operating system object that it reads and writes like a file. The kernel takes the bytes you write and turns them into TCP segments or UDP datagrams, which is why the application never needs to know how either protocol works. Be careful with the words: the socket API is the interface, and a socket is the endpoint that the API creates and names.

Naming the endpoint: the socket address

A file on disk has a path; a socket has an address: an IP address plus a Port number, for example 10.0.0.5:443. The IP address finds the host and the port finds the process on that host, the same two-level addressing you met with the TCP/IP stack. RFC 9293 identifies a TCP connection by a pair of sockets, one at each end, so a connection is really four numbers: client IP and port, server IP and port.

One more ingredient completes the name. The protocol is fixed when the socket is created, so TCP port 53 and UDP port 53 are different endpoints even on the same host. DNS, as RFC 1035 specifies, listens on both.

The lifecycle of a connection

A Server and a Client play different roles, so they use different calls. The server must be findable before anyone arrives: it creates a socket, binds it to a well-known address, marks it as listening, then accepts connections one by one. The client already knows where to go, so it only creates a socket and connects. Once connected, both sides send and receive, then close.

Once you know a program holds a socket, the next decision is which kind. Take two jobs. First, downloading a 2 GB dataset for your project: one missing byte corrupts the file, so every byte must arrive, in order. Second, a live video call: a voice frame that arrives 1 s late is useless, so waiting for it to be resent makes the call worse, not better. These two jobs need different sockets, and the difference is fixed the moment socket() is called.

Two services behind the same API

A TCP socket is a stream socket. RFC 9293 describes TCP as a reliable, in-order, byte-stream service. It sets up a connection with a three-way handshake, numbers every byte, checks it with a checksum and retransmits what is lost. That reliability costs setup time and state on both hosts, which is exactly the connection that listen(), connect() and accept() manage.

A UDP socket is a datagram socket. RFC 768 says UDP offers a minimum of protocol mechanism: delivery and duplicate protection are not guaranteed, and the header is just four 16-bit fields (source Port number, destination port, length, checksum), 8 bytes in total. There is no listen or accept: each datagram stands alone. POSIX names the two kinds SOCK_STREAM and SOCK_DGRAM.

Choosing a socket for a workload

The right question is not which is faster. Ask what happens to your application when one unit of data is lost or late. If it must be recovered, use TCP. If late data is worthless, or the exchange is tiny and easy to retry, UDP avoids overhead that buys you nothing. For interactive media this is really about Latency: a retransmitted frame arrives after its moment has passed.

The last row of that table shows that the choice is not always binary. RFC 9114 defines HTTP/3 as the same HTTP semantics over a new transport, QUIC, and RFC 9000 says QUIC packets are carried in UDP datagrams. QUIC rebuilds reliable streams, flow control and encryption in user space on top of UDP. So choosing UDP does not always mean giving up reliability. It means a protocol or library above UDP decides how much reliability to add, and when.

Now bring sockets to the web. You type https://uni.majid.app and press Enter. The browser resolves the name, asks the operating system to open a TCP connection to port 443 (or QUIC over UDP for HTTP/3), sends the HTTP request, reads the response, and may reuse the same connection for the next requests. The page code only calls fetch("/api/...") and never sees a Socket.

The browser owns the client socket

A web application is a Network application in which the browser is the Client program and owns the client socket: when to open it, reuse it and close it. MDN puts it simply: browsers communicate with web servers using HTTP, by sending a request to the server. Every socket call from the lifecycle above is still happening, just inside the browser and inside the server runtime.

This changes the level at which you work. Frontend code for the World Wide Web is written in terms of HTTP requests, and backend code is written in terms of routes that answer them. The socket becomes infrastructure you rely on rather than an object you manage.

Three components: client, server, database

So what is on the other end of that connection? Picture a course portal. You submit a homework answer. The browser sends a request over the Internet. The server checks it and writes a row to the database. When you reopen the page later, the server reads that row and sends it back in a response.

The pieces have names. The Frontend is one Component: the client. The Backend is two components: the Server and the database. The client talks only to the server, never directly to the database. MDN describes the same flow: on a request, the server fetches data from the database and builds the response. This is the Request-response loop you met with network applications, and the client always starts it.

Look at the server to database link closely, because it reuses everything from the first concept. It is itself a client-server connection over sockets, with the web server acting as the database client. Writes flow from server to database and reads flow back. A web application is therefore a chain of socket conversations, each with its own client and server role.

Why server and database often live apart

• They scale separately: many identical server instances can share one carefully managed database.
• Their resource needs differ: the server wants CPU, the database wants disk and memory.
• The database can be kept off the public Internet, reachable only from the servers.

This is the first placement decision on the edge-to-cloud continuum. Later parts ask where the server and the database should each live, and every placement has a cost: each read or write between separate machines adds its own network Round-trip time (RTT), which later feeds into Response time (RT).

The architecture becomes real when you read the code on each side. Consider a calculator running in the browser and the backend that serves it. Walk one request through: the user opens the About view, and the frontend sends GET /calculadora/about.

From request to handler to response

On the Backend, the framework compares the request method and path against its routes. It finds the route with method GET and path /calculadora/about and calls its handler, handler(request, h). The handler builds an object with a message field and returns it. In hapi, a returned plain object becomes the response payload, serialized as JSON. The browser receives that JSON in the HTTP response body and the Frontend renders it.

The general rule: a route is a method plus a path plus a handler. The set of routes a backend exposes is its Web API, the Interface the frontend programs against, while HTTP is the Protocol carried between them. Protocol plus interface again, one level higher than the socket API. Underneath, the Node.js runtime owns a listening socket and one connection socket per Client, exactly the welcoming door picture from the first concept.

Same language, different machines

Notice the languages. The frontend uses HTML for structure, CSS for presentation and JavaScript for behaviour, all inside the browser. The backend also runs JavaScript, but in the Node.js runtime on the Server. Same language, different processes on different machines, joined only by HTTP over a socket.

Part 05 ended with a simple picture: a web app is a Client talking to a Server. The natural next question is where that server should actually sit, and the answer turns out to be "not in one place, but anywhere along a range".

The path is not an empty wire

Picture a student in Dhahran opening a web app whose only server is in a data center on another continent. Every click travels the full distance out as a request and the full distance back as a response. Now add three stops along the way: one in the campus building, one in the city, one in the region. Each stop is closer to the client than the far server is, so any work that can run at a nearer stop comes back sooner.

Seen this way, the space between client and server is a range of places where compute and storage can live. Latency grows as you move away from the client, and so does capacity, because far sites are larger. Placing layers along that range lets each request be answered by the nearest layer that is powerful enough to handle it.

This is not an invented teaching device. NIST describes fog computing as a layered model for accessing a shared continuum of computing resources, with nodes organized by their latency and distance to the end devices, and with different layers providing different services while working together as a continuum (NIST SP 500-325).

What makes a range a continuum

The word Continuum is doing real work here, so pin it down with the clearest example there is: visible light. Walk along the spectrum from 400 nm to 700 nm. Move one nanometer and the color does not visibly change. There is no single nanometer where blue stops and green starts. Yet 400 nm (violet) and 700 nm (red) are obviously different colors. That is the whole definition in one picture: neighboring points barely differ, while the two ends differ a lot. The Britannica Dictionary and Wiktionary put it the same way: a continuous series where no part is noticeably different from its neighbors, although the ends are very different from each other.

The familiar names on the wider electromagnetic spectrum (gamma, X-ray, UV, infrared, microwaves, radio) are labels people put on that smooth range because labels are useful. They are not walls that nature built.

Now map it back to computing. In the Edge-to-cloud (E2C) continuum, the two endpoints are "computing on the device itself" and "computing in a hyperscale cloud region". Everything between them is a candidate location for the layers above. The names you will meet in Part 08, Mist, Edge, Fog and Cloud, work exactly like UV and infrared: convenient labels on one range, where latency to the client and available capacity both grow as you move away from the device.

Layering along a distance is not new. The network you use every day already splits one long path into segments, each built with the technology that suits its span.

Make it concrete. A student sits in a KFUPM lab and sends a print job to a partner office in Riyadh. The first hop is the lab's Ethernet switch. The middle of the journey crosses routers in a wide area network. The last hop is the office's own switch, which delivers the job to the printer. Three segments, three tiers along the distance.

Why one technology cannot run end to end

A switch works at the Data link layer and forwards frames by MAC address. It fills its forwarding table by flooding and learning, which is cheap and automatic inside one building but does not scale to the whole world: flooding every unknown frame to every port of every network on Earth would be absurd. A router works at the Network layer and forwards by IP address, using tables computed by routing algorithms over hierarchical address blocks, which is exactly what scales across many networks (Kurose and Ross, Chapter 6). Each technology is excellent inside its own range and poor outside it, so the path is built from pieces that each fit a stretch of it.

This is the networking Continuum: distance grows along the path, and connectivity is assembled from tiers that each serve one stretch. Keep the shape in mind, because the edge-to-cloud continuum does the same with compute instead of connectivity, and the memory hierarchy, next, does it with time instead of distance.

The second place layering already exists is inside every computer. Here the axis is not kilometers but time: how long it takes the CPU to reach a piece of data.

Imagine a loop that sums a large array. The running total is touched on every instruction, so it lives in a register, right inside the processor. The chunk of the array being read right now is touched thousands of times a second, so it lives in cache. The rest of the dataset sits in RAM, and the file it came from sits on disk. Each step outward is slower to reach, but holds more.

This arrangement is the Memory hierarchy, a Continuum of access times. The rule is simple: the more urgently and frequently data is needed, the closer to the CPU it lives. Hennessy and Patterson describe the same picture: as you move away from the processor, each level is slower and larger, with times ranging from picoseconds up to milliseconds for magnetic disks. Notice the match with the network path: near tiers are small and fast, far tiers are large and slow.

Why a small fast layer is enough

If fast memory holds only a tiny fraction of the data, why does it help at all? Because of locality. Programs tend to reuse data they touched recently (temporal locality) and data stored near it (spatial locality). So a small, fast layer that keeps those items can answer most requests. Denning notes that this one principle shapes processor caches, disk caches, storage hierarchies and edge caches for the Web. That last item is the bridge to this course: an edge site works for the same reason a CPU cache does.

A ranking tells you the order of the levels; measurements tell you how much each step costs. To measure a level you need two quantities: bandwidth (how much data per second it can move) and latency (the fixed access delay paid on every fetch). Storage is simply the size of each level.

Start with a video editing workstation. The frame on screen right now sits in cache or registers, because it is touched constantly. Today's raw clips are pulled from the SSD into RAM so they can be processed quickly. Last year's projects stay on slow archive storage and are fetched only when you open them. That is the Memory hierarchy used as a placement policy, and the question is how big the gaps between levels really are.

The measured hierarchy

The Cornell Virtual Workshop publishes figures measured on Intel Skylake server processors. Reading outward, bandwidth is roughly cut in half at each level while latency roughly quadruples. The real steps vary, so read this as a rule of thumb.

The bandwidth figures come from a Sandia National Laboratories evaluation of Skylake (Hammond, Vaughan and Hughes, 2018), and the latencies were measured on a closely related Xeon model. Latency is also quoted in clock cycles, such as "4 cyc." and "14 cyc.". 2 ns in 4 cycles implies about 0.5 ns per cycle, a clock of roughly 2 GHz (our own arithmetic, not a published figure).

Turning two resources into one time

Bandwidth and latency only become useful for decisions once you combine them into the time a fetch actually takes. Cornell gives a simple model for any level:

Here T is time, S is the size of the data, B is bandwidth and L is latency. For a tiny fetch, S/B is close to zero, so latency decides everything. For a huge transfer, the S/B term dominates and bandwidth decides.

The analogy the course is built on

Now every piece is in place. CPU cache is to RAM as Edge is to Cloud. Both put a small, fast, nearby tier in front of a large, slower, distant one. Both answer most requests from the near tier because of locality, and both fall back to the far tier on a miss. Interactive requests are small, so by T = S/B + L they are latency-bound and benefit most from a nearer tier. Bulk analytics is not interactive, so a few extra milliseconds of latency cost it little, and it needs far more compute than an edge site has. That is why Offloading it to the cloud, where capacity is, makes sense, as long as the data can be moved there or already lives there.

Picture a student in Dhahran opening an app whose backend runs in the AWS Frankfurt region. His phone sends a request that must physically cross about 4,400 km of Earth, and the answer must cross it again on the way back. Nothing useful can happen on his screen until both trips are done.

Latency is transit time, paid in both directions

That travel time is Latency: the time data spends in transit between two points. In the Request-response loop you met earlier, the Client always starts, so every exchange pays latency twice: once from client to Server, once from server back to client. Total network latency is the sum of the two one-way figures. They are often close, but they need not be equal, because Internet routes are not always the same in both directions.

Putting the server in the Cloud is the default because it is convenient, elastic and cheap to operate. The natural next question is how much time that choice costs at the very least, before any engineering detail enters the picture.

The smallest latency physics allows

Start with a number. A server 3,000 km away, reached at the speed of light, needs 3,000 ÷ 300,000 = 0.01 s, which is 10 ms one way. So every 1,000 km costs at least 3.3 ms one way, or 6.7 ms for a round trip.

Generalising this gives the Latency lower bound: divide the Geodesic distance by the speed of light $c$. It is a lower bound for three reasons that stack. Nothing carries information faster than light. No cable between two cities can be shorter than the shortest path along the Earth. And the formula ignores every other delay a real packet meets. Because each simplification can only make the true figure larger, the result is a floor that no provider, protocol or hardware upgrade can break.

Real glass is slower than vacuum

“Speed of light” in the bound means light in a vacuum. Real links carry light through glass fiber with a refractive index of about 1.5, so the signal moves at roughly 200,000 km/s, about two thirds of $c$ (Grigorik, High Performance Browser Networking). Even a perfectly straight fiber therefore needs about 1.5× the bound. ITU-T G.114 plans 5 µs/km for optical fibre systems, which is 5 ms per 1,000 km, against 3.3 ms per 1,000 km at $c$. Keep both numbers in mind: the vacuum bound is the absolute floor, and the fiber floor is the realistic best case for a cabled network.

Try the simulator. Pick the Frankfurt preset and read the one-way bound, then read the round-trip value to see the number doubled. The presets use the distances implied by the lecture’s own figures (for example 11,100 km for Oregon), a choice examined closely when we compare bounds with measurements below.

The bound is only as good as the distance you feed it, so which distance is the right one? Stretch a string tight between London and Singapore on a real globe. It does not run across Arabia the way a ruler on a flat map suggests. It runs north, over Eastern Europe and Central Asia. Now flatten that globe into a rectangle: the string that was the shortest path turns into a curve.

Those are the two candidates. A straight line drawn on the flat map gives the planar distance. The curve that the string traces gives the Geodesic distance between the same two endpoints. Esri’s documentation defines planar distance as straight-line Euclidean distance in a 2D Cartesian coordinate system, and geodesic distance as distance across the curved surface of the world in 3D. Signals travel over the real Earth, not over a map, so latency lives in the second definition.

Map projections stretch the Earth, and the stretch grows with latitude and with the size of the area. Over a city block the two distances agree. Over continents they can disagree a lot, and near the equator they can be surprisingly close: Esri notes that for Singapore to Nairobi, about 7,440 km, the Web Mercator planar result is less than a metre longer. Because you cannot know in advance which case you are in, always use the geodesic when you compute a Latency lower bound. Using a planar distance that happens to be too short would even produce a “bound” that is not a bound at all.

With the right distance and the right formula in hand, the bound can finally meet reality. Put the client in Dammam and the server in three AWS regions: US West (Oregon, us-west-2), Europe (Frankfurt, eu-central-1) and Asia Pacific (Tokyo, ap-northeast-1). For each, compute the one-way Latency lower bound, then compare it with the Round-trip time (RTT) measured with aws-latency-test.com.

The rule behind the example: compare like with like. An RTT is a round trip, so compare it with twice the one-way bound, never with the one-way figure itself. Doing that for all three regions tells the same story each time: the measurements sit about 2.9× to 3.4× above the vacuum round-trip bound. A ratio that stable across very different distances is a hint that the extra cost is systematic, not bad luck on one path.

Where the factor of three comes from

• About 1.5× comes from glass alone, because light in fiber moves at about two thirds of $c$.
• Cables do not follow the geodesic. They follow coastlines and seabeds, land at a few stations, and backhaul over land to data centers.
• Each router on the way adds processing and queueing time, two of the four delays in the next concept.

Research agrees with this breakdown. Singla and colleagues measured Internet paths worldwide and found router paths about 2.3× the speed-of-light latency at the median. After removing the 1.5× fiber factor, path detours alone still leave about 1.53×.