Distributed Computing - System Models.pptx

System Models
• Complementary ways in design of Distributed Systems
• Three Different system models
• Physical Model
• Architectural Model
• Fundamental Model
• No Global time in Distributed systems
• All communication in process done by messages
• Message communication over network affected by delays
• Suffer from variety of failures
• Vulnerable to security attacks

Issues addressed by three different models
• The interaction model
• deals with performance and with the difficulty of setting time limits in a distributed
system.
• example for message delivery.
• The failure model
• attempts to give a precise specification of the faults that can be exhibited by processes and
communication channels.
• It defines reliable communication and correct processes.
• The security model
• discusses the possible threats to processes and communication channels.
• It introduces the concept of a secure channel, which is secure against those threats.

Difficulties and Threats for Distributed Systems
• Widely varying modes of use
• The component parts of systems are subject to wide variations in workload.
• Some parts of a system may be disconnected, or poorly connected some of the time.
• Some applications have special requirements for high communication bandwidth and low latency.
• Wide range of system environments
• A distributed system must accommodate heterogeneous hardware, operating systems and
networks.
• Internal problems
• Non-synchronized clocks, conflicting data updates and many modes of hardware and software
failure involving the individual system components.
• External threats
• Attacks on data integrity and secrecy, denial of service attacks.

Physical Models
• Representation of the underlying hardware elements of a distributed system that abstracts away from
specific details of the computer and networking technologies employed.
• Baseline Physical Model
• hardware or software components located at networked computers communicate and coordinate their actions only
by passing messages.
• It leads to an extensible set of computer nodes interconnected by a computer network for the required passing of
messages.
• Early distributed systems
• 10 and 100 nodes interconnected by a local area network, with limited Internet connectivity and supported a small
range of services such as shared local printers and file servers as well as email and file transfer across the Internet.
• Individual systems were largely homogeneous and openness was not a primary concern.
• Internet-scale Distributed Systems
• Extensible set of nodes interconnected by a network of networks
• Incorporate large numbers of nodes and provide distributed system services for global organizations and across
organizational boundaries.

Physical Models
• Contemporary distributed systems
• The emergence of mobile computing
• The devices may move from location to location in a distributed system with service discovery and
spontaneous interoperation.
• The emergence of ubiquitous computing
• The device move from discrete nodes to architectures where computers are embedded in everyday objects
and in the surrounding environment
• The emergence of cloud computing
• The device move from autonomous nodes performing a given role to pools of nodes that
together provide a given service.
• Distributed systems of systems
• A system of systems can be defined as a complex system consisting of a series of
subsystems that are systems in their own right and that come together to perform a particular
task or tasks.

Physical Models
• Generations of distributed systems

Architectural Models
• structure in terms of separately specified components and their
interrelationships
• Three Stage Approach
• core architectural elements that underpin modern distributed systems, highlighting
the diversity of approaches that now exist
• examining composite architectural patterns that can be used in isolation or, more
commonly, in combination, in developing more sophisticated distributed systems
solutions
• Middleware platforms are available to support the various styles of programming
that emerge from the above architectural styles

• Architectural Elements
• Communicating Entities
• Communicating Paradigms
• Roles and Responsibilities
• Mapping Consideration
• Questions to understand the fundamental building blocks
• What are the entities that are communicating systems?
• How to communicate, what communication paradigm used?
• What are the roles and responsibilities?
• How to map with physical distributed infrastructure?

• Communication Entities
• From a system perspective,
• communication in a distributed system are typically processes
• Primitive environments - node communication
• Distributed System environments - processes are supplemented by threads
• From a Programming perspective,
• Object
• In distributed object-based approaches,
• a computation consists of a number of interacting objects representing natural units of decomposition for the given
problem domain.
• Objects are accessed via interfaces, with an associated Interface Definition language (or IDL)
• providing a specification of the methods defined on an object.

• Component
• Resemble objects in that they offer problem-oriented abstractions for building distributed systems and
are also accessed through interfaces.
• Component-based middleware often provides additional support for key areas such as deployment and
support for server-side programming.
• Web Services
• Closely related to objects and components, again taking an approach based on encapsulation of
behaviour and access through interfaces.
• The World Wide Web consortium (W3C) defines a web service as:
• a software application identified by a URI, whose interfaces and bindings are capable of being defined, described and
discovered as XML artefacts.
• A Web service supports direct interactions with other software agents using XML-based message exchanges via
Internet-based protocols.

• Communication Paradigm
• Three Types
• Interprocess communication
• Remote Invocation
• Indirect Communication
• Interprocess Communication
• low-level support for communication between processes in distributed systems
• including message-passing primitives, direct access to the API offered by Internet
protocols (socket programming) and support for multicast communication.

• based on a two-way exchange between communicating entities in a distributed system.
• resulting in the calling of a remote operation, procedure or method.
• Direct Communication Methods
• Request-reply protocols
• a pattern imposed on an underlying message-passing service to support client-server computing.
• pairwise exchange of messages
• from client to server and then from server back to client
• with the first message containing an encoding of the operation to be executed at the server and also an array of
bytes holding associated arguments
• the second message containing any results of the operation, again encoded as an array of bytes.
• HTTP protocol

• Direct Communication Methods
• Remote procedure calls
• procedures in processes on remote computers can be called as if they are procedures in the local address space.
• Hides important aspects of distribution, including the encoding and decoding of parameters and results, the
passing of messages and the preserving of the required semantics for the procedure call.
• It supports client-server computing with servers offering a set of operations through a service interface and clients
calling these operations directly.
• Remote Method Invocation
• strongly resembles remote procedure calls
• calling object can invoke a method in a remote object.
• Supports object identity and the associated ability to pass object identifiers as parameters in remote calls.

• Indirect Communication Methods
• Senders do not need to know who they are sending to (space uncoupling).
• Senders and receivers do not need to exist at the same time (time uncoupling).
• Key Techniques
• Group Communication
• Delivery of messages to set of recipients
• Multiparty communication
• Abstraction of group represented by group identifier in a system
• Publish-subscribe system
• Distributed event based systems
• all share the crucial feature of providing an intermediary service
• efficiently ensures information generated by producers is routed to consumers who desire this information.

• Key Techniques
• Message Queues
• offer a point-to-point service
• producer processes can send messages to a specified queue
• consumer processes can receive messages from the queue or be notified of the
arrival of new messages in the queue.
• Tuple Spaces
• processes can place arbitrary items of structured data
• Also known as Generative Communication

• Key Techniques
• Distributed shared memory
• abstraction for sharing data between
processes that do not share physical
memory.
• Presenting a high level of distribution
transparency.
• The underlying infrastructure must ensure
a copy is provided in a timely manner
• It deal with issues relating to
synchronization and consistency of data.

• Roles and Responsibilities
• Two Architectural styles
from the role of individual
process
• Client – Server
• Web servers
• Search Engines
• Web Crawlers
• Peer to peer

• Mapping Consideration
• Placement
• determining the properties of the distributed system with regard to performance, reliability
and security
• Characteristics
• mapping of services to multiple servers
• caching
• mobile code
• mobile agents

• Architectural Patterns
• Layering
• It is related to abstraction
• In a layered approach, a complex system is partitioned into a number of layers, with a
given layer making use of the services offered by the layer.
• A vertical organization of services into service layers.
• A distributed service can be provided by one or more server processes, interacting with
each other and with client processes in order to maintain a consistent system-wide view
of the service’s resources.
• Two major components – Platform and Middleware

• Platform
• A platform for distributed systems and applications consists of the lowest-level
hardware and software layers.
• These low-level layers provide services to the layers above them, which are
implemented independently in each computer,
• bringing the system’s programming interface up to a level that facilitates
communication and coordination between processes.

• Middleware
• Middleware as a layer of software whose purpose is to mask heterogeneity and to provide a convenient programming
model to application programmers.
• Middleware is represented by processes or objects in a set of computers that interact with each other to implement
communication and resource-sharing support for distributed applications.
• It is concerned with providing useful building blocks for the construction of software components that can work with one
another in a distributed system.
• In particular, it raises the level of the communication activities of application programs through the support of
• abstractions such as remote method invocation;
• communication between a group of processes;
• notification of events;
• the partitioning, placement and retrieval of shared data objects amongst cooperating computers;
• the replication of shared data objects; and
•

• Tiered Architecture
• It is a technique to organize functionality of a given layer and place this functionality into
appropriate servers and, as a secondary consideration, on to physical nodes.
• Three tiered architecture
• presentation logic
• concerned with handling user interaction and updating the view of the application as presented to the
user;
• application logic (business logic)
• concerned with the detailed application-specific processing associated with the application.
• data logic
• concerned with the persistent storage of the application, typically in a database management system.

• Tiered Architecture
• Two tier solution – Client server approach
• Advantage
• Low latency in terms of interaction - only one exchange of messages to invoke an operation
• Disadvantage
• splitting of application logic across a
process boundary with multiple constraint
• Three tier solution
• one-to-one mapping from logical elements
to physical servers
• Each tier also has a well-defined role

• Role of Ajax
• Asynchronous Javascript and XML
• an extension to the standard client-server style of interaction used in the World Wide Web.
• AJAX meets the need for fine-grained communication between a Javascript front-end program running in a web
browser and a server-based back-end program holding data describing the state of the application.
• To recapitulate, in the standard web style of interaction a browser sends an HTTP request to a server for a page,
image or other resource with a given URL.
• The server replies by sending an entire page that is either read from a file on the server or generated by a program,
depending on which type of resource is identified in the URL.
• When the resultant content is received at the client, the browser presents it according to the relevant display method
for its MIME type.
• A web page may be composed of several items of content of different types, the entire page is composed and

• Role of Ajax
• Standard style of interaction constraints the development of web application
• Once the browser has issued an HTTP request for a new web page, the user is unable to interact
with the page until the new HTML content is received and presented by the browser.
• This time interval is indeterminate, because it is subject to network and server delays.
• In order to update even a small part of the current page with additional data from the server, an
entire new page must be requested and displayed.
• This results in a delayed response to the user, additional processing at both the client and the
server and redundant network traffic.

• Ajax
• Second innovative step that was needed to enable major interactive web applications to be
developed and deployed.
• It enables Javascript front-end programs to request new data directly from server programs.
• Any data items can be requested and the current page updated selectively to show the new values.
• AJAX is the ‘glue’ that supports the construction of web applications
• It provides a communication mechanism enabling front-end components running in a browser to
issue requests and receive results from back-end components running on a server.
• Clients issue requests through the Javascript XmlHttpRequest object, which manages an HTTP
exchange with a server process.

• Thin Clients
• It refers to a software layer that supports a window-based user interface that is local to the
user while executing application programs or, more generally, accessing services on a
remote computer.
• Advantage
• simple local devices can be significantly enhanced with a plethora of networked services and
capabilities.
• Drawback
• In highly interactive graphical activities such as CAD and image processing - delays
experienced by users are increased to unacceptable levels

• Other commonly occurring platforms
• Proxy
• Brokerage
• Reflection
• Proxy
• It is a recurring pattern to support location transparency in RPC or RMI.
• With this approach, a proxy is created in the local address space to represent the remote
object.
• This proxy offers exactly the same interface as the remote object, and the programmer
makes calls on this proxy object.

• Brokerage
• It supports interoperability in potentially complex distributed infrastructures.
• This pattern consists of the trio of service provider, service requester and service broker.
• Reflection
• Reflection is a pattern that is increasingly being used in distributed systems as a means of
supporting both introspection (the dynamic discovery of properties of the system) and
intercession (the ability to dynamically modify structure or behaviour).
• Standard service interfaces are available at the base level
• Meta-level interface is also available providing access to the components and their

• Associated Middleware Solutions
• It is to provide a higher-level programming abstraction for the development of distributed systems.
• Through layering, to abstract over heterogeneity in the underlying infrastructure to promote
interoperability and portability.
• Categories of Middleware
• Top Level – choice of communicating entities and associated communication paradigms
and follows five of the main architectural models : Distributed objects, distributed
components, publish-subscribe systems, message queues and web services.
• Subcategory – application servers provide support for three tier architecture for security
and reliability.

• Categories of Middleware

• Limitations of Middleware
• To support their needs for communication and data sharing
• Dependability of system require support at application level
• Function as a feature of communication system itself is not sensible
• The correct behaviour in distributed systems depends upon checks, error-correction
mechanisms and security measures at many levels.
• To perform checks within the communication system alone will guarantee only part of
their requiredness

Fundamental Models
• Purpose of this model
• To make explicit all the relevant assumptions about the systems we are modelling.
• To make generalizations concerning what is possible or impossible, given those
assumptions.
• The generalizations may take the form of general-purpose algorithms or desirable
properties that are guaranteed.
• The guarantees are dependent on logical analysis and, where appropriate, mathematical
proof.

Fundamental Models
• Aspects of Distributed Systems
• Interaction:
• Computation occurs within processes
• the processes interact by passing messages, resulting in communication (information flow) and
coordination (synchronization and ordering of activities) between processes.
• Failure:
• The correct operation of a distributed system is threatened whenever a fault occurs in any of the
computers on which it runs (including software faults) or in the network that connects them.
• Security:
• The modular nature of distributed systems and their openness exposes them to attack by both
external and internal agents.

Fundamental Models
• Interaction Model
• Two Significant factors affecting interacting processes in a distributed system
• Communication Performance
• Impossible to maintain a single global notion of time.
• Communication related to latency, bandwidth and jitter
• Latency
• The time taken for the first of a string of bits transmitted through a network to reach its destination.
• The delay in accessing the network, which increases significantly when the network is heavily
loaded.
• The time taken by the operating system communication services at both the sending and the
receiving processes, which varies according to the current load on the operating systems.

Fundamental Models
• Communication related to latency, bandwidth and jitter
• The bandwidth of a computer network is the total amount of information that can be
transmitted over it in a given time.
• Jitter is the variation in the time taken to deliver a series of messages. Jitter is relevant to
multimedia data.
• Each computer in a distributed system has its own internal clock, which can be used by local
processes to obtain the value of the current time.
• Therefore two processes running on different computers can each associate timestamps with their
events.
• The term clock drift rate refers to the rate at which a computer clock deviates from a perfect
reference clock.

Fundamental Models
• Two Variants
• Synchronous Distributed Systems
• Three boundary limits
• The time to execute each step of a process has known 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.

Fundamental Models
• Asynchronous Distributed Systems
• The asynchronous model allows no assumptions about the time intervals involved
in any execution.
• No Boundary limits
• Process execution speeds
• Message transmission delays
• Clock drift rates
• Actual distributed systems are very often asynchronous because of the need for
processes to share the processors and for communication channels to share the
network.

Fundamental Models
• Event Ordering
• consider the following set of exchanges
between a group of email users, X, Y, Z and A, on a mailing list:
1. User X sends a message with the subject Meeting.
2. Users Y and Z reply by sending a message with the subject Re: Meeting.
• In real time, X’s message is sent first, and Y reads it and replies
• Z then reads both X’s message and Y’s reply and sends another reply, which references
both X’s and Y’s messages.
• But due to the independent delays in message delivery, the messages may be delivered

Fundamental Models
• Event Ordering
• messages m1, m2 and m3 would carry
times t1, t2 and t3 where t1<t2<t3.
• The messages received will be displayed to users according to their time ordering.
• If the clocks are roughly synchronized, then these timestamps will often be in the correct
order.
• Lamport's logical time
• to provide an ordering among the events at processes running in different computers in a distributed
system.
• allows the order in which the messages are presented to be inferred without recourse to clocks.

Fundamental Models
• Failure Model
• defines the ways in which failure may occur in order to provide an understanding of the
effects of failures.
• The faults classified as omission failures
• when a process or communication channel fails to perform actions that it is supposed to do.
• Process omission failure
• process has crashed.
• process repeatedly fails to respond to invocation messages.
• Communication omission failure
• Send or Receive omission failure
• Channel omission failure

Fundamental Models
• Failure Model
• Arbitrary Failures(Byzantine failure)
• worst possible failure semantics - any type of error may occur
• Communication channels may suffer
• Timing Failures
• applicable in synchronous distributed systems where time limits are set on process execution time, message
delivery time and clock drift rate.
• Masking Failures
• Each component in a distributed system is generally constructed from a collection of other components.
• It is possible to construct reliable services from components that exhibit failures.
• A service masks a failure either by hiding it altogether or by converting it into a more acceptable type of
failure.

Fundamental Models
• Failure Model
• Timing Failure classes

Fundamental Models
• Failure Model
• Reliability of one to one communication
• The term reliable communication is defined in terms of validity and integrity
• 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.
• The threats to integrity come from two independent sources:
• Any protocol that retransmits messages but does not reject a message that arrives twice.
• Protocols can attach sequence numbers to messages so as to detect those that are delivered twice.
• Malicious users that may inject spurious messages, replay old messages or tamper with messages.
• Security measures can be taken to maintain the integrity property in the face of such attacks.

Fundamental Models
• Security Model
• Security of distributed system achieved by
• securing the processes
• the channels used for their interactions
• protecting the objects that they encapsulate against unauthorized access.
• Protecting Objects
• a server that manages a collection of objects on behalf of some users.
• The users can run client programs that send invocations to the server to perform operations on the
objects.
• The server carries out the operation specified in each invocation and sends the result to the client.
• Objects are intended to be used in different ways by different users.

Fundamental Models
• Security Model
• Securing Process and Interactions
• Processes interact by sending messages.
• The messages are exposed to attack because the network and the communication service that
they use are open, to enable any pair of processes to interact.
• Servers and peer processes expose their interfaces, enabling invocations to be sent to them by
any other process.
• Distributed systems are often deployed and used in tasks that are likely to be subject to
external attacks by hostile users.

Fundamental Models
• Security Model
• The Enemy
• Also known as adversary
• capable of sending any message to any process and reading or copying any message sent
between a pair of processes
• Attacks can be done by using network connection or make false requests to services,
purporting to come from authorized users.
• The threats from a potential enemy include
• threats to processes
• threats to communication channels.

Fundamental Models
• Security Model
• Threats to Processes
• A process that is designed to handle incoming requests may receive a message from any other process in the
distributed system, and it cannot necessarily determine the identity of the sender.
• lack of reliable knowledge of the source of a message is a threat to the correct functioning of both servers and
clients.
• Threats to communication channels
• An enemy can copy, alter or inject messages as they travel across the network and its intervening gateways.
• It leads a threat to the privacy and integrity of information as it travels over the network and to the integrity
of the system.
• Another form of attack is the attempt to save copies of messages and to replay them at a later time, making it
possible to reuse the same message over and over again.

Fundamental Models
• Security Model
• Defeating Security threats
• Cryptography
• Authentication
• Secure Channels – three properties
• client and server communicate via a secure channel, the server knows the identity of the principal
behind the invocations and can check their access rights before performing an operation.
This enables the server to protect its objects correctly and allows the client to be sure that it is receiving
results from a bonafide server.
• A secure channel ensures the privacy and integrity (protection against tampering) of the data
transmitted across it.
• Each message includes a physical or logical timestamp to prevent messages from being replayed or
reordered.

Distributed Computing - System Models.pptx

More Related Content

Similar to Distributed Computing - System Models.pptx

More from nirmalanr2

Recently uploaded

Distributed Computing - System Models.pptx