Topics to be covered

Definitions and Examples

Basics Goals
Models (architectural, fundamental)
Hardware and Software Concepts
The Client-Server Model

1 2
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Historical Definition of a Distributed System

Two developments from mid 50s
A distributed system is:
• 100 million dollars -- 1 instr per sec
1000 dollars -- 10 million instr per sec A collection of independent computers
1012 price/performance gain that appears to its users as a single
coherent system
Rolls Royce cost 1 dollar -- a billion miles per gallon
(200-page manual to open the door)
Two aspects:
(1) Independent computers
• Local and Wide Area networks (LANs)
(2) Single system ⇒ middleware

3 4
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Definition of a Distributed System A Distributed System as Middleware

Characteristics
(1) Heterogeneity hidden
(2) Interact with a consistent and uniform way
(3) Availability
(4) Scale
1.1
Issues
(1) Concurrency
(2) No global clock Note that the middleware layer extends over multiple machines.
(3) Independent failures

5 6
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

1
 A typical portion of the Internet
Examples of Distributed Systems

The Internet
Intranets intranet 

Mobile and Ubiquitous Computing  ISP

The Web 

p2p systems (such as Napster)

File systems (SUN, CODA, Adrews) backbone

Storage Systems (Occean)

Object-based Systems (CORBA, DCOM, etc) satellite link
Groupware
desktop computer:
server:
network link:
ISPs: Internet Service Providers
Backbone links the Intranets together
7 8
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Portable and handheld devices in a distributed system

A Typical Intranet email server Desktop
computers
print and other servers Internet

Local area
Web server network

Host intranet WAP

email server Wireless LAN gateway Home intranet
print
File server
other servers
Mobile
the rest of phone
the Internet Printer Laptop
Camera Host site
router/firewall

• A portion of the Internet separately administrated • Devices: laptop computers, handheld devices (e.g., PDAs, video cameras),
wearable devices, devices embedded in appliances
• Several LANs linked by backbone connections
• Mobile computing, ubiquitous computing, location-aware computing
• Connected to the Internet via a router
• In the figure above: 3 different forms of wireless connections: wireless
• Firewalls protects an intranet by preventing unauthorized messages LAN, mobile phone through WAP, infra-red link
leaving or entering; implementing by filtering messages
9 10
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Resource sharing on the Web

http://www.google.comlsearch?q=kindberg
Computers in the Internet
www.google.com

Web servers Browsers

www.cdk3.net Internet
http://www.cdk3.net/
www.w3c.org
Date Computers Web servers
File system of http://www.w3c.org/Protocols/Activity.html
Protocols
www.w3c.org
1979, Dec. 188 0
Activity.html 1989, July 130,000 0
1999, July 56,218,000 5,560,866
• WWW a system for publishing and accessing resources and services
across the Internet
• Web browsers act as client
• Request resources (e.g., web pages) from web servers
• CERN , 1989
• Hypertext structure among documents

11 12
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

2
 Computers vs. Web servers in the Internet
Goals

1. Connecting Users and Resources

Date Computers Web servers Percentage
2. Transparency
1993, July 1,776,000 130 0.008
1995, July 6,642,000 23,500 0.4 3. Openness
1997, July 19,540,000 1,203,096 6
1999, July 56,218,000 6,598,697 12 4. Scalability

13 14
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Connecting Users and Resources Transparency in a Distributed System

Typical resources
access transparency
Printers, computers, storage facilities,
data, files Hide differences in data representation and how
Why sharing? a resource is accessed

Economics Intel (little endian format)/Sun SPARC (big endian) (order of

Collaboration, Information Exchange bytes)
(groupware) OS with different file name conversions

Problems with sharing

Security
Unwanted Communication

15 16
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Transparency in a Distributed System

Transparency in a Distributed System
replication transparency
location transparency Hide that a resource is replicated
Hide where a resource is located subsumes that all replicas have the same name
importance of naming, e.g., URLs (and thus location transparency)
migration transparency concurrency transparency

Hide that a resource may move to another location Hide that a resource may be shared by several
competitive users
leave the resource in a consistent state
relocation transparency more refined mechanism: transactions
Hide that a resource may move to another location
while in use
example, mobile users

17 18
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

3
 Transparency in a Distributed System Different Forms of Transparency in a
Distributed System (summary)
failure transparency

Hide the failure and recovery of a resource Transparency Description

L. Lamport: You know you have one [distributed system] when Access
Hide differences in data representation and how a
the crash of a computer you ‘ve never heard of stops you for resource is accessed
getting any work done Location Hide where a resource is located
Migration Hide that a resource may move to another location
Important problem: inability to distinguish between a Hide that a resource may be moved to another
dead resource and a painfully slow one Relocation
location while in use
Hide that a resource may be shared by several
Replication
persistent transparency competitive users
Hide that a resource may be shared by several
Concurrency
competitive users
Hide whether a (software) resource is in memory or
disk Failure Hide the failure and recovery of a resource
Hide whether a (software) resource is in memory or on
Persistence
disk

19 20
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

(Coulouris et. al.) Degree of Transparency

Access transparency: enables local and remote resources to be accessed using
identical operations. (same) Not always desirable
Location transparency: enables resources to be accessed without knowledge of
their location. (same) – also migration and relocation
Examples?
Mobility transparency: allows the movement of resources and clients within a Users located in different continents
system without affecting the operation of users or programs. (contex-aware)
Replication transparency: enables multiple instances of resources to be used to Not always possible
increase reliability and performance without knowledge of the replicas by users or
application programmers. Examples?
Concurrency transparency: enables several processes to operate concurrently
Hiding failures (you can distinguish a slow computer from
using shared resources without interference between them.
a failing one/whether an action was performed)
Failure transparency: enables the concealment of faults, allowing users and
application programs to complete their tasks despite the failure of hardware or Trade-off between a high degree of transparency
software components. – also persistent transparency
and the performance of a system
Performance transparency: allows the system to be reconfigured to improve Keep web caches exactly up-to-date
performance as loads vary.
Scaling transparency: allows the system and applications to expand in scale Immediately flushing write operations to disk
without change to the system structure or the application algorithms.
Retry to access a web page to mask a failure
21 22
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Openness
Goals Open distributed system

Be able to interact with services from other open systems,

1. Connecting Users and Resources irrespectively of the underlying environment

2. Transparency Offers services according to standard rules that describe the

syntax and the semantics of these services

3. Openness
• Rules formalized in protocols
4. Scalability • Services specified through interfaces (described in an Interface
Definition Language (IDL) (but only the syntax part)
• Neutral and complete specifications (with regards to a potential
implementation)

23 24
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

4
 Openness
Openness • A system organized as a collection of relatively small and easily
replaceable or adaptable components
•Provide definitions of the internal parts of the system as well
• Interoperability: to what extend can work together
• Portability: to what extend an application developed for A
can be executed on B that implements the same interface
• Separate Policy from Mechanism
with A
A distributed system provides only mechanisms
Policies specified by applications and users
Example policies:
• What level of consistency do we require for client-cached data?
• Which operations do we allow downloaded code to perform?
• Which QoS requirements do we adjust in the face of varying
bandwidth?
• What level of secrecy do we require for communication?

25 26
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Scalability Problems
Scalability
Concept Example

Along three different dimensions: Centralized services A single server for all users

• size (number of users and/or processes) Centralized data A single on-line telephone book

• geographical (maximum distance between nodes) Centralized algorithms Doing routing based on complete information

• administrative (number of administrative

domains) Decentralized algorithms
• No complete information about the system state
• Make decision only on local information
The (non) solution: powerful servers • Failure of one machine does not ruin the algorithm
• No assumption of a global clock

27 28
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Scalability
Scaling Techniques
Geographical scalability:
Three techniques:
Synchronous communication
In WAN, Unreliable and point-to-point
• hiding communication latencies
How to scale a distributed system across multiple, independent
• distribution
administrative domains: conflicting policies with respect to
resource usage (and payment), management and security
• replication
Expand to a new domain
• Protect itself against malicious attacks from the new
domain
• The new domain has to protect itself against malicious
attacks from the distributed system

29 30
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

5
 Scaling Techniques
Scaling Techniques

Hiding communication latencies

try to avoid waiting for responses to remote service

requests as much as possible

• asynchronous communication (do something else)

• moving part of the computation to the client

process

The difference between letting:

a) a server or
b) a client check forms as they are being filled

31 32
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Scaling Techniques Scaling Techniques

nl.vu.cs.flits
Distribution
Taking a component, splitting into
smaller parts, and spreading these
parts across the system

Example:
(1) The World Wide Web

(2) Domain Name Service (DNS)

hierarchically organized into a tree of domains
Each domain divided into non overlapping zones
The names in each domain handled by a single name server An example of dividing the DNS name space into zones.

33 34
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Scaling Techniques

Replication
Caching (client-driven)

Models
• increase availability

• balance the load

• reduce communication latency

• but, consistency problems

35 36
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

6
 System Models System Models
1. Architectural models
Fundamental models are concerned with a more formal description
2. Fundamental models of the properties that are common in all of the architectural models

Models:
An architectural model of a distributed system is
concerned with the placement of its parts and the • Interaction model deals with performance and with the difficulty
relationships between them of setting time limits in distributed systems, for example for
message delivery
Examples include the client-server model and the p2p model
• Failure model gives a precise specification of the faults that can
• determine the distribution of data and computational tasks be exhibited by processes and communication channels. Defines
amongst the physical nodes of the system reliable communication and correct processes.
• useful when evaluating the performance, reliability, scalability
and other properties of distributed systems • Security model discusses the possible threats to processes and
communication channels.

37 38
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Interaction Model Interaction Model

Communication performance characteristics:
• Distributed systems are composed of multiple interacting
Latency: delay between sending a message by one process and
processes
its receipt by another
Bandwidth of a computer network: total amount of information
• Their behavior and state can be described by a distributed that can be transmitted over it in a given time
algorithm: a definition of the steps to be taken by each
Jitter: the variation in the time taken to deliver a series of
process including the transmission of messages between
messages
them

• Messages are transmitted between processes to transfer Computer clocks:

information among them and to coordinate their activity Clock drift rate: relative amount that a computer clock differs
from a perfect reference clock

39 40
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Variants of the Interaction Model Failure Model

Based on whether they set time limits (lower and upper bounds) Classification of failures:
on:
•Omission failures:
• Process execution speeds when a process or communication channel fails to perform
actions that is supposed to do
• Message transmission delays
Process omission failure: crash
• Clock drift rates
Fail-stop crash is other processes can detect certainly
that the process has crashed
Synchronous distributed systems (can set timeouts, can be built)
Asynchronous distributed systems (e.g., Internet, web)

Despite the lack of accurate clocks, the execution of a system

can be described in terms of events and their ordering
41 42
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

7
 Failure Model Failure Model

Classification of failures:

processp process q • Arbitrary or Byzantine failures

send m receive Arbitrary failures of processes and channels

Communication channel
Outgoing message buffer Incoming message buffe

Communication omission failures: send-omission, channel-

omission, and receive omission

43 44
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Omission and arbitrary failures Timing failures

In synchronous systems:
Class of failure Affects Description
Fail-stop Process Process halts and remains halted. Other processes may
detect this state. Class of Failure Affects Description
Crash Process Process halts and remains halted. Other processes may Clock Process Process’s local clock exceeds the bounds on its
not be able to detect this state. rate of drift from real time.
Omission Channel A message inserted in an outgoing message buffer never Performance Process Process exceeds the bounds on the interval
arrives at the other end’s incoming message buffer. between two steps.
Send-omission Process A process completes a send,but the message is not put Performance Channel A message’s transmission takes longer than the
in its outgoing message buffer. stated bound.
Receive-omission Process A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary Process or Process/channel exhibits arbitrary behaviour: it may
(Byzantine) channel send/transmit arbitrary messages at arbitrary times,
commit omissions; a process may stop or take an
incorrect step.

45 46
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Security Model Security Model

To model security threats, we postulate an enemy (or

Securing the processes and the channel and adversary)
protecting the objects
Send any message to any process and reading/copying any
message between a pair of processes

Protecting the objects: access rights (specify who is

allowed to perform each operation of an object) 1. Threats to processes (cannot identify the identity of the
sender: holds for both clients and servers)
Associate with each invocation and each result the
authority on which it is issued called a principal 2. Threats to communication channels
3. Other possible threats (mobile code, denial of service)

47 48
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

8
 Classification of Multiple CPU Computer Systems

Into two groups:

Multiprocessors (shared memory): there is single physical address

shared by all CPUs

Hardware Concepts Multicomputers: each machine has its own private memory.
Either Homogeneous or Heterogeneous

Further divided based on the architecture of the interconnection

network:

Bus: a single network that connects all machines

Switch

49 50
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Hardware Concepts
Multiprocessors

Overload the bus ⇒ cache memory

High hit rate drops the amount of bus traffic
But incoherency

Scalability
Different method to connect the memory with the CPU ⇒
divide the memory in modules

51 52
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Multiprocessors Homogeneous Multicomputer Systems

CPU-to-CPU communication
aka System Area Networks (SANs)

Bus-based connected through a multi-access network

such as Fast Ethernet, problem?

n2 crossbar switches Omega network

Switch-based: routed instead of broadcast
Problem: many switches between
the CPU and the memory Different topologies

NUMA machine: some memory is associated with each CPU

53 54
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

9
 Homogeneous Multicomputer Systems Heterogeneous Multicomputer Systems

Heterogeneous machines, interconnection networks

Scale
Lack of global view

transparency is harder

Grid Hypercube (n-dimensional cube)

4-dimensional

Massively parallel processors (MPPs)

Clusters of Workstations (COWs)
55 56
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Software Concepts
• Much like an OS (resource managers, hides underlying hardware)
•Tightly-coupled (maintain a global view) – loosely coupled

• DOS (Distributed Operating System)

• NOS (Network Operating System)
• Middleware

Software Concepts System Description Main Goal

Tightly-coupled operating system for multi- Hide and manage

DOS processors and homogeneous hardware
multicomputers resources
Loosely-coupled operating system for Offer local
NOS heterogeneous multicomputers (LAN and services to remote
WAN) clients
Provide
Additional layer atop of NOS implementing
Middleware distribution
general-purpose services
transparency

57 58
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Distributed Operating Systems Multicomputer Operating Systems

• Two types: multiprocessor OS and multicomputer OS
Harder than traditional (multiprocessor) OS: Because
Multi-processor OS
memory is not shared
Shared memory
Emphasis shifts to processor communication by message
Functionality similar to traditional OSs but handle multiple CPUs passing
• Aim at supporting high performance through multiple CPUs,
make their number transparent to the application
• OSs on each computer knows about the other computers
• Similar to multitasking uniprocessor OS:
• OS on different machines generally the same
o All communication done by manipulating data at shared
• Services are generally (transparently) distributed
memory locations.
across computers
o Protection is done through synchronization primitives

59 60
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

10
 Multicomputer Operating Systems Multicomputer Operating Systems
Processor communication by message passing
• Often no simple global communication
General structure
• No simple system-wide synchronization mechanisms
• Virtual (distributed) shared memory requires OS to
maintain global memory map in software (Distributed
Shared Memory (DSM) vs Only message passing
• Inherent distributed resource management: no central
Each node has each own kernel: modules for managing local resources point where allocation decisions can be made
(memory, local CPU, local disk, etc) + handling interprocess communication
(sending and receiving messages to and from other nodes)
Practice: only very few truly multicomputer OS exist
Common layer of software: implements the OS as a virtual machine
supporting parallel and concurrent execution of tasks.
Facilities: assigning a task to a processor, providing transparent storage,
general interprocess communication
61 62
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Multicomputer Operating Systems Multicomputer Operating Systems

Semantics of message passing Semantics of message passing
(continued)
Buffering of messages at the
sender or the receiver
Is the communication reliable?
Four possible synchronization
points:
Reliable comm.
Synchronization point Send buffer
S1 (block the sender when its guaranteed?
buffer is full)
Block sender until buffer not full Yes Not necessary
S2 (message has been send)
Block sender until message sent No Not necessary
S3 (message has arrived at the
Block sender until message received No Necessary
receiver)
S4 (message has been delivered to Block sender until message delivered No Necessary
the receiver)

63 64
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Multicomputer Operating Systems Network Operating System

Do not assume that the underlying hardware is homogeneous and
that it should be managed as if it were a single system
Provide facilities to allow users to make use of services provided
Distributed Shared Memory Systems (DSMs) on a specific machine (rlogin, rcp)

The address space is divided up into pages with the General structure
pages being spread over all the processors in the
system
When a processor references an address that is not
present locally, a trap occurs, and the OS fetches
the pafe

65 66
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

11
 Network Operating System Network Operating System

Some provide a shared global file system

Different clients may mount the servers in different places.

67 68
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Middleware
Network Operating Systems

Some characteristics:
• Each computer has its own OS with networking facilities
• Computers work independently (i.e, they may even have
different OS)
• Services are to individual nodes (ftp, telnet, www)
• Highly file oriented (basically, processors share only
files)
• Compared to distributed OSs
• Middleware itself does not manage an individual mode
• Lack of transparency (harder to use; need to be
managed independently) • OS on each computer need not know about the other computers

• Easier to add/remove a machine (scalability, • OS on different computers need not be the same
openness) • Services are generally (transparently) distributed across
computers
69 70
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Middleware Models Middleware Services

Based on some model or paradigm, such as: Communication services (offer high-level communication
facilities to hide low-level message passing)
• all resources are treated as files (UNIX and Plan 9)
• Procedure calls across networks
• Distributed file systems
• Remote-object method invocation
• Remote Procedure Calls (RPCs): allow a process to call a
procedure whose implementation is located on a remote • Message-queuing systems
machine
• Advanced communication streams
• Distributed objects: transparently invoke objects
• Event notification service
residing on remote machines
• Distributed documents

71 72
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

12
 Middleware Services Middleware Services

Information system services (help manage data) Control services (giving applications control over when,
where and how they access data)
• Large scale system-wide naming services
• Code migration
• Advanced directory services (search engines)
• Distributed transaction processing
• Location services for tracking mobile objects
• Persistent storage facilities
Security services
• Data caching and replication
• Authentication and authorization services
• Simple encryption services
• Auditing service

73 74
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Comparison between Systems

Middleware and Openness
Distributed OS
Middleware-
Item Network OS
based OS
Multiproc. Multicomp.

Degree of transparency Very High High Low High

Same OS on all nodes Yes Yes No No

Number of copies of OS 1 N N N

Shared
Basis for communication Messages Files Model specific
memory
Global, Global,
Resource management Per node Per node
central distributed
Scalability No Moderately Yes Varies
In an open middleware-based distributed system, the protocols
used by each middleware layer should be the same, as well as the Openness Closed Closed Open Open
interfaces they offer to applications.

75 76
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Clients and Servers

Process are divided in
Server: implementing a specific service
Client: requesting a service from a server by sending it a
request and subsequent waiting for the server’s reply
Distributed across different machines
The Client-Server Model Follow a request-reply

77 78
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

13
 Application Layering Application Layering

Traditional three-layered view

User-interface layer: programs that allow end users to
interact with the application; differ in their sophistication
Processing layer: contains the functions of an application
Data layer: contains the data that a client wants to
manipulate through the application components

The general organization of an Internet search engine into

three different layers
79 80
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Multitiered Architectures Multitiered Architectures

Alternative client-server organizations An example of a server acting as a client.

Client invocation Server

invocation

result result
Server

Client
Key:
Process: Computer:

81 82
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Multitiered Architectures Alternative Architectures

An example of a server acting as a client.

Vertical distribution: placing logically different components

on different machines

Horizontal distribution: a client or server may be physically

split up into logically equivalent parts; each operating on its
own share of the complete data

83 84
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

14
 Alternative Architectures
Collaborating servers
Cooperating servers: service is physically distributed across a
Service
collection of services:
• Traditional multi-tiered architectures
• Replicated files systems Server

• Network news services Client

• Large-scale naming systems, etc

Server
Cooperating clients: distributes applications exist by virtue of
client collaboration:
• Teleconferencing Client
Server
• Publish/subscribe

85 86
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Modern Architectures

An example of horizontal distribution of a Web service.

Extra Slides

87 88
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Multiprocessor Operating Systems

Uniprocessor Operating Systems

monitor Counter {
private:
int count = 0;
public:
1.11
int value() { return count;}
void incr () { count = count + 1;}
void decr() { count = count – 1;}
}

Separating applications from operating system code through

a microkernel.
A monitor to protect an integer against concurrent access.
89 90
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

15
 Multiprocessor Operating Systems Distributed Shared Memory Systems

monitor Counter { a) Pages of address

private: void decr() { space distributed
int count = 0; if (count ==0) { among four machines
int blocked_procs = 0; blocked_procs = blocked_procs + 1;
condition unblocked; wait (unblocked); b) Situation after CPU 1
public: blocked_procs = blocked_procs – 1; references page 10
int value () { return count;} }
void incr () { else c) Situation if page 10
if (blocked_procs == 0) count = count – 1; is read only and
count = count + 1; } replication is used
else }
signal (unblocked);
}

A monitor to protect an integer against concurrent access, but

blocking a process.
91 92
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Distributed Shared Memory Systems An Example Client and Server (1)

1.18

False sharing of a page between two independent processes.

The header.h file used by the client and server.
93 94
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

An Example Client and Server (2) An Example Client and Server (3)

1-27 b

A sample server.
95
A client using the server to copy a file. 96
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

16
 Figure 2.4 Figure 2.5
Web proxy server A distributed application based on peer
processes
Application Application

Client Web
server Coordination Coordination
code code
Proxy
server

Client Web
server
Application

Coordination
code

97 98
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Figure 2.6 Figure 2.7

Web applets Thin clients and compute servers
a) client request results in the downloading of applet code
Compute server
Network computer or PC
Client Web
Applet code server
Thin network Application
Client Process
b) client interacts with the applet

Web
Client Applet server

99 100
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Figure 2.8 Figure 2.9

Spontaneous networking in a hotel Real-time ordering of events
send receive receive
Music
service Alarm
X
1 m1 4
gateway service
m2
send
Internet receive
2 3 Physical
Y
receive time

Hotel wireless
send
network Z
Discovery
service receive receive
Camera
m3 m1 m2
A
receive receive receive
TV/PC Guests t1 t2 t3
Laptop PDA
devices

101 102
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

17
 Figure 2.13 Figure 2.14
Objects and principals The enemy
Access rights Object
invocation
Copy of m

Client The enemy

result Server m’
Process p m Process q
Communication channel
Principal (user) Network Principal (server)

103 104
Distributed Systems, Spring 2003 Distributed Systems, Spring 2003

Figure 2.15
Secure channels

Principal A Principal B

Process p Secure channel Process q

105
Distributed Systems, Spring 2003

18