communication in distributed systems
•Download as PPTX, PDF•
1 like•160 views
This document discusses communication in distributed systems. It begins with an introduction that describes how distributed computing will be central to many critical applications but also faces challenges around reliability and scalability. The document then covers communication protocols and architectures for distributed systems, including layered, object-based, data-centered, and event-based styles. It also discusses topics like reliability, communication in groups, and order of communication. The conclusion restates that the best architecture depends on application requirements and environment.
Report
Share
communication in distributed systems
- 1. Communication in Distributed Systems By Hussian A.al-kabi Mohammed R.al-rekabe
- 2. Content …. Introduction Communication in Distributed Systems Architecture of Distributed System Layered style object based data-centered event-based Reliability Communication in groups Order Communication Conclusion References
- 3. Introduction Distributed computing will be central to advances in a broad range of critical applications, including intelligence information systems, military command and control, air traffic control, electric power grid management, telecommunications, and a vast array of web-based commercial and government applications. Indeed, a massive rollout of such systems is already underway. Yet while impressive capabilities have been easy to develop and demonstrate in small-scale settings, once deployed these systems often stumble badly. Software that runs securely and reliably in small-scale mockups may lose those properties as numbers of users, the size of the network and transaction processing rates all increase. Whereas small networks are well behaved, any sufficiently large network behaves like the public Internet, exhibiting disruptive overloads and routing changes, periods of poor connectivity and throughput instability. Failures rise in frequency simply because the numbers of participating components are larger. A scalable technology must ride out such forms of infrastructure instability
- 4. In a distributed system there is no shared memory and thus the whole nature of the communication between processes should be reconsidered. The processes, to communicate, must adhere to rules known as protocols. For distributed systems in a wide area, these protocols often take the form of several layers and each layer has its own goals and rules. Messages are exchanged in various ways, and there are many design options in this regard, an important option is the "remote procedure call. It is also important to consider the possibilities of communication between groups of processes, not only between two processes.
- 5. ARCHITECTURE of Distributed System Software Architecture of Distributed System: It deals with how software components are organised and, how they work together, i.e., communicate with each other. Typical software architectures include: • Layered, • object-oriented, • data-centred, • and event-based Software architectures
- 6. Contd… System Architecture: placement of machines placement of software on machines There is no single best architecture: The best architecture for a particular system depends on the application requirements and the environment.
- 7. Architectural styles(1/4): Layered style Observation: Layered style is used for client-server system
- 8. Contd… Components at layer LNare allowed to call components at underlying layers LN-1,but not the other way around. Database Layer Data Management Layer Applications Layer User Interface Layer Requests Results
- 9. Architectural styles (2/4): object based Object Object Object Object Object Method Calls Basic idea: Organize into logically different components, and subsequently distribute those components over the various machines. Observation: object-based style for distributed object systems. In essence, each object corresponds to what we have defined as a component and these components are connected through a (remote) procedure call mechanism. component = object connector = RPC or RMI
- 10. Architectural styles (3/4): data-centered Main purpose: data access and update Processes interact by reading and modifying data in some shared repository (active or passive) Traditional database (passive): responds to requests Blackboard system (active): system updates clients when information changes.
- 11. Architectural Styles (4/4): event-based Processes communicate through event propagation ‘Publish/Subscribe’ systems • Processes subscribed to events will receive them. Benefit is, components are loosely coupled; i.e. they don’t need to explicitly refer to each other.
- 12. Contd… Figure (a) The event-based architectural style • Communication via event propagation, in dist. Systems communication often in Publish/ Subscribe; e.g., register interest in market info; get email updates •Decouples sender & receiver; asynchronous communication Event-based arch. supports several communication styles: • Publish-subscribe • Broadcast • Point-to-point
- 13. Contd… Data Centric Architecture; e.g., shared distributed file systems or Web-based distributed systems Combination of data-centered and event based architectures Processes communicate asynchronously Figure (b) The shared data-space architectural style.
- 14. CLIENT-SERVER
- 15. Client-Server from another perspective A typical client-server application can be decomposed into three logical parts: the interface part, the application logic part, and the data part. Implementations of the client-server architecture vary with regards to how the parts are separated over the client and server roles.
- 16. VERTICAL DISTRIBUTION (MULTI-TIER) splitting up a server’s functionality over multiple computers Three layers’ of functionality: User interface Processing/Application logic Data Splitting up the server functionality in this way is beneficial to a system’s scalability as well as its flexibility. Scalability is improved because the processing load on each individual server is reduced, and the whole system can therefore accommodate more users. Logically different components on different machines The vertical distribution, or multi-tier, architecture distributes the traditional server functionality over multiple servers. A client request is sent to the first server. 1 6
- 17. Vertical Distribution from another perspective
- 18. HORIZONTAL DISTRIBUTION replicating a server’s functionality over multiple computers In this case, each server machine contains a complete copy of all hosted Web pages and client requests are passed on to the servers in a round robin fashion. The horizontal distribution architecture is generally used to improve scalability (by reducing the load on individual servers) and reliability (by providing redundancy). Logically equivalent components replicated on different machines
- 19. PEER TO PEER COMMUNICATION ARCHITECTURE All processes have client and server roles. With the potentially huge number of participating nodes in a peer to peer network, it becomes practically impossible for a node to keep track of all other nodes in the system and the information they offer.
- 20. Issues related to reliability of communication; -Ensuring that the message was received on node (s) target (s) -Maintenance of order in the delivery of messages -Flow control to avoid "flooding" the receiving node -Fragmentation of the messages to eliminate limitations on size Maximum messages If the communication system does not guarantee some of these aspects, it must send the application
- 21. three choices: - Order FIFO: Messages from one source reach each receiver in the order they are sent. ·There are no guarantees on messages from different issuers -Causal ordering: If the messages sent between two emitting a possible relationship "cause and effect, all group process first receive the message "cause" and then message "effect." - If no connection, no guarantee any delivery order - Definition of "causality" is discussed in "Synchronization" -Total Management:All messages (various sources) sent a group are received in the same order for all items.
- 22. References [1] J.-M. Andreoli, C. Hankin, and D. Le Me´tayer, Coordination Programming: Mechanisms, Models and Semantics. World Scientific, 1996. [2] F. Arbab and F. Mavaddat, “Coordination Languages and Models,” Proc. Coordination 2002 Conf., Apr. 2002. [3] Abstract State Machines (ASMs), http://www.eecs.umich.edu/ gasm, 2003. [4] AsmL for Microsoft.NET, http://www.research.microsoft.com/ foundations/asml, 2003. [5] M. Barnett and W. Schulte, “Runtime Verification of .NET Contracts,” J. Systems and Software, vol. 65, no. 3, pp. 199-208, 2002. [6] M. Barnett, C. Campbell, W. Schulte, and M. Veanes, “Specification, Simulation and Testing of COM Components Using Abstract State Machines,” Formal Methods and Tools for Computer Science, Proc. Eurocast 2001 Conf., pp. 266-270, Feb. 2001. [7] M. Barnett, W. Grieskamp, Y. Gurevich, W. Schulte, N. Tillmann, and M. Veanes, “Scenario-Oriented Modeling in AsmL and Its Instrumentation for Testing,” Proc. Int’l Conf. Software Eng. (ICSE/ SCESM), 2003. [
- 23. 8] M. Barnett, W. Grieskamp, L. Nachmanson, W. Schulte, N.Tillmann, and M. Veanes, “Towards a Tool Environment for Model-Based Testing with AsmL,” Proc. Formal Approaches to Software Testing Conf. (FATES 2003), 2004. [9] M. Barnett, L. Nachmanson, and W. Schulte, “Conformance Checking of Components Against Their Non-Deterministic Specifications,” Technical Report MSR-TR-2001-56, Microsoft Research, June 2001. [10] G. Bella and E. Riccobene, “Formal Analysis of the Kerberos Authentication System,” J. Universal Computer Science, vol. 3, no. 12, pp. 1337-1381, 1997. [11] A. Blass and Y. Gurevich, “Abstract State Machines Capture Parallel Algorithms,” ACM Trans. Computational Logic, vol. 4, no. 4, pp. 578-651, Oct. 2003. [12] E. Bo¨rger and R. Sta¨rk, Abstract State Machines: A Method for High- Level System Design and Analysis. Springer, 2003. [13] D. Box, “Code Name Indigo: A Guide to Developing and Running Connected Systems with Indigo,” MSDN Magazine, http://msdn. microsoft.com/msdnmag/, 2003. [14] P. Clements, “A Survey of Architecture Description Languages,” Proc. Eighth Int’l Workshop Software Specification and Design, Mar. 1996. [15] D.E. Comer, Internetworking with TCP/IP, Principles, Protocols, and Architectures. Prentice Hall, 2000. [16] R. Farahbod, U. Gla¨sser, and M. Vajihollahi, “Specification and Validation of the Business Process Execution Language for Web Services,” Technical Report SFU-CMPT-TR-2003-06, Simon Fraser Univ., Sept. 2003. [17] R. Farahbod, U. Gla¨sser, and M. Vajihollahi, “Specification and Validation of the Business Process Execution Language for Web Services,” Proc. ASM Conf. 2004, 2004. [18] Foundations of Software Engineering Group at Microsoft, http:// research.microsoft.com/fse, 2003. [
- 24. [19] van Renesse, Robbert, Minsky, Yaron, and Hayden, Mark, “A Gossip-Based Failure Detection Service”, in the Proceedings of Middleware '98. England, August 1998. [20] van Renesse, Robbert, and Birman, Kenneth P,“Astrolabe: A Robust and Scalable Technology for Distributed System Monitoring, Management, and Data Mining”, Submitted to ACM TOCS, November 2001 [21] van Renesse, Robbert, and Birman, Kenneth P,Dumitriu, Dan and Vogels, Werner, “Scalable Management and Data Mining Using Astrolabe” in the. Proceedings of the First International Workshop on Peer-to-Peer Systems (IPTPS),. Cambridge, Massachusetts. March 2002. the Proceedings of the International Workshop on Reliable Peer-to-Peer Systems, Osaka, Japan. October 2002. [22] Werner Vogels, Chris Re, Robbert van Renesse and Ken Birman, .”A Collaborative Infrastructure for Scalable and Robust News Delivery”. In the Proceedings of the IEEE Workshop on Resource Sharing in Massively Distributed Systems (RESH'02), Vienna, Austria, July 2002.