1. Distributed Systems
System Models
Dr. Almetwally Mostafa

2. Dr.Almetwally Mostyafa Summer 2009
OUTLINE
Distributed System Models.
Distributed System Software Layers
Distributed System Architectures.
Client-Server Model Variations.
Distributed Processes Interfaces and Objects.
Distributed Architectures Design Requirements.
Fundamental Models:
Interaction Model.
Failure Model.
Security Model.
Dr.Almetwally Mostyafa Summer 2009

3. Distributed System Models
Architectural models: (as client-server and peer process models)
Define the main components of systems :
What their roles & how they interact,
How deployed in an underlying network of computers.
Describe the layered structure of distributed system software.
Fundamental models:
Concerned with properties that are common in all of the architectural models.
Addressed by three models:
The interaction model: deals with the difficulty of setting time limits.
The failure model: attempts to give a specification of the exhibited faults by processes and communication channels.
The security model: discusses possible threats to processes and communication channels.

4. Software Layers
In the layered view of a system each layer offers its services to the level above and builds its own service on the services of the layer below.
Software architecture is the structuring of software in terms of layers (modules) or services that can be requested locally or remotely.
Applications
Computer and network hardware
Platform
Operating system
Middleware
Dr.Almetwally Mostyafa Summer 2009

5. Dr.Almetwally Mostyafa Summer 2009
Software Layers
Platform:
Lowest-level layers that provide services to other higher layers.
bring a system’s programming interface for communication and coordination between processes .
Examples:
Pentium processor / Windows NT
SPARC processor / Solaris
Middleware:
Layer of software to mask heterogeneity and provide a unified distributed programming interface to application programmers.
Provide services, infrastructure services, for use by application programs.
Object Management Group’s Common Object Request Broker Architecture (CORBA).
Java Remote Object Invocation (RMI).
Microsoft’s Distributed Common Object Model (DCOM).
Limitation: require application level involvement in some tasks.
Dr.Almetwally Mostyafa Summer 2009

6. Dr.Almetwally Mostyafa Summer 2009
System Architectures
The architecture include:
The division of responsibilities between system components.
The placement of the components on computers in the network.
Client-server model:
Most important and most widely distributed system architecture.
Client and server roles are assigned and changeable.
Servers may in turn be clients of other servers.
Services may be implemented as several interacting processes in different host computers to provide a service to client processes:
Servers partition the set of objects on which the service is based and distribute them among themselves (e.g. Web data and web servers)
Servers maintain replicated copies of the service objects on several hosts for reliability and performance (e.g. AltaVista)
Dr.Almetwally Mostyafa Summer 2009

7. System Architectures Clients invoke individual servers Key: Client
invocation
invocation
result
result
Server
Client
Key:
Process:
Computer:
Clients invoke individual servers
Dr.Almetwally Mostyafa Summer 2009

8. System Architectures A service provided by multiple servers Service
Client
Server
Client
Server
A service provided by multiple servers
Dr.Almetwally Mostyafa Summer 2009
Dr. Almetwally Mostafa

9. Centralized Architectures
Figure 2-3. General interaction between a client and a server.
Dr.Almetwally Mostyafa Summer 2009
Dr. Almetwally Mostafa

10. The Client-Server Paradigm
Perhaps the best known paradigm for network applications, the client-server2 model assigns asymmetric roles to two collaborating processes.
One process, the server, plays the role of a service provider which waits passively for the arrival of requests. The other, the client, issues specific requests to the server and awaits its response.  
Dr.Almetwally Mostyafa Summer 2009

11. The Client-Server Paradigm - 2
Simple in concept, the client-server model provides an efficient abstraction for the delivery of network services.
Operations required include those for a server process (always alive) to listen and to accept requests, and for a client process to issue requests and accept responses.
By assigning asymmetric roles to the two sides, event synchronization is simplified: the server process waits for requests, and the client in turn waits for responses.
 Many Internet services are client-server applications. These services are often known by the protocol that the application implements. Well known Internet services include HTTP, FTP, DNS, finger, gopher, etc.
Dr.Almetwally Mostyafa Summer 2009

12. Multitiered Architectures (3)
Figure 2-6. An example of a server acting as client.
Dr. Almetwally Mostafa

13. System Architectures Caches and proxy servers: Cache: Proxy server:
A store of recently used data objects that is closer to the client process than those remote objects.
When an object is needed by a client process the caching service checks the cache and supplies the object from there in case of an up-to-date copy is available.
Proxy server:
Provides a shared cache of web resources for client machines at a site or across several sites.
Increase availability and performance of a service by reducing load on the WAN and web servers.
May be used to access remote web servers through a firewall.

14. System Architectures Web proxy server Client Web server Proxy server

15. A distributed application based on peer processes
System Architectures
Peer processes:
All processes play similar roles without destination as a client or a server.
Interacting cooperatively to perform a distributed activity.
Communications pattern will depend on application requirements.
Application
Coordination
code
A distributed application based on peer processes

16. Client-server Model Variations (Mobile Code)
Example: Java applets
The user running a browser selects a link to an applets whose code is stored on a web server.
The code is downloaded to the browser and runs there.
Advantage:
Good interactive response since.
Does not suffer from the delays or variability of bandwidth associated with network communication.
Disadvantage:
Security threat to the local resources in the destination computer.

17. Client-server Model Variations (Mobile Code)
a) client request results in the downloading of applet code
Web
server
Client
Applet
Applet code
b) client interacts with the applet
Web applets
Dr.Almetwally Mostyafa Summer 2009

18. Client-server Model Variations (Mobile Agents)
A running program (including both code and data) that travels from one computer to another in a network carrying out a task on someone’s behalf.
Can make many invocations to local resources at each visited site.
Visited sites must decide which local resources are allowed to use based on the identity of the user owning the agent.
Advantage: Reduce communication cost and time by replacing remote invocation with local ones.
Disadvantages:
Limited applicability.
Security threat of the visited sites resources.
Dr.Almetwally Mostyafa Summer 2009

19. Client-server Model Variations (Mobile Agents)

20. Dr.Almetwally Mostyafa Summer 2009
Client-server Model Variations (Network Computers)
Downloads its operating system and any applications needed by the user from a remote file server.
Applications run locally but files are managed by a remote file server.
Users can migrate from one network computer to another.
Its processor and memory capacities can be restricted to reduce its cost.
Its disk (if included) holds only a minimum of software and use the reminder space as cache storage to hold copies of the most recently software and data files loaded from servers.
Dr.Almetwally Mostyafa Summer 2009

21. Dr.Almetwally Mostyafa Summer 2009
Client-server Model Variations (Thin Clients)
Software layer that supports a window-based user interface on a local computer while executing application programs on a remote computer.
Same as the network computer scheme but instead of downloading the applications code into the user’s computer, it runs them on a server machine, compute server.
Compute server is a powerful computer that has the capacity to run large numbers of applications simultaneously.
Disadvantage: Increasing of the delays in highly interactive graphical applications
Dr.Almetwally Mostyafa Summer 2009

22. Client-server Model Variations (Thin Clients)
Compute server
Network computer or PC
network
Application
Thin
Client
Process
Thin clients and compute servers
Dr.Almetwally Mostyafa Summer 2009

23. Introduction to AJAX Asynchronous JavaScript and XML
AJAX is using JavaScript, namely the XmlHttpRequest object, to communicate asynchronously with a server-side component and dynamically update the source of an HTML page based on the resulting XML/Text response.
Smart campus:
NFC in your smartphone :

24. Introduction to AJAX

25. AJAX

26. The usual way we operate in the Web - Ajax
Typical browsing behaviour consists of loading a web page, then selecting some action that we want to do, filling out a form, submitting the information, etc.
Web browsing in this sequential manner, requesting one page at a time, and have to wait for the server to respond, loading a whole new web page before we continue.
This is the limitations of web pages, where transmitting information between a client and server generally requires a new page to be loaded.
JavaScript is one way to cut down on the client-server response time, by using it to verify form information before it’s submitted to a server.
JavaScript could not communicate directly with a web server.
Another drawback to this usual sequential access method is that there are many situations where you load a new page that shares lots of the same parts as the old page (consider the case where you have a “menu bar” on the top or side of the page that doesn’t change from page to page).

27. Things changed in Ajax
We used to not have any alternative to this load/wait/respond method of web browsing.
Ajax (sometimes written AJAX) is a means of using JavaScript to communicate with a web server without submitting a form or loading a new page.
Ajax makes use of a built-in object, XMLHttpRequest, to perform this function.
This object is not yet part of the DOM (Document Object Model) standard, but is supported (in different fashions) by Firefox, Internet Explorer, Safari, Opera, and other popular browsers.
The term “Ajax” was coined in 2005, but the XMLHttpRequest object was first supported by Internet Explorer several years before this.

28. Ajax Ajax stands for “Asynchronous JavaScript and XML”.
The word “asynchronous” means that the user isn’t left waiting for the server the respond to a request, but can continue using the web page.
The typical method for using Ajax is the following:
1) A JavaScript creates an XMLHttpRequest object, initializes it with
relevant information as necessary, and sends it to the server. The script
(or web page) can continue after sending it to the server.
2) The server responds by sending the contents of a file or the output of a
server side program (written, for example, in PHP).
3) When the response arrives from the server, a JavaScript function is
triggered to act on the data supplied by the server.
4) This JavaScript response function typically refreshes the display using the
DOM, avoiding the requirement to reload or refresh the entire page.

29. The Back End in Ajax implementations
The part of the Ajax application that resides on the web server is referred to as the “back end”.
This back end could be simply a file that the server passes back to the client, which is then displayed for the user.
Alternatively, the back end could be a program, written in PHP, Perl, Ruby, Python, C, or some other language that performs an operation and sends results back to the client browser.
An XMLHttpRequest object can send information using the GET and POST methods to the server in the same way that an HTML form sends information.
Recall from our previous discussions that the GET request encodes the information inside of the URL, while a POST request sends its data separately (and can contain more information than a GET request can).

30. The Peer-to-Peer System Architecture
In system architecture and networks, peer-to-peer is an architecture where computer resources and services are direct exchanged between computer systems.
These resources and services include the exchange of information, processing cycles, cache storage, and disk storage for files..
In such an architecture, computers that have traditionally been used solely as clients communicate directly among themselves and can act as both clients and servers, assuming whatever role is most efficient for the network.
Dr.Almetwally Mostyafa Summer 2009

31. Peer-to-Peer Distributed Computing Paradigm
In the peer-to-peer paradigm, the participating processes play equal roles, with equivalent capabilities and responsibilities (hence the term “peer”). Each participant may issue a request to another participant and receive a response.
Dr.Almetwally Mostyafa Summer 2009

32. Peer-to-Peer distributed computing
The client-server paradigm is an ideal model for a centralized network service,
The P2P paradigm is more appropriate for applications such as instant messaging, peer-to-peer file transfers, video conferencing, and collaborative work. It is also possible for an application to be based on both the client-server model and the peer-to-peer model.
A well-known example of a peer-to-peer file transfer service is Napster.com or similar sites which allow files (primarily audio files) to be transmitted among computers on the internet. It makes use of a server for directory in addition to the peer-to-peer computing.

34. Architectures Design Requirements
Performance Issues:
Considered under the following factors:
Responsiveness:
Fast and consistent response time is important for the users of interactive applications.
Response speed is determined by the load and performance of the server and the network and the delay in all the involved software components.
System must be composed of relatively few software layers and small quantities of transferred data to achieve good response times.
Throughput:
The rate at which work is done for all users in a distributed system.
Load balancing:
Enable applications and service processes to proceed concurrently without competing for the same resources.
Exploit available processing resources.
Dr.Almetwally Mostyafa Summer 2009

35. Architectures Design Requirements
Quality of Service:
Main system properties that affect the service quality are:
Reliability: related to failure fundamental model (discussed later).
Performance: ability to meet timeliness guarantees.
Security: related to security fundamental model (discussed later).
Adaptability: ability to meet changing resource availability and system configurations.
Dependability issues:
A requirement in most application domains.
Achieved by:
Fault tolerance: continuing to function in the presence of failures.
Security: locate sensitive data only in secure computers.
Correctness of distributed concurrent programs: research topic.
Dr.Almetwally Mostyafa Summer 2009

36. 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

37. Fundamental Models (Interaction Model)
Interacting processes in a distributed system are affected by two significant factors:
Performance of communication channels is characterized by:
Latency: delay between sending and receipt of a message including
Network access time.
Time for first bit transmitted through a network to reach its destination.
Processing time within the sending and receiving processes.
Throughput: number of units (e.g., packets) delivered per time unit.
Bandwidth: total amount of information transmitted per time unit.
Jitter: variation in the time taken to deliver multiple messages of the same type (relevant to multimedia data).

38. Fundamental Models (Interaction Model)
Computer clocks:
Each computer in a distributed system has its own internal clock to supply the value of the current time to local processes.
Therefore, two processes running on different computers read their clocks at the same time may take different time values.
Clock drift rate refers to the relative amount a computer clock differs from a perfect reference clock.
Several approaches to correcting the times on computer clocks are proposed.
Clock corrections can be made by sending messages, from a computer has an accurate time to other computers, which will still be affected by network delays.

39. 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

40. 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

41. Outline System Architecture Models Interaction Models Failure Models
Security Models

42. Dr.Almetwally Mostyafa Summer 2009
Failure Model
Defines the ways in which failure may occur in order to provide an understanding of its effects.
A taxonomy of failures which distinguish between the failures of processes and communication channels is provided:
Omission failures
Process or channel failed to do something.
Arbitrary failures
Any type of error can occur in processes or channels (worst).
Timing failures
Applicable only to synchronous distributed systems where time limits may not be met.
Dr.Almetwally Mostyafa Summer 2009

43. Failure Models Types of failures Masking failures Omission failures
Byzantine failures
Timing failures
Masking failures

44. 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

45. 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

46. Failure Model: structure of a comm. channel
Process p
Process q
Communication channel
send
Outgoing message buffer
Incoming message buffer
receive m
Processes and channels

47. 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 (less straightforward than it might seem)

48. Failure Models Types of failures Masking failures Omission failures
Byzantine failures
Timing failures
Masking failures

49. 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

50. 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

51. Impossibility of Agreement
Theorem: In an asynchronous distributed system it is impossible to reach an agreement in the presence of failures.

52. Impossibility of Agreement: Proof Sketch
Suppose agreement is achieved via a sequence of messages
Suppose agreement could be reached in spite of message loss
Then it must be possible to eliminate the last message in the sequence and still reach the agreement
Now you have one fewer messages in a sequence
If you keep applying the above argument, you will end up with the sequence of zero messages
This is a contradiction: there must be at least one message in the sequence

53. Outline System Architecture Models Interaction Models Failure Models
Security Models

54. 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

55. 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

56. Buffer Overflow Copy one buffer to another Do not check for bounds:
void foo (char *bar) {
char c[12];
strcpy(c, bar); // no bounds checking... }

57. Buffer Overflow (cont.)

58. 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 )
Packet snoopers(염탐) are freely available
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
스마트캠퍼스-학생신분증(분실시 매번 재발행)

59. 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

60. 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 message 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)

61. Fundamental Models (Security Model)
Network
invocation
result
Client
Server
Principal (user)
Principal (server)
Object
Access rights
Objects and principals
Dr.Almetwally Mostyafa Summer 2009

62. Fundamental Models (Security Model)
Communication channel
Copy of m
Process p q
The enemy m’
The enemy

63. Fundamental Models (Security Model)
Principal A
Secure channel
Process p q B
Secure channels
Dr.Almetwally Mostyafa Summer 2009

64. Summary I System architecture models Client/server – HTTP, FTP, Ajax
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

65. 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

66. Summary III Threat models
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