Introduction

AOverview

This lecture is the foundation every later topic in the course stands on. It starts with something small, switching a lamp on from a browser, and ends with a question that drives real engineering work: where on the edge-to-cloud continuum should each part of an application run so that it answers in time?

As a PhD student you need it for three things. The exams test whether you can name layers, sockets and tiers precisely and compute latency and response time without hesitation. The research project, worth 35% of the grade, asks you to design and justify a system, and that justification is exactly the reasoning taught here. Beyond the course, any edge or cloud system you build or review is judged by the same test: does its response time stay within the budget, RT ≤ τ?

The path has five stops. You model the lamp as a system of client, server and device. You place its conversations on the TCP/IP stack and the sockets beneath HTTP. You measure what distance costs, since a signal cannot beat the speed of light. Finally you spread the server layer across device, edge, fog and cloud and check each mapping against its latency budget.

Success looks like

• Decompose a system with the four design questions into components, relationships and layers, and draw it.
• Tell the Internet from the Web and place any application protocol on the correct layer of the TCP/IP stack.
• Trace one HTTPS request through the socket calls on both the client and the server.
• Compute the round-trip latency lower bound from a geodesic distance and explain why a measured RTT is larger.
• Compare device, edge, fog and cloud on latency, capacity, privacy and reach for a given workload.
• Map the tasks of an application onto the continuum and test the mapping with RT = L1 + PT + L2 ≤ τ.

How to study this lecture

1. Choose your route. Read the full guide in one sitting for the big picture, or work through one part at a time when you want depth.
2. Answer every recall prompt in your head, or on paper, before you reveal it. The effort of retrieving is what makes the idea stick.
3. Take each quiz and read the explanation even when you are right.
4. Mark a concept as understood only when you could explain it to a classmate without looking. Unmarked concepts show you where to return.
5. Keep the glossary open for terms, and use the reference sheet for formulas, numbers and comparisons when you review or solve problems.
6. Come back after a few days and retry the recall prompts and quizzes cold. Spaced practice builds the long-term memory an exam needs.

BThe 10 parts

1. 01Course map and syllabusWhat the course covers, how it is graded, and how to plan the research project from week one.3 conceptsSlides 1-718 min
   1. 1.1The lecture is a chain that ends in a placement decision
   2. 1.2Course scope: foundations first, then building and operating clouds
   3. 1.3The grade is a research pipeline you plan from week one
2. 02Designing systems with mental modelsAd-hoc versus structured design, and the four questions that turn a lamp in a browser into a system: system, components, relationships, layers.6 conceptsSlides 8-2136 min
   1. 2.1Design starts with a mental model, not a part
   2. 2.2A system is components that interact: client, server, device
   3. 2.3A relationship is a protocol plus an interface
   4. 2.4Interactions as request and reply, and the energy they report
   5. 2.5Mapping interactions to HTTP: safe GET, idempotent PUT
   6. 2.6Server component versus server layer: cloud, fog or edge
3. 03The Internet and the TCP/IP stackWhy connectivity is split into five layers, what each layer sends and addresses, and where each layer lives inside a computer.5 conceptsSlides 22-2930 min
   1. 3.1Connectivity is built from five cooperating layers
   2. 3.2Encapsulation: every payload is the PDU of the layer above
   3. 3.3Three scopes, three addresses, and what changes at each hop
   4. 3.4Sockets, connections and the 5-tuple
   5. 3.5Where the stack lives inside one computer
4. 04The Web and network applicationsThe Web as one network application, decentralized versus distributed designs, the two-dimensional design space, and the request-response loop.5 conceptsSlides 30-3930 min
   1. 4.1The Internet is infrastructure, the Web is one application on it
   2. 4.2Decentralized versus distributed: two different questions
   3. 4.3Placing server components: layers, resources and criteria
   4. 4.4Front-end, back-end and sockets: logical talk, physical bytes
   5. 4.5The request-response loop and what every response costs
5. 05Sockets and web app architectureThe socket API between your program and the transport layer, TCP versus UDP sockets, and the frontend and backend of a web application.4 conceptsSlides 40-4524 min
   1. 5.1Sockets: the door between an application and the network
   2. 5.2Stream or datagram: choosing TCP or UDP by what loss costs
   3. 5.3Web apps: the browser as client, the backend as server plus database
   4. 5.4Backend routes: how one HTTP request becomes a response
6. 06Why layering: the continuum ideaWhat a continuum is, and how networks and the memory hierarchy already use layers to trade distance and speed.4 conceptsSlides 46-5024 min
   1. 6.1A continuum of places between client and server
   2. 6.2Networks already layer the path: switching and routing tiers
   3. 6.3The memory hierarchy: nearness for urgent data, justified by locality
   4. 6.4Bandwidth, latency, and why cache is to RAM as edge is to cloud
7. 07The physics of latencyLatency to the cloud, the speed-of-light lower bound, geodesic distance, real measurements from Dammam, and the four delays that add up.4 conceptsSlides 51-5524 min
   1. 7.1Latency and the floor physics sets under it
   2. 7.2Measuring distance on a curved Earth
   3. 7.3Why real round trips cost three times the bound
   4. 7.4Where the time goes: the four packet delays
8. 08Edge, fog and cloudThe layers of the E2C continuum from mist to regional cloud, their latency, resources and typical roles.4 conceptsSlides 56-6024 min
   1. 8.1The server is a place on a line, not one box
   2. 8.2Three layers, seven stages: naming the continuum
   3. 8.3The core trade: resources grow outward, and so does latency
   4. 8.4Placing work: the closest layer that can carry it
9. 09Mapping tasks and response timeFour ways to place an object-detection pipeline on the continuum, how response time is computed, and why faster servers are not enough.6 conceptsSlides 61-7136 min
   1. 9.1A mapping places each task, and the user waits for the whole trip
   2. 9.2All in the cloud: why a faster server barely helps a distant client
   3. 9.3All on the device: no network, but the device pays
   4. 9.4All at the edge: proximity bought with reach and scale
   5. 9.5Splitting the pipeline: a shared fog behind many edges
   6. 9.6In practice: edge plus cloud, chosen task by task
10. 10Latency budget, exercises and summaryDesigning against a response-time threshold, three design exercises (smart glasses, AR, VR), and the lecture in one page.4 conceptsSlides 72-7724 min
    1. 10.1The latency budget: response time must fit inside τ
    2. 10.2A four-step design method, worked on smart glasses
    3. 10.3One app, many deadlines: AR and VR under motion-to-photon
    4. 10.4The split follows τ: the server becomes the continuum

CGlossary and reference

• GlossaryEvery term from the lecture, defined once, with links back to the slides that use it.
• Reference sheetThe lecture on one printable page, for revision before a quiz or exam.