1 / 23

Prepared by Dr. Samia Chelloug E-mail: samia_chelloug@yahoo.fr

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.

Download Presentation

Prepared by Dr. Samia Chelloug E-mail: samia_chelloug@yahoo.fr

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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…)

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

  4. Part 2: System models • Architectural model • Fundamental model • Failure model

  5. 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:

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

  7. System models • Objects are accessed via interfaces.

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

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

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

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

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

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

  14. System models

  15. 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 ).

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

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

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

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

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

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

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

More Related