cmpt 401 summer 2007 dr. alexandra fedorova lecture ii: architectural models
Post on 22-Dec-2015
218 views
TRANSCRIPT
![Page 1: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/1.jpg)
CMPT 401 Summer 2007
Dr. Alexandra Fedorova
Lecture II: Architectural Models
![Page 2: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/2.jpg)
2CMPT 401 Summer 2007 © A. Fedorova
Introductions
• Architectural model is an abstract view of a distributed system
• Models are constructed to simplify reasoning about the system
• A model of a DS is expressed in terms of– Components– Placement of components– Interactions among components
![Page 3: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/3.jpg)
3CMPT 401 Summer 2007 © A. Fedorova
Component of a Distributed System
• Component of a distributed system is a process• A process is running program• Examples:
– Server process – a program executing server code– Client process – a program executing client code
• Processes interact by sending each other messages
![Page 4: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/4.jpg)
4CMPT 401 Summer 2007 © A. Fedorova
Outline
• System Architecture Models– Client-Server– Peer-to-Peer– Variations
• Interaction Models• Failure Models• Security Models
![Page 5: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/5.jpg)
5CMPT 401 Summer 2007 © A. Fedorova
Client-Server Architecture I
©Pearson Education 2001
![Page 6: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/6.jpg)
6CMPT 401 Summer 2007 © A. Fedorova
Client-Server Architecture II
• Clients send requests to servers (i.e., invocation)• Servers send responses to clients (i.e., result)• Servers may be clients of other servers
– A web server is often a client of a file server– An Internet service is a client of a DNS server – a server
that translates DNS names to IP addresses• Potential problem: a single server is a scalability
bottleneck and a single point of failure
![Page 7: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/7.jpg)
7CMPT 401 Summer 2007 © A. Fedorova
Peer-to-Peer Architecture I
©Pearson Education 2001
![Page 8: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/8.jpg)
8CMPT 401 Summer 2007 © A. Fedorova
Peer-to-Peer Architecture II
• All processes play similar roles – i.e., they interact as peers
• No central component – potentially better scalability and resiliency to failures
• Use the power of modern desktops to implement a large-scale distributed system
• Examples: Napster, Kazaa, Skype, Bittorrent
![Page 9: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/9.jpg)
9CMPT 401 Summer 2007 © A. Fedorova
Architectural Variations
• Services provided by multiple servers• Proxy servers and caches• Mobile code• Mobile agents• Network computers • Thin clients• Mobile devices
![Page 10: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/10.jpg)
10CMPT 401 Summer 2007 © A. Fedorova
Services by multiple servers
• Multiple servers provide services to clients
• Servers may partition the service objects or replicate them
• WWW: partitioned objects• Sun NIS: replica of a
password file maintained at each server
• Computing clusters
©Pearson Education 2001
![Page 11: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/11.jpg)
11CMPT 401 Summer 2007 © A. Fedorova
Proxy Servers and Caches
• A cache is a store of recently used data objects that is closer than the main store
• A newly accessed object is added to the cache• When that object is accessed again, it is fetched from the cache, if there
is an up-to-date copy in the cache• Proxy servers intercept communication with the real server to provide
faster service (e.g., deliver cached data), better security (e.g., a proxy configured as a firewall)
©Pearson Education 2001
![Page 12: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/12.jpg)
12CMPT 401 Summer 2007 © A. Fedorova
Mobile Code
• Code that is downloaded from a remote machine (e.g., a server) and is run in a local machine (e.g., a client)
• Example: Java applet • Reason: provide better interactive experience
©Pearson Education 2001
![Page 13: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/13.jpg)
13CMPT 401 Summer 2007 © A. Fedorova
Mobile Agents
• A running program (both code and data) that travels from one computer to another
• Example: a worm– Used to attack computer systems– Used for system administration– The original work at Xerox PARC: to make use of idle
computers for a resource-intensive computation
![Page 14: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/14.jpg)
14CMPT 401 Summer 2007 © A. Fedorova
Network Computers
• Does not rely (or relies minimally) on locally installed software
• Downloads operating system and applications from a remote computer
• Applications are run locally, but files are managed on a remote server
• Users can migrate from one network computer to another
![Page 15: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/15.jpg)
15CMPT 401 Summer 2007 © A. Fedorova
Thin Clients• Similar to a network computer• Instead of downloading code to the user computer, it runs it
on a compute server• Software layer provides a window-based interface to the
client (X Windows)
![Page 16: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/16.jpg)
16CMPT 401 Summer 2007 © A. Fedorova
Mobile Devices
• Cellular phones• PDAs • Laptops• Wearable devices• Mobile sensors
![Page 17: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/17.jpg)
17CMPT 401 Summer 2007 © A. Fedorova
Architecture Models: Summary
• Classified according to roles of components:– Client-server– Peer-to-peer
• Variations according to modes of interactions– Services provided by multiple servers– Proxy servers and caches– Mobile code– Mobile agents– Network computers – Thin clients– Mobile devices
![Page 18: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/18.jpg)
18CMPT 401 Summer 2007 © A. Fedorova
Outline
• System Architecture Models• Interaction Models• Failure Models• Security Models
![Page 19: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/19.jpg)
19CMPT 401 Summer 2007 © A. Fedorova
Interaction Models
• Represent communication and coordination among the processes
• Must account for:– Performance of communication channels (communication delays
determine how well the system works)– Differing notions of time across system components
• We will look at the following interaction models– Synchronous– Asynchronous
![Page 20: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/20.jpg)
20CMPT 401 Summer 2007 © A. Fedorova
Communication Delays
• Message transmission delay is comprised of:– Network latency: the time for a bit of information to
travel from source network interface to destination network interface
– Delay in accessing network: i.e., how long it takes for the network to become available
– Operating system delays: the time taken by operating system services at both ends of communication channel
![Page 21: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/21.jpg)
21CMPT 401 Summer 2007 © A. Fedorova
Clocks and Timing Events
• Each computer has its own clock• Reading of a local clock will differ from the real
clock, because a clock drifts• Clock drift rates differ from one another
![Page 22: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/22.jpg)
22CMPT 401 Summer 2007 © A. Fedorova
Synchronous Interaction Model
• In a synchronous distributed system there are known bounds on:– Time to execute a step of a process– Message transmission time– Clock drift rate (i.e., the difference between local clock and the real clock)
• To guarantee bounds, one would need to:– Know resource requirements of each process– Guarantee those resources to the process (including network capacity)– Guarantee bounds on clock drift– Eliminate the possibility of certain failures
• Synchronous distributed systems are rare, because it is difficult to guarantee such bounds
• Synchronous system models are relatively easy to reason about
![Page 23: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/23.jpg)
23CMPT 401 Summer 2007 © A. Fedorova
Asynchronous Interaction Model
• No bounds on delays determining the length of interaction– No bounds on process execution time– No bounds on message transmission delays– No bounds on clock drift rates
• The Internet is an asynchronous system• Despite this uncertainty, many distributed systems
are useful
![Page 24: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/24.jpg)
24CMPT 401 Summer 2007 © A. Fedorova
Outline
• System Architecture Models• Interaction Models• Failure Models• Security Models
![Page 25: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/25.jpg)
25CMPT 401 Summer 2007 © A. Fedorova
Failure Models
• Types of failures– Omission failures– Byzantine failures– Timing failures
• Masking failures
![Page 26: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/26.jpg)
26CMPT 401 Summer 2007 © A. Fedorova
Omission Failures
• An omission failure occurs when a process stops sending/receiving messages.
• Types of omission failures– Process omission failures: the process has crashed– Communication omission failures: message has not
been delivered
![Page 27: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/27.jpg)
27CMPT 401 Summer 2007 © A. Fedorova
Process Omission Failures
• A process crash is called a fail-stop failure• In a synchronous system a fail-stop failure is
determined via timeouts• In an asynchronous system it is impossible to
detect reliably that the process has crashed• If the process is not responding it could have
crashed or it could be just running slowly
![Page 28: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/28.jpg)
28CMPT 401 Summer 2007 © A. Fedorova
Structure of a Communication Channel©Pearson Education 2001
![Page 29: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/29.jpg)
29CMPT 401 Summer 2007 © A. Fedorova
Communication Omission Failure
• Messages can be lost at the sender, at the receiver and in the network:– Receive omission: message is lost on the receiving side– Send omission: message is lost while sending– Channel omission: message is lost between sender and receiver
• A common cause for message loss:– Message buffer overflow due to system being busy– Systems drop messages deliberately when their buffers fill up– Clever algorithms to decide when to drop messages
![Page 30: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/30.jpg)
30CMPT 401 Summer 2007 © A. Fedorova
Failure Models
• Types of failures– Omission failures– Byzantine failures– Timing failures
• Masking failures
![Page 31: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/31.jpg)
31CMPT 401 Summer 2007 © A. Fedorova
Byzantine Failures
• Arbitrary failures– A process arbitrarily skips processing steps– A process takes unintended processing steps– Corrupted message contents
• Arbitrary failures can be caused by:– Malicious behaviour (attack)– Software bugs
• A byzantine failure cannot be reliably detected
![Page 32: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/32.jpg)
32CMPT 401 Summer 2007 © A. Fedorova
Timing Failures
• Apply to synchronous systems• Relevant for multimedia applications• Clock failure: a process’s local clock exceeds the
bounds on the drift rate from real time• Performance failure:
– Process exceeds the bounds on the interval between two steps
– A message transmission takes longer than the stated bound
![Page 33: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/33.jpg)
33CMPT 401 Summer 2007 © A. Fedorova
Impossibility of Agreement
• Theorem: In an asynchronous distributed system it is impossible to reach an agreement in the presence of failures.
![Page 34: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/34.jpg)
34CMPT 401 Summer 2007 © A. Fedorova
Impossibility of Agreement: Proof
1. Suppose agreement is achieved via a sequence of messages2. Suppose agreement could be reached in spite of message loss3. Then it must be possible to eliminate the last message in the
sequence and still reach the agreement4. Now you have one fewer messages in a sequence5. If you keep applying the above argument, you will end up with
the sequence of zero messages6. This is a contradiction: there must be at least one message in
the sequence
![Page 35: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/35.jpg)
35CMPT 401 Summer 2007 © A. Fedorova
Masking Failures
• Conversion from one type of failure to another– When a corrupted message is detected, the process
acts as if the message has been lost– Byzantine Omission
• Handling omission failures via retransmission• Handling fail-stop failures via
– Replication– Restarting the process, restoring its memory state
![Page 36: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/36.jpg)
36CMPT 401 Summer 2007 © A. Fedorova
Outline
• System Architecture Models• Interaction Models• Failure Models• Security Models
![Page 37: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/37.jpg)
37CMPT 401 Summer 2007 © A. Fedorova
Security Models
• Adversary: a process that sends messages that would not be sent by a legitimate process– The goal is to violate integrity or secrecy of data or to
disrupt normal functioning of the system• Types of security threats:
– Threats to processes– Threats to communication channels– Denial of service (DoS) attacks
![Page 38: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/38.jpg)
38CMPT 401 Summer 2007 © A. Fedorova
Threats to Processes
• Forged identity– The client adversary masquerades as a legitimate user and obtains
secret information from the server– The server adversary masquerades as a legitimate server and
sends a wrong response to the client• Taking over the system (i.e., a hacked system)
– An adversary exploits system vulnerability– Sends a packet that causes the server to execute the program
belonging to the adversary (viruses or buffer overflow attacks)– The adversary causes the byzantine failure
![Page 39: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/39.jpg)
39CMPT 401 Summer 2007 © A. Fedorova
Threats to Communication Channels
• Interception of messages:– Watch messages sent over the network, read their
contents: violation of privacy and secrecy (i.e., someone reads my e-mail)
• Injection of messages:– Save a copy of a legitimate message and later “replay”
it on the network– E.g., send a message asking to charge the credit card
multiple times
![Page 40: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/40.jpg)
40CMPT 401 Summer 2007 © A. Fedorova
Denial of Service Attacks
• Flood the system with pointless messages to prevent normal operation of the system
• Causes the system to run very slowly• Many systems are not designed to handle
performance spikes: CNN server became unresponsive on 9/11
![Page 41: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/41.jpg)
41CMPT 401 Summer 2007 © A. Fedorova
Dealing with Security Failures
• Encryption– Scramble the message so as to hide its content, i.e., encrypt– Message can be decrypted using a key. A key is usually a large number that is
difficult to guess. • Authentication
– Encrypt a part of the message; in the encrypted part provide enough information to guarantee authenticity
– Enabled by use of shared secrets and encryption• Secure channels
– Built on top of regular channels using encryption– Communicating processes reliably know each others’ identity– Transmitted cannot be tampered with– Each message includes a physical or logical timestamp to prevent reordering or
replay– Examples: Virtual Private Network (VPN), Secure Sockets Layer (SSL)
![Page 42: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/42.jpg)
42CMPT 401 Summer 2007 © A. Fedorova
Summary I
• System architecture models– Client/server– Peer-to-peer– Variations: mobile devices, network computer, thin
client etc.• Interaction models
– Synchronous system: known bounds on clock drifts and message delays
– Asynchronous system: no such bounds
![Page 43: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/43.jpg)
43CMPT 401 Summer 2007 © A. Fedorova
Summary II
• Failure Model– Omission failures
• Process omission: fail-stop – cannot be reliably detected in an asynchronous system
• Communication omission: Send/receive omission, channel omission– Byzantine failures
• Bugs• Message corruption• Hardest to deal with
– Timing failures• Apply to synchronous systems
• In an asynchronous system agreement cannot be reached in presence of failures
![Page 44: CMPT 401 Summer 2007 Dr. Alexandra Fedorova Lecture II: Architectural Models](https://reader031.vdocument.in/reader031/viewer/2022013011/56649d785503460f94a5baab/html5/thumbnails/44.jpg)
44CMPT 401 Summer 2007 © A. Fedorova
Summary III
• Threat model– Adversary– Threats to processes (spoofing identity, hacking the system)– Threats to communication channels (intercepting messages,
replaying messages)– Denial of service attacks: prevent proper functioning of the
system by sending useless messages• Security threads addressed via encryption, authentication
and secure channels