1. Chapter 2: System Model
Introduction
Architecture Models
Fundamental Models
Summary

2. Introduction Why do we need model? Architecture model
Each model is intended to provide an abstract, simplified but consistent description of a relevant aspect of distributed system design
Architecture model
defines the way in which the components of systems interact with one another and the way in which they are mapped onto the underlying network of computers
Client/Server vs. Peer to Peer
variants of C/S
partition of data or replication as cooperating servers
caching of data by proxy servers and clients
use of mobile code and mobile agents
requirement to add and remove mobile devices in a convenient manner

3. Introduction …continued
Fundamental model
concerned with a more formal description of the properties that are common in all of the architectural models
The interaction model deals with performance and with the difficulty of setting time limits in a distributed system
The failure model attempts to give a precise specification of the faults that can be exhibited by processes and communication channels
The security model discusses the possible threats to processes and communication channels

4. Chapter 3: System Model
Introduction
Architecture Models
Fundamental Models
Summary

5. Concepts What does the architecture model consider? Software layers
The placement of the components across a network of computers – seeking to define useful patterns for the distribution of data and workload
The interrelationships between the components – their functional roles and patterns of communication between them
Software layers
Originally refer to the structuring of software as layers or modules in a single computer
Recently in terms of services offered and requested between processes located in the same or different computers

6. Software and hardware service layers in distributed systems Platform
Software layer
Software and hardware service layers in distributed systems
Platform
The lowest-level hardware and software layers, e.g., Intel x86/Windows, SPARC/SunOS, PowerPC/MacOS
Middleware
A layer of software, mask heterogeneity, provide a convenient programming model to application programmers
Examples: RPC, RMI, CORBA, DCOM, Isis(group communication system)
Limitations: some systems require support at the application level
e.g., In case of transferring large message, TCP provides some error detection and correction, but it can’t recover from major network interruptions. So the mail transfer service at the application layer is required.
‘ the end-to-end argument’ [1984]
some communication-related functions can be completely and reliably implemented only with the knowledge and help of the application standing at the end points of the communication system
Counter to the view of middleware supporters (transparency entirely)

7. Software and hardware service layers in distributed systems

8. What is system architecture?
System architectures
What is system architecture?
The division of responsibilities between system components (applications, server and other processes) and the placement of the components on computers in the network
Main distributed system architectures
1. Client-Server model
Be Historically the most important and remain the most widely employed
Servers may in turn be clients of other servers
2. Services provided by multiple servers
Partition the set of service objects on different servers, e.g. workflow system
Maintain replicated service objects on several hosts, e.g. Sun NIS
3. Proxy servers and caches
A cache is a store of recently used data objects that is closer than the objects themselves
E.g., web page cache at web browser or web proxy server

9. Clients invoke individual servers

10. A service provided by multiple servers

11. Web Proxy Server

12. System architectures … continued
4. Peer processes ( peer to peer )
All of the processes play similar roles, interacting cooperatively as peers to perform a distributed activity or computation without any distinction between clients and servers
Maintain consistency of application-level resources and synchronize application level action when necessary
E.g., a peer-to-peer whiteboard

13. A distributed application based on peer processes

14. Variations on the client-server model
Reasons of variation
The use of mobile code and mobile agents
Users need for low-cost computers with limited hardware resources
The requirement to add and remove mobile devices in a convenient manner
Several variations:
1. Mobile code
good interactive response, e.g., applet
2. Mobile agent
A running program that travels from one computer to another in a network carrying out a task on someone’s behalf, e.g., agilet[IBM], worm[Xerox PARC]
3. Network Computers
Download its operating system and any application software from a remote file server
All the application data and code is stored by a file server, so users may migrate

15. Web applets

16. Variations on the client-server model … continued
4. Thin client
A software layer that supports a window-based user interface on a computer that is local to the user while executing application programs on a remote computer
Drawback : high latencies
Implementation: X-11, VNC[AT&T 1998]
5. Spontaneous networking
The form of distribution that integrates mobile devices and other devices into a given network
Key features: easy connection to a local network, easy integration with local services
Key design issues
Convenient connection and integration
Limited connectivity: mobile device move around continuously, disconnection
Security and privacy
Discovery Services: registration service, lookup service

17. Thin clients and compute servers
Application
Process
Network computer or PC
Compute server
network

18. Spontaneous networking in a hotel
Internet
gateway
PDA
service
Music
Discovery
Alarm
Camera
Guests
devices
Laptop
TV/PC
Hotel wireless
network

19. Design requirements for distributed architectures
Performance issues
Responsiveness: determined by the load and performance of the server and network, delays in the client and server operating system’s communication and middleware services as well as code of the service
Throughput: the rate at which computational work is done, the throughput of the intervening software layers is important
Balancing computational loads
Dependability issues
Fault tolerance: redundancy, e.g., data and processes be replicated, messages be retransmitted
Security: e.g. locate sensitive data in computers that can be secured effectively against attack
Quality of service
Reliability, security
Performance: ability to meet timeliness guarantees
Adaptability: meet changing system configurations and resource
Availability: have necessary computing and network resources at the appropriate times ( the abbreviation QoS)
Use of caching and replication, e.g. Web caching protocol

20. Chapter 3: System Model
Introduction
Architecture Models
Fundamental Models
Summary

21. A system model should address the following questions
Fundamental models
A system model should address the following questions
What are the main entities in the system?
How do they interact?
What are the characteristics that affect their individual and collective behavior?
Purpose of a model
Make explicit all the relevant assumptions about the system we are modeling
Make generalizations concerning what is possible or impossible by logical analysis and mathematical proof
Fundamental models intend to discuss
Interaction
Failure
Security

22. Interaction model Examples of interaction in distributed system
DNS, NIS: multiple server processes cooperate with one another
P2P voice conference system: with strict real-time constraints
Distributed algorithm: a definition of the steps to be taken by each of the processes of which the system is composed, including the transmission of messages between them
Difficult to describe all the states, because of failures of processes and message transmissions
Two significant factors affecting interacting processes
Communication performance is often a limiting characteristic
Latency – the delay between the sending of a message by one process and its receipt by another. Including: Network delay, Accessing delay, OS delay
Bandwidth – total amount of information that can be transmitted over it in a given time
Jitter – variation in the time taken to deliver a series of messages
Impossible to maintain a single global notion of time
Clock drift rate – the relative amount that a computer clock differs from a perfect reference clock
Timing event: e.g., GPS, Logical time

23. Two variants of the interaction model
Synchronous distributed system
The time to execute each step of a process has know lower and upper bounds
Each message transmitted over a channel is received within a known bounded time
Each process has a local clock whose drift rate from real time has a known bound
Asynchronous distributed system – no bounds on
process execution speeds: e.g. each step may take an arbitrarily long time
Message transmission delays: e.g. a message may be received after an arbitrarily long time
Clock drift rates: the drift rate of a clock is arbitrary
Examples of synchronous DS and asynchronous DS
Asynchronous DS: , ftp
Synchronous DS: VOD, voice conference system

24. Example: disorder of messages
Event ordering
Example: disorder of messages
A group including X, Y, Z and A
X send “Meeting” to all; Y and Z reply “Re: Meeting” to all
At A, the messages received are Z.”Re: Meeting”, X.”Meeting”, Y.”Re: Meeting”
Logical time[Lamport 1978]
Provide an ordering among the events at processes running in different computers in a distributed system

25. Failure model
Failure model: defines the ways in which failure may occur in order to provide an understanding of the effects of failures and defeat the failures
Failure models:
1. Omission failures
A process or communication channel fails to perform actions that it is supposed to do
Process omission failure: Crash
Fail-stop: Crash that can be detected by other processes certainly, e.g., by timeouts in synchronous DS
Communication omission failures: dropping messages
Send omission, receive omission, channel omission
Benign failures

26. Failure model …continued
2. Arbitrary (Byzantine) failures
the worst possible failure semantics
Arbitrarily omit intended processing steps or take unintended processing steps. E.g., return a wrong value in response to an invocation
Arbitrary failures in process is hard to be detected, Arbitrary failures in communication channel exist but rare, by recognize and reject the faulty msgs
Class of failure
Affects
Description
Fail-stop
Process
Process halts and remains halted. Other processes may
detect this state.
Crash
not be able to detect this state.
Omission
Channel
A message inserted in an outgoing message buffer never
arrives at the other end’s incoming message buffer.
Send-omission
A process completes a
send,
but the message is not put
in its outgoing message buffer.
Receive-omission
A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary
(Byzantine)
Process or
channel
Process/channel exhibits arbitrary behaviour: it may
send/transmit arbitrary messages at arbitrary times,
commit omissions; a process may stop or take an
incorrect step.

27. Failure model …continued
3. Timing failures
Applicable in synchronous distributed system, but not asynchronous DS
Masking failures
Hide, e.g., replicated servers
convert, e.g., Checksum: arbitrary failure -> omission failure
Reliability of one-to-one communication
Validity – any message in the outgoing message buffer is eventually delivered to the incoming message buffer
Integrity – the message received is identical to one sent, and no messages are delivered twice, against retransmit protocols and malicious messages
Reliable communication is defined in terms of validity and integrity
Class of Failure
Affects
Description
Clock
Process
Process’s local clock exceeds the bounds on its
rate of drift from real time.
Performance
Process exceeds the bounds on the interval
between two steps.
Channel
A message’s transmission takes longer than the
stated bound.

28. The security of a distributed system
Security model
The security of a distributed system
The processes
The communication channels
The objects
Protecting the objects
Access rights: who is allowed to perform the operations of an object
Principal: the authority who has some rights on the object

29. Securing processes and their interactions
The enemy
Threats to processes
To servers: invocate with a false identity, e.g. cheating a mail server
To clients: receive false result, e.g. stealing account password
Threats to communication channels
Copy, alter or inject messages
Save and replay, e.g., retransfer money from one account to another
Denial of service: excessive and pointless invocation on services or message transmissions in a network, resulting in overloading of physical resources (network bandwidth, server processing capacity)
Mobile code: malicious mobile program, e.g. Trojan horse attachment
Communication channel
Copy of m
Process p q
The enemy m’

30. Securing processes and their interactions … continued
Defeating security threats
Cryptography and shared secrets
Identify each other by the shared secrets that are only known by themselves. Cryptography is the base.
Authentication – proving the identities supplied by their senders
Secure channels
Each process knows reliably the identities of the principal on whose behalf the other process is executing
Ensure the privacy and integrity of the data transmitted across it
Each message includes physical or logical time stamp
Principal A
Secure channel
Process p q B

31. Chapter 3: System Model
Introduction
Architecture Models
Fundamental Models
Summary

32. Summary Architecture models Fundamental models
Client / Server, e.g. Web, FTP, NEWS
Multiple Servers, e.g. DNS
Proxy and Cache, e.g. Web Cache
Peer process
Variations of C/S
Mobile code, mobile agent, network computer, thin client, spontaneous networks
Fundamental models
Interaction models – synchronous DS and asynchronous DS
Failure models – omission failures, arbitrary failures and timing failures
Security model - the enemy and the approaches of defeating them