230 likes | 494 Views
Princess Nora Bint Abdulrahman University College of computer and information sciences Networks department. Distributed systems (NET 422). Prepared by Dr. Samia Chelloug E-mail: samia_chelloug@yahoo.fr. Content. Characterization of distributed systems. System models.
E N D
Princess Nora Bint Abdulrahman UniversityCollege of computer and information sciencesNetworks department Distributed systems (NET 422) Prepared by Dr. Samia Chelloug E-mail: samia_chelloug@yahoo.fr
Content • Characterization of distributed systems. • System models. • Inter-process communication (Internet protocols, external data representation, client-servereur, group communication…). • Distributed objects and remote invocation (RPC, events and notifications, Java, RMI). • Distributed file systems (architecture, case study Sun Nfs). • Name services (concepts, DNS, case study X.5000). • P2P systems and middleware. • Time and global state ( synchronization of physical and logical clocks). • Coordination and agreement. • Replication (system model, fault-tolerant services). • Web services (service description and IDL for web services, case study: the grid…)
Textbooks • George Coulouris, Jean Dollimore, Tim Kindberg, Gordon Blair, ‘Distributed Systems. Concepts and Design’, Fifth Edition, 2012. • Kenneth P.Birman, ‘Reliable Distributed systems: technologies, web services and applications’, Springer • Andrew S.Tanenbaum, Marteen Van Steen, ‘Distributed Systems: Principles and paradigms’, second edition, 2006. • Arno Puder, Kay Romer, Frank Pilttofer, ‘Distributed Systems Architecture: a middle approach’, Elsevier, 2006.
Part 2: System models • Architectural model • Fundamental model • Failure model
System models • How to build distributed systems? • We need a descriptive model that can capture and analyze design issues and properties. • The architecture of a system and its structure in terms of separately specified components and their interrelationships. • The overall goal is to ensure that the structure will meet present and future demands. • What are the entities that are communicating in the distributed system? • How do they communicate? What communication paradigm is used ? Architectural model:
System models • What roles (potentially changing) and responsabilities do they have in the overall architecture? • How are they mapped on to the physical distributed infrastructure? Specific issues for distributed systems: • Entities that communicate in a distributed system are processes but some systems do not support processes abstraction (sensor networks) and hence the entities are nodes. • Objects: have been introduced to enable and encourage the use of oriented –object programming approaches in distributed systems.
System models • Objects are accessed via interfaces.
System models • Web services : closely related to objects. They are intrinsically integrated into the www. A software application identified by a URI, whose interface and binding are capable of being defined, described and discovered as XML. • Communications: • Interprocess communication: refers to the relatively low-level support for communication between processes in distributed systems, including message passing primitives, and direct access to the API. • Remote invocation: results in the calling of a remote operation, procedure or method.
System models -Remote procedure call makes a remote call looks like a local call. -Supports many transparencies and heterogeneities. -Remote method call extends RPC to object-oriented programming. Request-reply: involves a pairwise exchange of messages from client to server and from server to client. • Indirect communications: • Group communication is concerned with the delivery of messages to a set of recipients (one to many). Relies on a group identifier.
System models • Publish-subscribe: Large number of producers (publishers) distribute information : items of interest (events) . • Message queue: Producer processes can send messages to a specified queue and consumer processes can receive messages from the queue. • Distributed shared memory: Enables sharing data between processes that do not share physical memory. A copy is provided in a timely manner.
System models • Roles and responsabilities:(System architecture) What role does a given entity take? • Client/server: Client processes interact with individual servers processes. Servers may in turn be clients of other servers.
System models • Peer - to peer: All processes involved in a task play similar roles, interacting cooperatively as peers without any distinction between client and server processes.
System models • Caching: a store of recently used data objects that is closer to one client or a particular set of clients. • When an object is needed by a client process, the caching service first checks the cache and supplies the object from there if an up-to date copy is available. If not, an up-to-date copy is fetched. • Web browsers maintain a cache of recently visited web pages.
System models • Mobile code: client requests a result in the downloading of applet code. Applets are a well-known and widely used example of mobile code. • The user running a browser, selects a link to an applet whose code is stored on a web browser. • The code is downloaded to the browser and runs there. • Good interactive response (does not suffer from the delays and variability of bandwidth ).
System models • Placement: • The final issue to beconsideredis how entities (objects, services, …) mapinto the underlyingdistributed infrastructure whichwillconsist of a potentially large number of machines interconnected by a network. • No optimal solutions. Onlystrategies to help • Layeringis a vertical organization of services into service layers.
System models • Tiered architecture is complementary to layering. It enables organizing functionnality of a given layer and place this functionnality into appropriate servers and, as a second consideration, on to physical nodes.
System models Fundamental model: Fundamental model allows us to be more specific about some characteristics of distribted systems and the failures and security risks they might exhibit. • Interaction model: • The rate at which each process proceeds and the timing of the transmission of messages between them cannot in general be predicted. • Latency is defined as the delay between the start of message ‘s transmission from one process and the begining of its receipt by another.
System models • Computer clocks and timing events: • Each computer has its own internal clock, which can be used by local processes to obtain the value of the current time. • Two variants of interaction models: synchronous and asynchronous ones. • Synchronous: time to execute each step of a process has known lower and upper bounds. Each message is recived with a known bound time. • In some distributed systems, we are interested in knowing whether an event at one process occured before, after or concurrently with another event.
System models • If the clocks on X’s, Y’s and Z’s computers could be synchronized, each message could carry the time on local computer’s clock. t1 < t2 < t3
System models • Failure model: • Both processes and communication channels may fail. • Failure model defines the way in which failure may occur. • Omission failures: • Process p performs a send by inserting the message m in its outgoing message queue. • The communication channel is responsible for transporting m to q’s incomming message queue. • Process q perfomrs a receive by taking m from its incoming message buffer.
System models • Omission failure is known as « dropping messages ». • Omission failure is caused by lack of buffer space at the receiver or at any intermediate gateway.