Upload
adityabaid4
View
221
Download
0
Embed Size (px)
Citation preview
7/28/2019 5 SD Communication
1/67
Communication in Distributed SystemsDistributed Systems
Sistemi Distribuiti
Andrea [email protected]
Dipartimento di Informatica Scienza e Ingegneria (DISI)Alma Mater Studiorum Universita di Bologna a Cesena
Academic Year 2012/2013
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 1 / 42
http://find/7/28/2019 5 SD Communication
2/67
Outline
Outline
1 Interaction & Communication
2 Fundamentals
3 Remote Procedure Call
4 Message-oriented Communication
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 2 / 42
http://find/7/28/2019 5 SD Communication
3/67
Disclaimer
These Slides Contain Material from[Tanenbaum and van Steen, 2007]
Slides were made kindly available by the authors of the book
Such slides shortly introduced the topics developed in the book
[Tanenbaum and van Steen, 2007] adopted here as the main book ofthe course
Most of the material from those slides has been re-used in thefollowing, and integrated with new material according to the personalview of the teacher of this course
Every problem or mistake contained in these slides, however, shouldbe attributed to the sole responsibility of the teacher of this course
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 3 / 42
http://find/7/28/2019 5 SD Communication
4/67
Previous Knowledge
What You Are Supposed to Know. . .
. . . from the Courses of Computer Networks, Telecommunication
Networks and Foundations of Informatics
Basics about protocols
ISO/OSI
Protocols and reference model
Main network and Internet protocols
Basics about communication
Procedure call
Representation formats and problems e.g., little endian vs. bigendian
Sockets
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 4 / 42
P i K l d
http://find/7/28/2019 5 SD Communication
5/67
Previous Knowledge
What You Are Supposed to Know. . .
. . . from the Courses of Computer Networks, Telecommunication
Networks and Foundations of Informatics
Basics about protocols
ISO/OSI
Protocols and reference model
Main network and Internet protocols
Basics about communication
Procedure call
Representation formats and problems e.g., little endian vs. bigendian
Sockets
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 4 / 42
I t ti & C i ti
http://find/7/28/2019 5 SD Communication
6/67
Interaction & Communication
Outline
1 Interaction & Communication
2 Fundamentals
Layers & ProtocolsTypes of Communication
3 Remote Procedure Call
4 Message-oriented CommunicationStream-oriented Communication
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 5 / 42
Interaction & Communication
http://find/7/28/2019 5 SD Communication
7/67
Interaction & Communication
The Role of Interaction in Distributed System
Interaction vs. Computation
Talking of processes, threads, LWP, and the like, is just half of thestoryMaybe, not even the most important half. . .
They represent the computational components of a (distributed)system
Components of a system actually make a system only by interactingwith each other
Interaction represents an orthogonal dimension with respect tocomputation
Engineering Interaction
Methodologies and technologies for engineering communication arenot the same as those for engineering computationNew models and tools are requiredwhich could be seamlessly integrated with those for engineeringcomputational components
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 6 / 42
Interaction & Communication
http://find/7/28/2019 5 SD Communication
8/67
Interaction & Communication
The Role of Interaction in Distributed System
Interaction vs. Computation
Talking of processes, threads, LWP, and the like, is just half of thestoryMaybe, not even the most important half. . .
They represent the computational components of a (distributed)system
Components of a system actually make a system only by interactingwith each other
Interaction represents an orthogonal dimension with respect tocomputation
Engineering Interaction
Methodologies and technologies for engineering communication arenot the same as those for engineering computationNew models and tools are requiredwhich could be seamlessly integrated with those for engineeringcomputational components
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 6 / 42
Interaction & Communication
http://find/7/28/2019 5 SD Communication
9/67
Interaction & Communication
Interaction vs. Communication
Interaction is more general than communication
Communication is a form of interactionCommunication is interaction where information is exchangedNot every interaction is communicationE.g., sharing the same space is a way of interacting without
communicating
Whereas such a distinction is not always evident from the literature. . .
On the one hand, we should keep this in mindOn the other hand, in the classical field of inter-process
communication, this distinction is often not essential
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 7 / 42
Interaction & Communication
http://find/7/28/2019 5 SD Communication
10/67
Interaction & Communication
Interaction vs. Communication
Interaction is more general than communication
Communication is a form of interactionCommunication is interaction where information is exchangedNot every interaction is communicationE.g., sharing the same space is a way of interacting without
communicating
Whereas such a distinction is not always evident from the literature. . .
On the one hand, we should keep this in mindOn the other hand, in the classical field of inter-process
communication, this distinction is often not essential
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 7 / 42
Interaction & Communication
http://find/7/28/2019 5 SD Communication
11/67
&
Communication in Non-distributed Settings
Communication does not belong to distributed systems only
Communication mechanisms like procedure call and message-passing
just require a plurality of interacting entities, not distributed onesHowever, communication in distributed systems presents moredifficult challenges, like unreliability of communication and large scale
Of course, communication in distributed systems first of all deals withdistribution / location transparency
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 8 / 42
Fundamentals
http://find/7/28/2019 5 SD Communication
12/67
Outline
1 Interaction & Communication
2 Fundamentals
Layers & ProtocolsTypes of Communication
3 Remote Procedure Call
4 Message-oriented CommunicationStream-oriented Communication
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 9 / 42
Fundamentals Layers & Protocols
http://find/7/28/2019 5 SD Communication
13/67
y
Outline
1 Interaction & Communication
2 Fundamentals
Layers & ProtocolsTypes of Communication
3 Remote Procedure Call
4 Message-oriented CommunicationStream-oriented Communication
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 10 / 42
Fundamentals Layers & Protocols
http://goforward/http://find/http://goback/7/28/2019 5 SD Communication
14/67
Layered Communication
Communication involves a number of problems at many different levels
From the physical network level up to the application levelCommunication can be organised on layersA reference model is useful to understand how protocols, behavioursand interactions
OSI model
Standardised by the International Standards Organization (ISO)Designed to allow open systems to communicateRules for communication govern the format, content and meaning of
messages sent and receivedSuch rules are formalised in protocolsThe collection of protocols for a particular system is its protocolstack, or protocol suite
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 11 / 42
Fundamentals Layers & Protocols
http://find/7/28/2019 5 SD Communication
15/67
Layered Communication
Communication involves a number of problems at many different levels
From the physical network level up to the application levelCommunication can be organised on layersA reference model is useful to understand how protocols, behavioursand interactions
OSI model
Standardised by the International Standards Organization (ISO)Designed to allow open systems to communicateRules for communication govern the format, content and meaning of
messages sent and receivedSuch rules are formalised in protocolsThe collection of protocols for a particular system is its protocolstack, or protocol suite
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 11 / 42
Fundamentals Layers & Protocols
http://find/7/28/2019 5 SD Communication
16/67
Types of Protocols
Connection-oriented protocols
First of all, a connection is established between the sender and thereceiver
Possibly, an agreement over the protocol to be used is reached
Then, communication occurs through the connection
Finally, the connection is terminated
Connectionless protocols
No setup is required
The sender just send a message when it is ready
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 12 / 42
Fundamentals Layers & Protocols
http://find/7/28/2019 5 SD Communication
17/67
Types of Protocols
Connection-oriented protocols
First of all, a connection is established between the sender and thereceiver
Possibly, an agreement over the protocol to be used is reached
Then, communication occurs through the connection
Finally, the connection is terminated
Connectionless protocols
No setup is required
The sender just send a message when it is ready
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 12 / 42
Fundamentals Layers & Protocols
http://find/7/28/2019 5 SD Communication
18/67
The OSI Reference Model
Layers, interfaces, and protocols in the OSI Model[Tanenbaum and van Steen, 2007]
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 13 / 42
Fundamentals Layers & Protocols
http://find/7/28/2019 5 SD Communication
19/67
A Message in the OSI Reference Model
A typical message as it appears on the network[Tanenbaum and van Steen, 2007]
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 14 / 42
Fundamentals Layers & Protocols
http://find/7/28/2019 5 SD Communication
20/67
OSI Model = OSI Protocols
OSI protocols
Never successful
TCP/IP is not an OSI protocol, and still dominates its layers
OSI model
Perfect to understand and describe communication systems throughlayers
However, some problems exist when middleware comes to play
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 15 / 42
Fundamentals Layers & Protocols
http://find/7/28/2019 5 SD Communication
21/67
OSI Model = OSI Protocols
OSI protocols
Never successful
TCP/IP is not an OSI protocol, and still dominates its layers
OSI model
Perfect to understand and describe communication systems throughlayers
However, some problems exist when middleware comes to play
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 15 / 42
Fundamentals Layers & Protocols
http://goforward/http://find/http://goback/7/28/2019 5 SD Communication
22/67
Middleware Protocols
The problem
Middleware mostly lives at the application levelProtocols for middleware services are different from high-levelapplication protocols
Middleware protocols are application-independent, applicationprotocols are obviously application-dependentHow can we distinguish between the two sorts of protocols at thesame layer?
Extending the reference model for middleware
Session and presentation layers are replaced by a middleware layer,which includes all application-independent protocolsPotentially, also the transport layer could be offered in the middlewareone
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 16 / 42
Fundamentals Layers & Protocols
http://find/7/28/2019 5 SD Communication
23/67
Middleware Protocols
The problem
Middleware mostly lives at the application levelProtocols for middleware services are different from high-levelapplication protocols
Middleware protocols are application-independent, applicationprotocols are obviously application-dependentHow can we distinguish between the two sorts of protocols at thesame layer?
Extending the reference model for middleware
Session and presentation layers are replaced by a middleware layer,which includes all application-independent protocolsPotentially, also the transport layer could be offered in the middlewareone
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 16 / 42
Fundamentals Layers & Protocols
http://find/7/28/2019 5 SD Communication
24/67
Middleware as an Additional Service in Client-ServerComputing
Adapted reference model for network communication[Tanenbaum and van Steen, 2007]
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 17 / 42
Fundamentals Types of Communication
http://find/7/28/2019 5 SD Communication
25/67
Outline
1 Interaction & Communication
2 FundamentalsLayers & ProtocolsTypes of Communication
3 Remote Procedure Call
4 Message-oriented CommunicationStream-oriented Communication
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 18 / 42
Fundamentals Types of Communication
http://find/7/28/2019 5 SD Communication
26/67
Types of Communication
Persistent vs. transient communication
Persistent communication A message sent is stored by thecommunication middleware until it is delivered to the receiver No need for time coupling between the sender and the receiver
Transient communication A message sent is stored by thecommunication middleware only as long as both the receiver and thesender are executing
Time coupling between the sender and the receiver
Asynchronous vs. synchronous communication
Asynchronous communication The sender keeps on executing aftersending a message
The message should be stored by the middlewareSynchronous communication The sender blocks execution aftersending a message and waits for response until the middlewareacknowledges trasmission, or, until the receiver acknowledges thereception, or, until the receiver has completed processing the request
Some form of coupling in control between the sender and the receiver
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 19 / 42
Fundamentals Types of Communication
http://find/7/28/2019 5 SD Communication
27/67
Types of Communication
Persistent vs. transient communication
Persistent communication A message sent is stored by thecommunication middleware until it is delivered to the receiver No need for time coupling between the sender and the receiver
Transient communication A message sent is stored by thecommunication middleware only as long as both the receiver and thesender are executing
Time coupling between the sender and the receiver
Asynchronous vs. synchronous communication
Asynchronous communication The sender keeps on executing aftersending a message
The message should be stored by the middlewareSynchronous communication The sender blocks execution aftersending a message and waits for response until the middlewareacknowledges trasmission, or, until the receiver acknowledges thereception, or, until the receiver has completed processing the request
Some form of coupling in control between the sender and the receiver
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 19 / 42
Fundamentals Types of Communication
http://find/7/28/2019 5 SD Communication
28/67
Communications with a Middleware Layer
Viewing middleware as an intermediate (distributed) service inapplication-level communication
[Tanenbaum and van Steen, 2007]
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 20 / 42
Fundamentals Types of Communication
C S
http://find/7/28/2019 5 SD Communication
29/67
Actual Communication in Distributed Systems
Persistency & synchronisation in communication
In the practice of distributed systems, many combinations of persistency andsynchronisation are typically adoptedPersistency and synchronisation should then be taken as two dimensions along whichcommunication and protocols could be analysed and classified
Discrete vs. streaming communication
Communication is not always discrete, that is, it does not always happen throughcomplete units of information e.g., messagesDiscrete communication is then quite common, but not the only way available anddoes not respond to all the needsSometimes, communication needs to be continuous through sequences of messagesconstituting a possibly unlimited amount of information
Streaming communication The sender delivers a (either limited or unlimited) sequenceof messages representing the stream of information to be sent to the receiver
Communication may be continuous
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 21 / 42
Fundamentals Types of Communication
A l C i i i Di ib d S
http://find/7/28/2019 5 SD Communication
30/67
Actual Communication in Distributed Systems
Persistency & synchronisation in communication
In the practice of distributed systems, many combinations of persistency andsynchronisation are typically adoptedPersistency and synchronisation should then be taken as two dimensions along whichcommunication and protocols could be analysed and classified
Discrete vs. streaming communication
Communication is not always discrete, that is, it does not always happen throughcomplete units of information e.g., messagesDiscrete communication is then quite common, but not the only way available anddoes not respond to all the needsSometimes, communication needs to be continuous through sequences of messagesconstituting a possibly unlimited amount of information
Streaming communication The sender delivers a (either limited or unlimited) sequenceof messages representing the stream of information to be sent to the receiver
Communication may be continuous
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 21 / 42
Remote Procedure Call
O li
http://goforward/http://find/http://goback/7/28/2019 5 SD Communication
31/67
Outline
1 Interaction & Communication
2 FundamentalsLayers & Protocols
Types of Communication
3 Remote Procedure Call
4 Message-oriented CommunicationStream-oriented Communication
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 22 / 42
Remote Procedure Call
R t P d C ll (RPC)
http://goforward/http://find/http://goback/7/28/2019 5 SD Communication
32/67
Remote Procedure Call (RPC)
Basic idea
Programs can call procedures on other machinesWhen a process A calls a procedure on a machine B, A is suspended,and execution of procedure takes place on BOnce the procedure execution has been completed, its completion issent back to A, which resumes execution
Information in RPC
Information is not sent directly from sender to receiverParameters are just packed and transmitted along with the request
Procedure results are sent back with the completionNo message passing
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 23 / 42
Remote Procedure Call
R t P d C ll (RPC)
http://find/7/28/2019 5 SD Communication
33/67
Remote Procedure Call (RPC)
Basic idea
Programs can call procedures on other machinesWhen a process A calls a procedure on a machine B, A is suspended,and execution of procedure takes place on BOnce the procedure execution has been completed, its completion issent back to A, which resumes execution
Information in RPC
Information is not sent directly from sender to receiverParameters are just packed and transmitted along with the request
Procedure results are sent back with the completionNo message passing
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 23 / 42
Remote Procedure Call
Iss s f RPC
http://find/7/28/2019 5 SD Communication
34/67
Issues of RPC
Main problems
The address space of the caller and the callee are separate anddifferent
Need for a common reference spaceParameters and results have to be passed and handled correctly
Need for a common data format
Either / both machines could unexpectedly crash
Need for suitable fault-tolerance policies
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 24 / 42
Remote Procedure Call
Conventional Procedure Call
http://find/http://goback/7/28/2019 5 SD Communication
35/67
Conventional Procedure Call
Parameter passing in a local procedure call[Tanenbaum and van Steen, 2007]
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 25 / 42
Remote Procedure Call
Client & Server Stubs
http://find/http://goback/7/28/2019 5 SD Communication
36/67
Client & Server Stubs
Main goal: transparency
RPC should be like local procedure call from the viewpoint of boththe caller and the callee
Procedure calls are sent to the client stub and transmitted to theserver stub through the network to the called procedure
Principle of RPC between a client and server program[Tanenbaum and van Steen, 2007]
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 26 / 42
Remote Procedure Call
Steps for a RPC
http://find/7/28/2019 5 SD Communication
37/67
Steps for a RPC
The client procedure calls the client stub in the normal way
The client stub builds a message and calls the local operating system
The clients OS sends the message to the remote OS
The remote OS gives the message to the server stub
The server stub unpacks the parameters and calls the server
The server does the work and returns the result to the stub
The server stub packs it in a message and calls its local OS
The servers OS sends the message to the clients OS
The clients OS gives the message to the client stub
The stub unpacks the result and returns to the client
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 27 / 42
Remote Procedure Call
Steps for a RPC
http://find/7/28/2019 5 SD Communication
38/67
Steps for a RPC
The client procedure calls the client stub in the normal way
The client stub builds a message and calls the local operating system
The clients OS sends the message to the remote OS
The remote OS gives the message to the server stub
The server stub unpacks the parameters and calls the server
The server does the work and returns the result to the stub
The server stub packs it in a message and calls its local OS
The servers OS sends the message to the clients OS
The clients OS gives the message to the client stub
The stub unpacks the result and returns to the client
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 27 / 42
Remote Procedure Call
Steps for a RPC
http://find/7/28/2019 5 SD Communication
39/67
Steps for a RPC
The client procedure calls the client stub in the normal way
The client stub builds a message and calls the local operating system
The clients OS sends the message to the remote OS
The remote OS gives the message to the server stub
The server stub unpacks the parameters and calls the server
The server does the work and returns the result to the stub
The server stub packs it in a message and calls its local OS
The servers OS sends the message to the clients OS
The clients OS gives the message to the client stub
The stub unpacks the result and returns to the client
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 27 / 42
Remote Procedure Call
Steps for a RPC
http://find/7/28/2019 5 SD Communication
40/67
Steps for a RPC
The client procedure calls the client stub in the normal way
The client stub builds a message and calls the local operating system
The clients OS sends the message to the remote OS
The remote OS gives the message to the server stub
The server stub unpacks the parameters and calls the server
The server does the work and returns the result to the stub
The server stub packs it in a message and calls its local OS
The servers OS sends the message to the clients OS
The clients OS gives the message to the client stub
The stub unpacks the result and returns to the client
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 27 / 42
Remote Procedure Call
Steps for a RPC
http://find/7/28/2019 5 SD Communication
41/67
Steps for a RPC
The client procedure calls the client stub in the normal way
The client stub builds a message and calls the local operating system
The clients OS sends the message to the remote OS
The remote OS gives the message to the server stub
The server stub unpacks the parameters and calls the server
The server does the work and returns the result to the stub
The server stub packs it in a message and calls its local OS
The servers OS sends the message to the clients OS
The clients OS gives the message to the client stub
The stub unpacks the result and returns to the client
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 27 / 42
Remote Procedure Call
Steps for a RPC
http://find/7/28/2019 5 SD Communication
42/67
Steps for a RPC
The client procedure calls the client stub in the normal way
The client stub builds a message and calls the local operating system
The clients OS sends the message to the remote OS
The remote OS gives the message to the server stub
The server stub unpacks the parameters and calls the server
The server does the work and returns the result to the stub
The server stub packs it in a message and calls its local OS
The servers OS sends the message to the clients OS
The clients OS gives the message to the client stub
The stub unpacks the result and returns to the client
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 27 / 42
Remote Procedure Call
Steps for a RPC
http://find/http://goback/7/28/2019 5 SD Communication
43/67
Steps for a RPC
The client procedure calls the client stub in the normal way
The client stub builds a message and calls the local operating system
The clients OS sends the message to the remote OS
The remote OS gives the message to the server stub
The server stub unpacks the parameters and calls the server
The server does the work and returns the result to the stub
The server stub packs it in a message and calls its local OS
The servers OS sends the message to the clients OS
The clients OS gives the message to the client stub
The stub unpacks the result and returns to the client
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 27 / 42
Remote Procedure Call
Steps for a RPC
http://goforward/http://find/http://goback/7/28/2019 5 SD Communication
44/67
S p
The client procedure calls the client stub in the normal way
The client stub builds a message and calls the local operating system
The clients OS sends the message to the remote OS
The remote OS gives the message to the server stub
The server stub unpacks the parameters and calls the server
The server does the work and returns the result to the stub
The server stub packs it in a message and calls its local OS
The servers OS sends the message to the clients OS
The clients OS gives the message to the client stub
The stub unpacks the result and returns to the client
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 27 / 42
Remote Procedure Call
Steps for a RPC
http://find/7/28/2019 5 SD Communication
45/67
p
The client procedure calls the client stub in the normal way
The client stub builds a message and calls the local operating system
The clients OS sends the message to the remote OS
The remote OS gives the message to the server stub
The server stub unpacks the parameters and calls the server
The server does the work and returns the result to the stub
The server stub packs it in a message and calls its local OS
The servers OS sends the message to the clients OS
The clients OS gives the message to the client stub
The stub unpacks the result and returns to the client
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 27 / 42
Remote Procedure Call
Steps for a RPC
http://find/http://goback/7/28/2019 5 SD Communication
46/67
p
The client procedure calls the client stub in the normal wayThe client stub builds a message and calls the local operating system
The clients OS sends the message to the remote OS
The remote OS gives the message to the server stub
The server stub unpacks the parameters and calls the server
The server does the work and returns the result to the stub
The server stub packs it in a message and calls its local OS
The servers OS sends the message to the clients OS
The clients OS gives the message to the client stub
The stub unpacks the result and returns to the client
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 27 / 42
Remote Procedure Call
Parameter Passing
http://find/7/28/2019 5 SD Communication
47/67
g
Passing value parameters
Parameters are marshalled to pass across the network
Procedure calls are sent to the client stub and transmitted to theserver stub through the network to the called procedure
Steps of a remote computation through a RPC[Tanenbaum and van Steen, 2007]
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 28 / 42
Remote Procedure Call
Issues in Parameter Passing
http://find/7/28/2019 5 SD Communication
48/67
Passing value parameters
Problems of representation and meaningE.g., little endian vs. big endianIn order to ensure transparency, stubs should be in charge of the mapping & translationPossible approach: interfaces described through and IDL (Interface DefinitionLanguage), and consequent handling compiled into the stubs
Passing reference parametersMain problem: reference space is localFirst solution: forbidding reference parametersSecond solution: copying parameters (suitably updating the reference), then copyingthem back (according to the original reference)
Call-by-reference becomes copy&restore
Third solution: creating a global/accessible reference to the caller space from the callee
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 29 / 42
Remote Procedure Call
Issues in Parameter Passing
http://find/7/28/2019 5 SD Communication
49/67
Passing value parameters
Problems of representation and meaningE.g., little endian vs. big endianIn order to ensure transparency, stubs should be in charge of the mapping & translationPossible approach: interfaces described through and IDL (Interface DefinitionLanguage), and consequent handling compiled into the stubs
Passing reference parametersMain problem: reference space is localFirst solution: forbidding reference parametersSecond solution: copying parameters (suitably updating the reference), then copyingthem back (according to the original reference)
Call-by-reference becomes copy&restore
Third solution: creating a global/accessible reference to the caller space from the callee
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 29 / 42
Remote Procedure Call
Asynchronous RPC
http://goforward/http://find/http://goback/7/28/2019 5 SD Communication
50/67
Synchronicity might be a problem in distributed systems
Synchronicity is often unnecessary, and may create problems
Asynchronous RPC is an available alternative in many situations
Traditional RPC Asynchronous RPC
[Tanenbaum and van Steen, 2007]
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 30 / 42
Remote Procedure Call
Deferred Synchronous RPC
http://find/7/28/2019 5 SD Communication
51/67
Combining asynchronous RPCs
Sometimes some synchronicity is required, but too much is too much Deferred Synchronous RPC combines two asynchronous RPC to
provide an ad hoc form of synchronicity
The first asynchronous call selects the procedure to be executed andprovides for the parameters
The second asynchronous call goes for the results
In between, the caller may keep on computing
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 31 / 42
Remote Procedure Call
Limits of RPC
http://find/7/28/2019 5 SD Communication
52/67
Coupling in timeCo-existence in time is a requirement for any RPC mechanism
Sometimes, a too-hard requirement for effective communication indistributed systems
An alternative is required that does not require the receiver to beexecuting when the message is sent
The alternative: messaging
Please notice: message-oriented communication is not synonym ofuncoupling
However, we can take this road toward uncoupled communication
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 32 / 42
Remote Procedure Call
Limits of RPC
http://find/7/28/2019 5 SD Communication
53/67
Coupling in timeCo-existence in time is a requirement for any RPC mechanism
Sometimes, a too-hard requirement for effective communication indistributed systems
An alternative is required that does not require the receiver to beexecuting when the message is sent
The alternative: messaging
Please notice: message-oriented communication is not synonym ofuncoupling
However, we can take this road toward uncoupled communication
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 32 / 42
Message-oriented Communication
Outline
http://find/7/28/2019 5 SD Communication
54/67
1 Interaction & Communication
2 FundamentalsLayers & Protocols
Types of Communication
3 Remote Procedure Call
4 Message-oriented CommunicationStream-oriented Communication
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 33 / 42
Message-oriented Communication
Message-oriented Transient Communication
http://find/7/28/2019 5 SD Communication
55/67
Basic ideaMessages are sent through a channel abstraction
The channel connects two running processes
Time coupling between sender and receiver
Transmission time is measured in terms of milliseconds, typically
Examples
Berkeley Sockets typical in TCP/IP-based networks
MPI (Message-Passing Interface) typical in high-speedinterconnection networks among parallel processes
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 34 / 42
Message-oriented Communication
Message-oriented Transient Communication
http://find/7/28/2019 5 SD Communication
56/67
Basic ideaMessages are sent through a channel abstraction
The channel connects two running processes
Time coupling between sender and receiver
Transmission time is measured in terms of milliseconds, typically
Examples
Berkeley Sockets typical in TCP/IP-based networks
MPI (Message-Passing Interface) typical in high-speedinterconnection networks among parallel processes
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 34 / 42
Message-oriented Communication
Message-Oriented Persistent Communication
http://find/7/28/2019 5 SD Communication
57/67
Message-queuing systems a.k.a. Message-Oriented Middleware (MOM)
Basic idea: MOM provides message storage serviceA message is put in a queue by the sender, and delivered to adestination queueThe target(s) can retrieve their messages from the queueTime uncoupling between sender and receiverExample: IBMs WebSphere
General architecture of a message-queuing system[Tanenbaum and van Steen, 2007]
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 35 / 42
Message-oriented Communication Stream-oriented Communication
Outline
http://find/7/28/2019 5 SD Communication
58/67
1 Interaction & Communication
2 FundamentalsLayers & Protocols
Types of Communication
3 Remote Procedure Call
4 Message-oriented CommunicationStream-oriented Communication
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 36 / 42
Message-oriented Communication Stream-oriented Communication
Streams
http://goforward/http://find/http://goback/7/28/2019 5 SD Communication
59/67
Sequences of data
A stream is transmitted by sending sequences of related messages
Single vs. complex streams: a single sequence vs. several related
simple streams
Data streams: typically, streams are used to represent and transmithuge amounts of data
Examples: JPEG images, MPEG movies
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 37 / 42
Message-oriented Communication Stream-oriented Communication
Streams & Time
http://find/7/28/2019 5 SD Communication
60/67
Continuous vs. discrete media
In the case of continuous (representation) media, time is relevant tounderstand the data e.g., audio streamsIn the case of discrete (representation) media, time is not relevant tounderstand the data e.g., still images
Transmission of time-dependent informationAsynchronous transmission mode data items of a stream are transmitted
in sequence without further constraintse.g., a filerepresenting a still image
Synchronous transmission mode data items of a stream are transmitted in
sequence with a maximum end-to-end delaye.g., datageneration by a pro-active sensor
Isochronous transmission mode data items of a stream are transmitted insequence with both a maximum and a minimum end-to-enddelaye.g., audio & video
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 38 / 42
Message-oriented Communication Stream-oriented Communication
Streams & Time
http://find/http://goback/7/28/2019 5 SD Communication
61/67
Continuous vs. discrete media
In the case of continuous (representation) media, time is relevant tounderstand the data e.g., audio streamsIn the case of discrete (representation) media, time is not relevant tounderstand the data e.g., still images
Transmission of time-dependent informationAsynchronous transmission mode data items of a stream are transmitted
in sequence without further constraintse.g., a filerepresenting a still image
Synchronous transmission mode data items of a stream are transmitted in
sequence with a maximum end-to-end delaye.g., datageneration by a pro-active sensorIsochronous transmission mode data items of a stream are transmitted in
sequence with both a maximum and a minimum end-to-enddelaye.g., audio & video
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 38 / 42
Message-oriented Communication Stream-oriented Communication
Streams & Quality of Service
http://find/7/28/2019 5 SD Communication
62/67
Quality of service
Timing and other non-functional properties are typically expressed asQuality of Service (QoS) requirementsIn the case of streams, QoS typically concerns timing, volume, andreliabilityIn the case of middleware, the issue is how can a given middleware
ensure QoS to distributed applications
A practical problem
Whatever the theory, many distributed systems providing streaming
services rely on top of the IP stackIP specification allow for a protocol implementation dropping packetswhen neededQoS should be enforced at the higher levels
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 39 / 42
Message-oriented Communication Stream-oriented Communication
Streams & Quality of Service
http://find/7/28/2019 5 SD Communication
63/67
Quality of service
Timing and other non-functional properties are typically expressed asQuality of Service (QoS) requirementsIn the case of streams, QoS typically concerns timing, volume, andreliabilityIn the case of middleware, the issue is how can a given middleware
ensure QoS to distributed applications
A practical problem
Whatever the theory, many distributed systems providing streaming
services rely on top of the IP stackIP specification allow for a protocol implementation dropping packetswhen neededQoS should be enforced at the higher levels
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 39 / 42
Conclusions
Summing Up
http://find/7/28/2019 5 SD Communication
64/67
Interaction & communicationInteraction as an orthogonal dimension w.r.t. computation
Communication as a form of interaction
High-level abstractions for process-level communicationRemote Procedure Call
Message-oriented models
Streaming
Other forms like multicasting and epidemic protocols are important,but are not a subject for this course
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 40 / 42
Conclusions
Summing Up
http://find/7/28/2019 5 SD Communication
65/67
Interaction & communicationInteraction as an orthogonal dimension w.r.t. computation
Communication as a form of interaction
High-level abstractions for process-level communicationRemote Procedure Call
Message-oriented models
Streaming
Other forms like multicasting and epidemic protocols are important,but are not a subject for this course
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 40 / 42
References
References I
http://find/7/28/2019 5 SD Communication
66/67
Tanenbaum, A. S. and van Steen, M. (2007).
Distributed Systems. Principles and Paradigms.Pearson Prentice Hall, Upper Saddle River, NJ, USA, 2nd edition.
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 41 / 42
http://goforward/http://find/http://goback/7/28/2019 5 SD Communication
67/67
Communication in Distributed SystemsDistributed SystemsSistemi Distribuiti
Andrea [email protected]
Dipartimento di Informatica Scienza e Ingegneria (DISI)Alma Mater Studiorum Universita di Bologna a Cesena
Academic Year 2012/2013
Andrea Omicini (DISI, Univ. Bologna) 5 Communication A.Y. 2012/2013 42 / 42
http://find/