Lecture 3

Peer to Peer Architectures,

Threads, VMs, Clients

By: Dr. Aymen J. Salman

2021-2022
 What is Overlay Network

An overlay network is a telecommunications network

that is built on top of another network and is
supported by its infrastructure.

• The first overlay network example is Internet,

which is an overlay network running over the
infrastructure of the public switched telephone
network (PSTN)
• Most current application networks run on top of the
public Internet such as:
• virtual private networks (VPNs)
• Client/Server and peer-to-peer (P2P)
networks
• Content Delivery Networks (CDNs)
• Voice over IP (VoIP) services such as Skype
 Most Used P2P Applications

• Bitcoin & Blockchain

• Skype
• File Sharing Application: BitTorrent, uTorrent, Pando and Tribler
• online gaming platforms:
• Blizzard Entertainment distributes Diablo III, StarCraft II, and World of Warcraft
• Wargaming also distributes World of Tanks, World of Warships, and World of
Warplanes games.
• Operating System images and updates download:
• Ubuntu, Linux Mint, and Manjaro
• Windows 10 updates
 Decentralized Architectures
Observation
In the last couple of years we have been seeing a
tremendous growth in peer-to-peer systems
• Structured P2P: nodes are organized following a specific
distributed data structure
• Unstructured P2P: nodes have randomly selected
neighbors
• Hybrid P2P: some nodes are appointed special functions
in a well-organized fashion

Note
In virtually all cases, we are dealing with overlay networks:
data is routed over connections setup between the nodes
(via application level multicasting)
5
 Structured P2P Systems
Basic idea
Organize the nodes in a structured overlay network such as
a logical ring and make specific nodes responsible for
services based only on their ID

This is Chord Protocol, which one of the

main 4 famous distributed Hash table
protocols (CAN, Tapestry and Pastry)

Note
The system provides an operation
LOOKUP(key) that will efficiently
route the lookup request to the
associated node.
6
 Structured P2P Systems
Other example
Organize nodes in a hypercube

7
 Unstructured P2P Systems
Observation
Many unstructured P2P systems attempt to maintain a random overlay;
two nodes are linked with probability 𝑝.

Basic principles
Each node is required to contact a randomly selected other node:
• Let each peer maintain a partial view of the network, consisting of c
other nodes
• Each node P periodically selects a node Q from its partial view
• P and Q exchange information and exchange members from their
respective partial views

Note
It turns out that, depending on the exchange, randomness, but also
robustness can be maintained.

8
 Unstructured P2P Systems
Observation Searching or Querying Information Strategies
We can no longer look up information deterministically; we
must resort to searching:
• Flooding: node 𝑢 sends a lookup query to all of its
neighbors. A neighbor responds, or forwards (floods) the
request. There are many variations:
– Limited flooding (maximal number of forwarding)
– Probabilistic flooding (flood only with a certain probability).

• Random walk: Randomly select a neighbor 𝑣. If 𝑣 has the

answer, it replies, otherwise 𝑣 randomly selects one of its
neighbors.
– Variation: parallel random walk. Works well with replicated data.

9
 Hybrid P2P Systems
Superpeers (Edge Server Architecture)
Observation)
Sometimes it helps to select a few nodes to do specific work:
superpeer
Examples
• Peers maintaining an
index (for search)

• Peers monitoring the

state of the network

• Peers able to setup

connections

12
 Hybrid P2P Systems
Edge-server architecture
Essence
Systems deployed on the Internet where servers are placed at the edge of the
network: the boundary between enterprise networks and the actual Internet.

Client Content provider

ISP
ISP

Core Internet

Edge server

Enterprise network
Skype’s principle operation: A wants to contact B

Both A and B are on the public Internet

A TCP connection is set up between A and B for control packets.
The actual call takes place using UDP packets between negotiated ports.

A operates behind a firewall, while B is on the public Internet

A sets up a TCP connection (for control packets) to a super peer S
S sets up a TCP connection (for relaying control packets) to B
The actual call takes place through UDP and directly between A and B

Both A and B operate behind a firewall

A connects to an online super peer S through TCP
S sets up TCP connection to B.
For the actual call, another super peer is contacted to act as a relay R: A
sets up a connection to R, and so will B.
All voice traffic is forwarded over the two TCP connections, and through R.
 Hybrid P2P Systems
Collaboration: The BitTorrent case
Principle: search for a file F
Lookup file at a global directory ⇒ returns a torrent file
Torrent file contains reference to tracker: a server keeping an accurate
account of active nodes that have (chunks of) F .
P can join swarm, get a chunk for free, and then trade a copy of that
chunk for another one with a peer Q also in the swarm.
Client node
K out of N nodes

Lookup(F) Node 1

A BitTorrent List of nodes Node 2

torrent file
Web page or with (chunks of)
for file F
search engine file F
Web server File server Tracker
Node N
 So Far
• Peer to Peer System Architectures
• Thread Review
• Virtual Machine Review
• Clients

19
 Review: Threads
Basic idea: we build virtual processors in software, on top of physical
processors:

Processor: Provides a set of instructions along with the capability of

automatically executing a series of those instructions.

Thread: A minimal software processor in whose context a series of

instructions can be executed. Saving a thread context implies
stopping the current execution and saving all the data needed to
continue the execution at a later stage.

Process: A software processor in whose context one or more threads

may be executed. Executing a thread, means executing a series of
instructions in the context of that thread.

20
Context Switching
Thread Usage in Nondistributed Systems

Context switching as the result of Inter-Process Communication (IPC)

24
Process Vs Thread
Parameter Process Thread

Definition Process means a program is in execution. Thread means a segment of a process.

Lightweight The process is not Lightweight. Threads are Lightweight.

Termination time The process takes more time to terminate. The thread takes less time to terminate.

Creation time It takes more time for creation. It takes less time for creation.

Communication between processes needs Communication between threads requires less time
Communication
more time compared to thread. compared to processes.

Context switching time It takes more time for context switching. It takes less time for context switching.

Resource Process consume more resources. Thread consume fewer resources.

All the level peer threads are treated as a single task

Treatment by OS Different process are tread separately by OS.
by OS.

Memory The process is mostly isolated. Threads share memory.

Sharing It does not share data Threads share data with each other.

25
Threads and Operating System
Threads and Operating System

Conclusion

Try to mix user-level

and kernel-level
threads into a single
concept, however,
performance gain
has not turned out
to outweigh the
increased
complexity.
 Using Threads at the Client Side
Multithreaded Web client:
Hiding network latencies:
• Web browser scans an incoming HTML page, and finds that more
files need to be fetched.
• Each file is fetched by a separate thread, each doing a (blocking)
HTTP request.
• As files come in, the browser displays them.

Multiple request-response calls to other machines (RPC):

• A client does several calls at the same time, each one by a different
thread.
• It then waits until all results have been returned.
• Note: if calls are to different servers, we may have a linear speed-up
compared to doing calls one after the other to the same server.

28
 Using Thread at the Server Side
Improve performance:
• Starting a thread is much cheaper than starting a new
process.
• Having a single-threaded server prohibits simply scaling
the server to a multiprocessor system.
• As with clients: hide network latency by reacting to the
next request while the previous one is being replied.

Better structure:
• Most servers have high I/O demands. Using simple, well-
understood blocking calls simplifies the overall structure.
• Multithreaded programs tend to be smaller and easier to
understand due to simplified flow of control.

30
Multithreaded Servers

A multithreaded server organized in a dispatcher/worker model.

31
 So Far
• Peer to Peer System Architectures
• Thread Review
• Virtual Machine Review
• Clients

32
 Virtualization
Observation:
Virtualization is becoming increasingly important:
• Hardware changes faster than software
• Ease of portability and code migration
• Isolation of failing or attacked components

33
 VM Monitors on operating systems
Practice: We’re seeing VMMs run on top of existing
operating systems (e.g. VirtualBox, VMWare)

• Perform binary translation: while executing an application

or operating system, translate instructions to that of the
underlying machine.

• Distinguish sensitive instructions: traps to the original

kernel (think of system calls, or privileged instructions).

• Sensitive instructions are replaced with calls to the VMM.

36
 Clients: User Interfaces
Essence: A major part of client-side software is focused on
(graphical) user interfaces.

37
 So Far
• Peer to Peer System Architectures
• Thread Review
• Virtual Machine Review
• Clients

39
 Client-Side Software
Generally tailored for distribution transparency
• access transparency: client-side stubs for RPCs
• location/migration transparency: let client-side software
keep track of actual location
• replication transparency: multiple invocations handled
by client stub:

• failure transparency: can often be placed only at client

(we’re trying to mask server and communication failures).

40
 Conclusion
• Peer to Peer System Architectures
• Thread Review
• Virtual Machine Review
• Clients

41