IOT438: Internet Computing

Ultimate Exam Revision Sheet — Lectures 1–10

All Key Concepts · MCQ Targets · Essay Targets · Tricky Distinctions
Dr. Mohammed Attya · Faculty of Computers & Information

Core Concepts: Centralized vs. Distributed:

• Evolution: Centralized → Client-Server → Dis- • Centralized: single failure point, tight control, lim-
tributed → Internet Computing ited scale
• Internet ̸= only communication — it is a global • Distributed: fault tolerant, scalable, no central au-
platform for computation, storage, and service inter- thority
action Loose Coupling (Service-Oriented):
• Three Core Paradigms: • Internal business logic is hidden behind well-defined
– Distributed Computing (multiple autonomous APIs
nodes) • Changes inside a service do not break consumers
– Resource Sharing (hardware, software, data, net-
work)
– Service-Oriented Computing (loose coupling,
standard APIs)
• Transparency Types: Access, Location, Failure
transparency
• Web as Middleware: hides OS/hardware hetero-
geneity → enables interoperability
• HTTP is STATELESS: every request is indepen-
dent; server has zero memory of previous requests —
this is the secret of scalability
• Synchronous = blocking (waits for reply) vs Asyn-
chronous = non-blocking (continues processing)
• Course focus: backend architecture, NOT web design
or frontend

MCQ TARGETS — High Probability Questions

• HTTP statelessness: each request is completely independent, server retains NO session state
• Web as middleware: hides heterogeneity (different OS, hardware, language)
• The THREE core paradigms: Distributed Computing, Resource Sharing, Service-Oriented Computing
• Synchronous = blocking / Asynchronous = non-blocking
• Centralized system weakness: single point of failure

ESSAY / COMPARE TARGETS

• Compare Centralized vs. Distributed Computing (fault tolerance, scalability, control)

• Explain the role of the Web as an infrastructure/middleware layer
• Describe the three types of transparency in distributed systems
• Why is HTTP statelessness critical for scalability?
IOT438 — Internet Computing Ultimate Exam Revision Sheet — Lectures 1–10

Core Concepts: HTTP Methods Semantics:

• TCP limitations: provides only a reliable byte • GET — retrieve data, safe, idempotent
stream — no message boundaries, no semantics, no • POST — create new resource, not idempotent
request/response distinction • PUT — full replace, idempotent
• Why custom protocols fail: tight coupling, hard • DELETE — remove resource
to debug, no tooling, security vulnerabilities
• PATCH — partial update
• Web Protocol Stack: DNS (naming) → URI
HTTP Request Anatomy:
(identity) → HTTP (semantics) → TCP (transport)
• Request Line (Method + URI + Version)
• Client always initiates: bypasses firewalls, han-
dles NAT; server never initiates first contact • Headers (Content-Type, Authorization, etc.)
• Statelessness = Scalability: any server can han- • Empty Line (separator)
dle any request → easy horizontal scaling and load • Optional Body
balancing Status Code Groups:
• Resource-Oriented: servers expose resources • 2xx = Success
(URIs), not functions • 4xx = Client Error (bad request, unauthorized)
• Errors are part of design: failures are inevitable; • 5xx = Server Error (server crashed, unavailable)
HTTP status codes make failures explicit so clients
can recover

MCQ TARGETS — High Probability Questions

• TCP moves bytes; HTTP moves structured messages with meaning
• Loose coupling = systems interact via contracts/messages, not shared state
• PUT = full replace (send all fields); POST = create new resource
• 4xx = client error; 5xx = server error
• Client ALWAYS initiates communication (firewall traversal, NAT)

TRICKY DISTINCTIONS — Do NOT Confuse

• TCP ̸= HTTP: TCP = byte stream (no meaning). HTTP = messages with semantics built on top of
TCP
• PUT vs PATCH: PUT replaces the ENTIRE resource (must send all fields); PATCH updates only
specified fields
• Stateful vs Stateless: Stateful = sessions stored server-side (hard to scale); Stateless = all context in
every request (easy to scale)

Page 2
IOT438 — Internet Computing Ultimate Exam Revision Sheet — Lectures 1–10

4 Physical Constraints of Internet Systems: Key Paradigm Shifts:

• Constraint 1 — No Shared Memory: data must • RPC danger: hides network costs; breaks when
be serialized and exchanged via message passing; no network delays/drops packets
pointers across machines • Cost model shift: CPU/memory in traditional →
• Constraint 2 — No Global Clock: hardware network round-trips in Internet systems
clocks drift; network latency is variable; timestamps • Idempotency is MANDATORY: retried re-
cannot define global event order quests must not corrupt state
• Constraint 3 — Unreliable Network: messages • Coordination avoidance: distributed locks scale
can be lost, delayed, duplicated, or reordered; slow poorly → use Eventual Consistency
response is indistinguishable from failure • Correctness under uncertainty is the central
• Constraint 4 — Partial Failure: some nodes fail challenge; scalability is a consequence of correct de-
while others run; no global failure notification; nodes sign
observe conflicting states Paradigm Comparison:
Dimension Traditional Internet
Memory Shared Partitioned
Time Global clock Local only
Failure Fail-stop Partial
Communication Blocking Asynchronous
Scaling Vertical Horizontal

MCQ TARGETS — High Probability Questions

• RPC abstraction fails at scale because it hides network uncertainty behind a local-looking function call
• Idempotency: executing the same operation multiple times produces the same result — mandatory
because requests ARE retried
• No Global Clock implication: timestamps cannot define global event ordering
• Cost model: dominant cost shifts from CPU to network round-trips
• A slow response is indistinguishable from a hard failure — systems must use timeouts, not blocking
waits

ESSAY / COMPARE TARGETS

• Explain the 4 physical constraints of Internet-scale distributed systems with examples

• Compare Traditional Computing vs. Internet Computing across all 5 dimensions
• Why do synchronous (blocking) models fail at Internet scale?

Page 3
IOT438 — Internet Computing Ultimate Exam Revision Sheet — Lectures 1–10

Distributed Execution — What Changes: Sockets:

• Distributed ̸= deploying same program on multi- • Socket = endpoint identified by IP address + Port
ple machines; it splits logic, state, and control • Ports allow multiplexing multiple services on one
across independent nodes host
• Local: shared stack, implicit communication, guar- UDP vs TCP:
anteed ordering Aspect UDP TCP
• Distributed: explicit message passing, no ordering
Abstraction Messages Byte stream
guarantee, every interaction is a failure point
Reliability None Yes
• Operations that appear atomic locally become multi- Ordering None Yes
step, failure-prone interactions Framing Built-in App must add
IPC Design Dimensions: Latency Low Higher
• Reliability (guaranteed delivery?)
Data Marshalling:
• Ordering (FIFO?)
• Serialize objects to bytes for heterogeneous systems
• Blocking (sender waits?)
(different endianness, memory layouts)
• Timeouts (how long before assuming failure?)
• Binary formats: fast, small; Text formats: readable,
• Choosing IPC = choosing a failure model extensible
Overlay Networks:
• Logical network on top of IP for custom rout-
ing/semantics (e.g., Skype super-nodes for NAT
traversal)

MCQ TARGETS — High Probability Questions

• Socket = IP + Port (allows multiplexing services on one machine)

• UDP = message-oriented, no reliability; TCP = byte stream, reliable but app must add message bound-
aries
• Marshalling: required because heterogeneous systems have different endianness and memory layout
• Overlay networks implement custom semantics above IP (don’t change underlying network)
• MPI: standardized explicit send/receive for HPC (High Performance Computing)

TRICKY DISTINCTIONS — Do NOT Confuse

• TCP gives byte streams, NOT messages: application must implement its own message fram-
ing/boundaries
• UDP gives messages but NO reliability: application must handle loss, duplication, and ordering

Page 4
IOT438 — Internet Computing Ultimate Exam Revision Sheet — Lectures 1–10

Types of Shared Resources: NFS vs SMB:

• Compute: AWS EC2, Google Colab, SETI@home Aspect NFS SMB
• Storage: Block (EBS, raw disk), File (NFS, SMB), Origin Sun (1984) IBM/Microsoft
Object (S3, flat metadata via REST) Primary OS Linux/Unix Windows
• Data: shared DBs, open datasets, real-time feeds State (v3) Stateless Stateful
Auth Kerberos/AUTH_SYS Active Directory
• Software: SaaS, shared APIs, container images
Encryption Optional Built-in (SMB3)
(Docker Hub)
• Network: CDN (Cloudflare), BGP peering, SDN HDFS & GFS:
Architectures: • HDFS default block: 128 MB, replicated 3×
• Client-Server: centralized, easy security, single • GFS chunk: 64 MB, replicated 3×
point of failure
• Both: write-once, read-many; designed for commod-
• P2P: no central server, scales with peers, high fault ity hardware
tolerance; uses DHT for O(log N) resource lookup
BitTorrent:
• Hybrid: central server for metadata/discovery +
• Seeder = has complete file, uploads
P2P for data transfer (BitTorrent, early Spotify)
• Leecher = downloading but also uploading pieces
CAP Theorem: A distributed system can only guar-
it has
antee 2 of 3: Consistency, Availability, Partition Tol-
erance • Tracker/DHT coordinates piece locations
Real Incidents:
• Amazon S3 outage 2017: engineer typo removed too
many servers
• Dropbox breach 2012: password reuse + weak SHA-
1 hashing; lesson: use bcrypt + MFA

MCQ TARGETS — High Probability Questions

• DHT routing efficiency: O(log N) hops

• NFSv3 is stateless → crash recovery is easy (clients just retry); NFSv4 is stateful
• HDFS default block size: 128 MB; replication factor: 3×
• CAP Theorem elements: Consistency, Availability, Partition Tolerance
• Object Storage (S3) uses flat metadata structure accessed via REST (no folder hierarchy)

ESSAY / COMPARE TARGETS

• Compare Client-Server vs. P2P vs. Hybrid architectures (scale, fault tolerance, security)
• Compare Block vs. File vs. Object storage with real examples
• Compare NFS vs. SMB
• Explain the Dropbox security incident and best-practice mitigations (bcrypt, MFA)

Page 5
IOT438 — Internet Computing Ultimate Exam Revision Sheet — Lectures 1–10

Definition & Analogy: Globus Toolkit Components:

• Grid = coordinated use of geographically dis- • GRAM5: job execution; translates to local
tributed, heterogeneous resources across multiple PBS/SLURM
administrative domains • GridFTP: parallel TCP streams for near line-rate
• Like an electrical power grid: submit a job without WAN transfers; supports partial file transfer
knowing which specific machine runs it • GSI: X.509 certificates + Proxy Certificates
• Virtual Organization (VO): dynamic cross- (short-lived, no password re-entry); single sign-on
institutional group sharing resources; preserves each • MDS: LDAP-based resource discovery; GRIS (per
site’s administrative autonomy site) → GIIS (aggregated index)
OGSA 5 Layers (bottom to top): Scheduling:
• 1. Fabric: physical hardware, clusters, storage, in- • PBS: traditional HPC clusters (NASA origin); qsub
struments for job submission
• 2. Connectivity: GridFTP, GSI security (X.509), • HTCondor: harvests idle cycles from desk-
SSL/TLS tops/volunteers; ClassAds matchmaking; DAGMan
• 3. Resource: GRAM (single job submission), Grid for workflows
SRM (storage) Real-World Systems:
• 4. Collective: resource discovery (MDS/LDAP), • CERN WLCG: Tier-0 (CERN) → Tier-1 (13 cen-
brokering, co-allocation, workflow tres) → Tier-2 (∼160) → Tier-3; 15 PB/year; Higgs
• 5. Application: user-facing science portals (CERN discovery 2012
physicist, bioinformatics, SETI) • SETI@home: 5M+ volunteers via BOINC; each
work unit sent to 3+ machines for validation

MCQ TARGETS — High Probability Questions

• Proxy Certificates: short-lived delegated credentials — allow jobs to authenticate without re-entering
passwords
• GridFTP achieves high speed via parallel TCP streams and partial file transfer
• MDS uses LDAP directory for resource discovery
• WLCG Tier-0 is located at CERN, Geneva
• HTCondor specializes in harvesting idle desktop cycles from volunteer machines

ESSAY / COMPARE TARGETS

• Detail all 5 OGSA layers with responsibilities and example tools

• Compare Grid vs. Cloud Computing (ownership, standards, pricing, control)
• Trace the GSI authentication flow step by step
• Explain the Grid Matchmaking process (GRIS → GIIS → Broker → Job)

Page 6
IOT438 — Internet Computing Ultimate Exam Revision Sheet — Lectures 1–10

NIST Cloud Definition (5 Characteristics): Deployment Models:

• On-Demand Self-Service: provision without hu- • Public: shared globally, elastic, low cost; best for
man interaction from provider startups/web apps
• Broad Network Access: accessible from any de- • Private: single org, high security, high CapEx; best
vice over the network for banks/government
• Resource Pooling: multi-tenancy; location inde- • Hybrid: mix private + public; Cloud Bursting =
pendence overflow to public during peaks (Black Friday)
• Rapid Elasticity: scale up/down automatically • Community: shared by organizations with com-
(Netflix ×10 at peak) mon compliance (hospitals, universities)
• Measured Service: pay-per-use metering (billed CapEx vs. OpEx:
per second) • CapEx (on-premises): large upfront cost, hardware
Service Models (Shared Responsibility): depreciates, 5-yr lifecycle, fixed capacity
• IaaS: provider manages hardware + hypervisor; • OpEx (cloud): pay monthly for actual use, instant
YOU manage OS, runtime, apps (AWS EC2) scale, no waste
• PaaS: provider manages OS + runtime + middle- Big Three Providers:
ware; YOU manage code + data (Heroku) • AWS 32% — widest service range, strongest IaaS
• SaaS: provider manages EVERYTHING; YOU just • Azure 22% — enterprise & Microsoft integration
use the app (Gmail, Office 365) • GCP 12% — AI/ML, Kubernetes (invented by
Google)

MCQ TARGETS — High Probability Questions

• CapEx to OpEx shift: cloud eliminates upfront hardware ownership risk
• Cloud Bursting: private cloud normally, automatically overflow to public during traffic spikes
• IaaS: YOU manage OS and above; PaaS: YOU manage code and data only; SaaS: YOU manage
nothing technical
• AWS market share: 32%
• Rapid Elasticity example: Netflix scales servers ×10 at peak hours, scales back at night

TRICKY DISTINCTIONS — Do NOT Confuse

• IaaS vs PaaS: IaaS = you control the OS; PaaS = provider controls the OS, you only control the app
• Hybrid ̸= Community: Hybrid = one org mixing private+public; Community = multiple orgs with
same compliance needs sharing one cloud

Page 7
IOT438 — Internet Computing Ultimate Exam Revision Sheet — Lectures 1–10

Virtualization: Docker Architecture:

• Solves the 5–15% utilization problem by running • Client → Daemon (REST API) → Registry
10+ isolated VMs on one server • Image: read-only blueprint (layers cached); Con-
• Type 1 (Bare-Metal): hypervisor directly on tainer: running instance with writable layer on top
hardware; best performance & security; used in data • Workflow: Build (Dockerfile → Image) → Ship
centres (VMware ESXi, KVM) (Registry) → Run (anywhere)
• Type 2 (Hosted): hypervisor runs as app on Host • Volumes: persistent storage outside the ephemeral
OS; easier for dev but has overhead (VirtualBox, container lifecycle (critical for DBs)
VMware Workstation) • Bridge network: default; Host network: re-
VMs vs Containers: moves isolation for speed
Aspect VM Container Kubernetes (K8s):
OS Full Guest OS (GBs) • Orchestrates containers across multiple machines
Shared Host Kernel (MBs)
Startup Minutes Seconds (Docker = single machine)
Isolation Strong (hardware) Process-level • Control Plane: API Server, etcd (state), Sched-
Density Tens/server Hundreds/server
uler, Controller Manager
Portability Heavy Lightweight
• Worker Nodes: Kubelet, Kube-proxy, container
runtime
• Pod: smallest deployable unit; Service: stable
IP/endpoint; Deployment: manages replica count
+ rolling updates; Namespace: virtual cluster iso-
lation
• Features: Auto-scaling (HPA), Self-healing, Rolling
updates (zero downtime)

MCQ TARGETS — High Probability Questions

• Type 1 hypervisor: runs directly on hardware (production/data centre); Type 2: runs on top of
Host OS (developer laptop)
• Containers share the Host OS kernel (NOT a full OS) — that’s why they’re lightweight
• K8s Pod = smallest deployable unit; K8s Service = stable network endpoint/IP
• Docker Image = immutable read-only blueprint; Docker Container = running instance with writable
layer
• Containers are ephemeral by default — volumes provide persistence

ESSAY / COMPARE TARGETS

• Compare Virtual Machines vs. Containers in depth (architecture, size, startup, isolation, use case)
• Compare Type 1 vs. Type 2 Hypervisors
• Explain the Docker Build → Ship → Run workflow
• Detail the Kubernetes Control Plane components and their roles

Page 8
IOT438 — Internet Computing Ultimate Exam Revision Sheet — Lectures 1–10

Serverless / FaaS: Cloud Challenges:

• Developers write pure function code; provider han- • Vendor Lock-in: Low (IaaS VMs) → High (Dy-
dles ALL server provisioning namoDB, Lambda); mitigate with Docker/K8s +
• Scale to zero: billing is strictly per millisecond multi-cloud + Terraform
of execution • Cost Traps: unmonitored auto-scaling, idle re-
• Cold Start Latency: 200 ms – 2 s added when sources, Data Egress fees (AWS: $0.09/GB out)
function hasn’t been called recently (provider allo- • Spot Instances: up to 90% discount but can be
cates new container) terminated with 2 min notice
• FaaS (AWS Lambda) = custom event-driven back- • Reserved Instances: 1–3 year commitment for
end logic steady workloads (up to 72% discount)
• BaaS (Firebase, Auth0) = replaces backend with Real Incidents:
managed third-party services • Capital One 2019: SSRF + over-privileged IAM;
• Avoid serverless for: long-running jobs >15 min, lesson: least privilege + GuardDuty
stateful apps, steady predictable traffic • Uber 2022: MFA fatigue attack + admin creds in
Cloud Security: scripts; lesson: phishing-resistant MFA
• Zero Trust: “Never trust, always verify” — every • SolarWinds 2020: supply chain attack via build
request authenticated regardless of network location pipeline; lesson: Zero Trust + code signing
• Least Privilege: grant only minimum permissions 12-Factor App (key factors):
necessary; Capital One breach = SSRF + over- • Config in environment variables (not in code)
privileged IAM role (106M records) • Stateless processes (share nothing)
• Encryption at Rest: AES-256 (S3, EBS, RDS) • Dev/Prod parity (same environment everywhere)
• Encryption in Transit: TLS 1.3 / HTTPS • Logs as event streams (stdout only)
• Encryption in Use: Confidential Computing
(AWS Nitro Enclaves)
• Never hardcode credentials; use IAM Roles; enable
MFA (stops 99.9% of hijacking)

MCQ TARGETS — High Probability Questions

• Cold start latency: 200 ms – 2 s penalty on first serverless function invocation
• Spot instances: up to 90% discount but 2-minute warning before termination
• Data Egress fees: charged when data moves OUT of the cloud provider’s network
• 12-Factor: store configuration in environment variables (never in code)
• FaaS vs BaaS: FaaS = you write custom logic; BaaS = third-party service replaces your backend logic

ESSAY / COMPARE TARGETS

• Compare FaaS vs. BaaS vs. SaaS with examples

• Discuss levels of Vendor Lock-in and mitigation strategies
• Explain Zero Trust and Principle of Least Privilege
• Describe 3 real cloud security incidents with root causes and lessons

Page 9
IOT438 — Internet Computing Ultimate Exam Revision Sheet — Lectures 1–10

SOA Triangle: REST (Representational State Transfer):

• Provider: creates and publishes the service + • Architectural style, NOT a protocol; Roy Fielding
WSDL (2000)
• Registry (UDDI): directory for discovery • Uses standard HTTP methods + URIs; typically
(White/Yellow/Green pages); now largely replaced JSON
by OpenAPI portals • 6 Constraints: Client-Server, Stateless, Cacheable,
• Consumer: finds via registry, binds, and uses the Uniform Interface, Layered System, Code on De-
service mand (optional)
SOAP (Simple Object Access Protocol): • HTTP Methods in REST:
• XML-only, strict, enterprise standard; transport- – GET = read, safe, idempotent
independent (HTTP, SMTP, FTP) – POST = create, not idempotent
• Built-in WS-Security and ACID transactions – PUT = full replace, idempotent (send ALL
• Message Anatomy: fields)
– Envelope — MANDATORY, root wrapper – PATCH = partial update
– Header — optional, auth/metadata – DELETE = remove
– Body — MANDATORY, payload GraphQL vs gRPC:
– Fault — optional, error info • GraphQL (Facebook 2015): single endpoint; client
• WSDL: XML contract defining operations, types, specifies exact data shape; solves over-fetching /
bindings; auto-generates client code under-fetching
• Best for: Banking, B2B, healthcare (HL7), airline • gRPC (Google 2016): binary Protocol Buffers;
reservations extremely fast; standard for microservice-to-
microservice communication
SOAP vs REST Quick Compare:
Aspect SOAP REST
Type Protocol Architectural style
Format XML only JSON / XML / any
Security WS-Security built-in HTTPS + OAuth
Speed Slower (verbose) Faster (lightweight)
Transactions ACID support No built-in
Best for Enterprise/B2B Web/Mobile APIs

MCQ TARGETS — High Probability Questions

• SOAP message: Envelope and Body are MANDATORY; Header and Fault are optional
• PUT = idempotent, full replace (send all fields); PATCH = partial update (send only changed fields)
• WSDL = the XML contract defining what operations a SOAP service offers
• GraphQL prevents over-fetching by letting client specify exactly what data it needs
• REST is an architectural style, NOT a protocol (unlike SOAP which is a protocol)

TRICKY DISTINCTIONS — Do NOT Confuse

• SOAP vs REST: SOAP is a strict protocol with mandatory XML; REST is a flexible architectural style
using any format
• PUT vs PATCH: PUT requires sending ALL fields (full replace); PATCH sends only the fields you
want to change
• GraphQL vs gRPC: GraphQL solves over-fetching for clients; gRPC is for fast internal microservice
communication (binary)

ESSAY / COMPARE TARGETS

• Compare SOAP vs. REST in depth (protocol type, format, security, transactions, use case)
• Detail the SOA Triangle and the role of each component
• List and explain 4 of the 6 REST architectural constraints
• Compare HTTP methods: GET, POST, PUT, PATCH, DELETE (safety and idempotency)

Page 10
IOT438 — Internet Computing Ultimate Exam Revision Sheet — Lectures 1–10

MASTER COMPARISON TABLE — Grid vs Cloud vs Distributed

Aspect Traditional Distributed Grid Computing Cloud Computing

Ownership Single org Multi-institution (VO) Single provider (AWS/GCP)
Control Centralized Multi-domain policies Provider-managed
Resources Homogeneous cluster Heterogeneous, federated Virtualized, elastic
Scale Hundreds of nodes Thousands of nodes Millions of VMs
Job Model Tightly coupled (MPI) Batch jobs (GRAM/PBS) On-demand VMs/services
Standards Custom/proprietary Open (OGSA, GridFTP) Proprietary APIs
Pricing Fixed hardware Free via VO Pay-as-you-go
Best For HPC, parallel computing Scientific research Web apps, SaaS

CRITICAL NUMBERS & FACTS TO MEMORIZE

• HDFS block size: 128 MB • Serverless cold start: 200 ms – 2 • NFSv4 port: 2049
• GFS chunk size: 64 MB s • SMB port: 445
• Both replicate: 3× • Spot instance warning: 2 min • CERN Tier-0: Geneva, Switzer-
• DHT lookup: O(log N) hops • Spot discount: up to 90% land
• AWS market share: 32% • Reserved discount: up to 72% • WLCG countries: 42 countries
• Azure market share: 22% • MFA stops: 99.9% of hijacking • Amazon S3 outage: Feb 2017
• GCP market share: 12% • Capital One breach: 106M records • SETI@home volunteers: 5M+

IOT438 Internet Computing · Dr. Mohammed Attya · Faculty of Computers & Information · All lectures 1–10 covered

Page 11