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.

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.