Models of Distributed System

The fundamental concept of Distributed System, Part -3. This is useful for CTEVT Diploma in Computer Engineering Students.

1. Distributed Computing EG 3113 CT Diploma in Computer Engineering 5 th Semester Unit 3.3 Models of Distributed System Lecture by : Er . Ashish K.C(Khatri)

2. Models of Distributed System: The distributed system models are listed as: Physical Model Architectural Model Fundamental Model 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 2

3. 1. Physical Model: Physical models consider the types of computers and devices that constitute a system and their interconnectivity, without details of specific technologies . Physical models are the most explicit way in which to describe a system; they capture the hardware composition of a system in terms of the computers (and other devices, such as mobile phones) and their interconnecting networks . A physical model is a representation of the underlying hardware elements of a distributed system that abstracts away from specific details of the computer and networking technologies employed. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 3

4. Some Physical Model: Baseline physical model: A distributed system in which hardware or software components located at networked computers communicate and coordinate their actions only by passing messages. This leads to a minimal physical model of a distributed system as an extensible set of computer nodes interconnected by a computer network for the required passing of messages 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 4

5. Early distributed systems: Such systems emerged in the late 1970s and early 1980s in response to the emergence of local area networking technology, usually Ethernet. These systems typically consisted of between 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. Providing quality of service was still very much in its infancy and was a focal point for much of the research around such early systems. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 5

6. Internet-scale distributed systems: Building on this foundation, larger-scale distributed systems started to emerge in the 1990s in response to the dramatic growth of the Internet during this time (for example, the Google search engine was first launched in 1996). In such systems, the underlying physical infrastructure consists of a physical model that is, an extensible set of nodes interconnected by a network of networks (the Internet). Such systems exploit the infrastructure offered by the Internet to become truly global. They incorporate large numbers of nodes and provide distributed system services for global organizations and across organizational boundaries. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 6

7. Contemporary distributed systems: In the above systems, nodes were typically desktop computers and therefore relatively static (that is, remaining in one physical location for extended periods), discrete (not embedded within other physical entities) and autonomous (to a large extent independent of other computers in terms of their physical infrastructure). The emergence of mobile computing has led to physical models where nodes such as laptops or smart phones may move from location to location in a distributed system, leading to the need for added capabilities such as service discovery and support for spontaneous interoperation The emergence of ubiquitous computing has led to a move from discrete nodes to architectures where computers are embedded in everyday objects and in the surrounding environment (for example, in washing machines or in smart homes more generally). The emergence of cloud computing and, in particular, cluster architectures has led to a move from autonomous nodes performing a given role to pools of nodes that together provide a given service (for example, a search service as offered by Google). 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 7

8. 2 . Architectural Model: The architecture of a system is its structure in terms of separately specified components and their interrelationships. The overall goal is to ensure that the structure will meet present and likely future demands on it. The architectural model describes responsibilities distributed between system components and how are these components placed. They are of two types: Client-Server Model Peer-to-Peer Model 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 8

9. a. Client-Server Model: The system is structured as a set of processes, called servers, that offer services to the users, called clients. The client-server model is usually based on a simple request/reply protocol, implemented with send/receive primitives or using remote procedure calls (RPC) or remote method invocation (RMI): The client sends a request (invocation) message to the server asking for some service; The server does the work and returns a result (e.g. the data requested) or an error code if the work could not be performed. A server can itself request services from other servers; thus, in this new relation, the server itself acts as a client. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 9

10. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 10

11. b. Peer-to-Peer Model: All processes (objects) play a similar role. Processes (objects) interact without a particular distinction between clients and servers. The pattern of communication depends on the particular application. A large number of data objects are shared; any individual computer holds only a small part of the application database. Processing and communication loads for access to objects are distributed across many computers and access links. This is the most general and flexible model . Peer-to-Peer tries to solve some of the above. It distributes shared resources widely -> share computing and communication loads. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 11

12. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 12

13. Architectural Patterns: They are not themselves necessarily complete solutions but rather offer partial insights that, when combined with other patterns, lead the designer to a solution for a given problem domain . Some architectural patterns are: Layering Tiered architecture Thin clients 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 13

14. Layering architecture: 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 below. A given layer therefore offers a software abstraction, with higher layers being unaware of implementation details, or indeed of any other layers beneath them. In terms of distributed systems, this equates to 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 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 14

15. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 15

16. 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. Intel x86/Windows, Intel x86/Solaris, Intel x86/Mac OS X, Intel x86/Linux and ARM/Symbian are major examples . 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. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 16

17. Tiered architecture: Tiered architectures are complementary to layering. Whereas layering deals with the vertical organization of services into layers of abstraction, tiering 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. Types: - Two Tier - Three Tier 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 17

18. consider the functional decomposition of a given application, as follows: the presentation logic , which is concerned with handling user interaction and updating the view of the application as presented to the user; the application logic , which is concerned with the detailed application-specific processing associated with the application (also referred to as the business logic, although the concept is not limited only to business applications); the data logic , which is concerned with the persistent storage of the application, typically in a database management system. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 18

19. 2-Tier architecture: In the two-tier solution, the three aspects mentioned above must be partitioned into two processes, the client and the server. This is most commonly done by splitting the application logic, with some residing in the client and the remainder in the server (although other solutions are also possible). The advantage of this scheme is low latency in terms of interaction, with only one exchange of messages to invoke an operation. The disadvantage is the splitting of application logic across a process boundary, with the consequent restriction on which parts of the logic can be directly invoked from which other part. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 19

20. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 20

21. 3-Tier architecture: In the three-tier solution, there is a one-to-one mapping from logical elements to physical servers and hence, for example, the application logic is held in one place, which in turn can enhance maintainability of the software. Each tier also has a well-defined role; for example, the third tier is simply a database offering a (potentially standardized) relational service interface. The first tier can also be a simple user interface allowing intrinsic support for thin clients (as discussed below). The drawbacks are the added complexity of managing three servers and also the added network traffic and latency associated with each operation. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 21

22. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 22

23. Thin Clients: The trend in distributed computing is towards moving complexity away from the end-user device towards services in the Internet. This is most apparent in the move towards cloud computing but can also be seen in tiered architectures. This trend has given rise to interest in the concept of a thin client, enabling access to sophisticated networked services, provided for example by a cloud solution, with few assumptions or demands on the client device. More specifically, the term thin client 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. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 23

24. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 24

25. 3. Fundamental Model: The fundamental model is based on the fundamental properties that allow us to be more specific about their characteristics and the failures and security risks they might exhibit. In general, such a fundamental model should contain only the essential ingredients that we need to consider in order to understand and reason about some aspects of a system’s behavior . The purpose of such a model is: 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 Types: - Interaction - Fault - Security 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 25

26. i . Interaction Model: Interaction models are for handling time i . e. for process execution, message delivery, clock drifts, etc . They are of two types: Synchronous distributed system Asynchronous distributed system 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 26

27. a. Synchronous System: Lower and upper bounds on the execution time of processes can be set. Transmitted messages are received within a known bounded time. Drift rates between local clocks have a known bound . In synchronous distributed systems there is a notion of global physical time (with a known relative precision depending on the drift rate). Only synchronous distributed systems have predictable behavior in terms of timing. Only such systems can be used for hard real-time applications. In synchronous distributed system it is possible and safe to use timeouts in order to detect failures of a process or communication link . It is difficult and costly to implement synchronous distributed systems. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 27

28. b. Asynchronous System: Many distributed systems (including those on the Internet) are asynchronous. No bound on process execution time (nothing can be assumed about speed, load, and reliability of computers). No bound on message transmission delays (nothing can be assumed about speed, load, and reliability of interconnections) No bounds on drift rates between local clocks. In an asynchronous distributed system there is no global physical time. Reasoning can be only in terms of logical time (see lecture on time and state). Asynchronous distributed systems are unpredictable in terms of timing. No timeouts can be used. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 28

29. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 29

30. ii. Fault Model: Failures can occur both in processes and communication channels. The reason can be both software and hardware faults. Fault models are needed in order to build systems with predictable behavior in case of faults (systems that are fault-tolerant). such a system will function according to the predictions, only as long as the real faults behave as defined by the “fault model”. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 30

31. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 31

32. iii. Security: The modular nature of distributed systems and their openness exposes them to attack by both external and internal agents. Our security model defines and classifies the forms that such attacks may take, providing a basis for the analysis of threats to a system and for the design of systems that are able to resist them. 8/16/2021 Distributed Computing Notes © Er. Ashish K.C(Khatri) 32