1. Message Passing Communication
2018/11/19
Message Passing Communication
Xuan Guo
Hi, I am Xuan Guo. I works with Prof. Pan. And my research area is Multiple Sequence Alignment.
And today I am going to give a presentation about message passing communication and how message passing communicate between application processes.
So lets move to the next slide.

2. Outline Overview Message Passing Communication
2018/11/19
Outline
Overview
Message Passing Communication
Basic Communication Primitives
Message synchronization and buffering
Pipe and socket APIs
Secure sockets
Group communication and multicast
Latest Relevant Research -- SOAP
Future Work
Reference
This is our outline.
As we can see, first we will talk about the overview of message passing.
Then I’ll introduce some basic knowledge concerning this communication technology. I divide this issue into five small parts.
After that I’ll give you a latest relevant research, that is SOAP, is the short for simple object access protocol.
And the rest parts is future work and reference.
OK.

3. Overview What is Message Passing Communication? Major issues
2018/11/19
Overview
What is Message Passing Communication?
A paradigm of communication where messages are sent from a sender to one or more recipients (Processes, Objects).
Message
Collection of typed data objects
Structures and interpretations are defined by peer applications
Major issues
Direct or indirect addressing
Blocking or non-blocking communication
Reliable or unreliable communication
Buffered or un-buffered communication
In this part we focused on the main concept of Message passing Communication and the main issues in this topic.
What is message passing communication. It is a paradigm of communication where messages are sent from a sender to one or more recipients. These senders and recipients can be processes or other objects.
The messages for communicating are collections of typed data objects, and their structures and interpretations are defined by peer applications.
Facing the need of processes communications, we need to address four issues. They are whether the communication is direct or indirect, blocking or non-blocking, reliable or unreliable, and buffered or un-buffered.

4. Basic Communication Primitives
2018/11/19
Basic Communication Primitives
Communication primitives:
send(destination, message)
receive(source, message)
channel naming = process name, link, mailbox, port
Direct communication: symmetric/asymmetric process naming, link
Indirect communication: many-to-many mailbox, many-to-one port
We use the following two generic message passing primitives as examples for sending and receiving messages.
In these two primitives, they both include message body. Well in the send primitives, the communication entity is destination, and in the other one is source.
We have four commonly used options to address communication entities, they are processes name, link, mailbox and port.
In a real implementation, process name, or global process identifier can be made unique by concatenating network host address with the locally generated process id.
This scheme implies that only one direct logical communication path exits between any pair of sending and receiving processes.
As shown in next slide’s left figure.
The addressing scheme is also refereed to as symmetric addressing, since the corresponding sending and receiving processes must explicitly name each other.
For the receiving process, it is not necessary to know sources. Then the addressing between sender and the receiver becomes asymmetric. As shown in next slide’s middle figure.
To allow for multiple data paths between processes and direct communication, we can use connections or links. There are similar to the virtual circuit.
In this slide’s right figure shows the possibility of maintaining two links between processes using two different link numbers.
Using processes name and links for addressing communication points provides direct communication between peer processes.
However, sometimes indirect communication is preferred.
Here are two indirect communications: mailbox and port.
Since receiving processes are interested only in the message itself, like multiple clients might request services from one of multiple servers, we can solve it by using shared mailbox, as a common situation in our daily life.
This scenario is illustrated in the left figure.
Ok. A port is an abstraction of a finite-size first-in-first-out quene maintained by the kernel. We can think of a port as a special example of a mailbox. Ports are similar to links except that they are bidirectional and buffered.

5. Direct Send/Receive Communication Primitives
2018/11/19
Direct Send/Receive Communication Primitives
Symmetric
Process Name
Asymmetric
Process Name
Links

6. Indirect Send/Receive Communication Primitives
2018/11/19
Indirect Send/Receive Communication Primitives
mailbox
mailbox
Multipath
Communication
Multipoint
Communication

7. Message Synchronization and Buffering
2018/11/19
Message Synchronization and Buffering
Message Synchronization Stages
Source
Kernel
Destination Kernel
Sender
Network
Receiver 1 2
message 3 4 8 7
ack 6 5
Non-blocking send: 1+8 (Asynchronous send)
Blocking send: (Synchronous send)
Reliable blocking send: (Synchronous send)
Explicit blocking send: (Synchronous send)
Request and reply: `1-4, service, 5-8 (Synchronous send) (Client/Server)
In this slide, we give message synchronization and buffering strategy.
This figure shows different stages of message transfer in the system.
When sending a message to a remote destination, the message is passed to the sender’s system kernel, which transmits it to the communication network.
Most systems allow usually a blocking or non-blocking send and receive primitives. The common default is usually a non-blocking send and a blocking receive. This because it is convenient to assume that message delivery is reliable can that the sender process can continue its useful work.
A following list shows five different options for the send primitive according to the stages.
The first option is referred to as an asynchronous send, while the others are considered synchronous sends. The last one is explicitly called client and server communication. With the asynchronous send, a sender process is blocked if its kernel is not ready to accept the message, perhaps due to lack of buffer space. However, this is a minimum requirement since it is dangerous for the sender to continue working before its kernel assumes control of the message.
Ok, we are going to next issue.

8. 2018/11/19
Message passing API
Pipe: A FIFO byte-stream unidirectional link for related processes (set up at process invocation)
Socket: A logical communication endpoint for communication between autonomous domains (bound to physical communication endpoint)
Ls –l | sort …
write
read
FIFO pipe
As we have seen in the previous discussion, there is a large variety of message passing communication primitives with different concepts and assumptions. It is more convenient to the users and effective to the system if communication is achieved through a well defined set of standard application program interfaces. That is APIs.
The pipe and socket are two interprocess communication APIs that are widely used in both the Unix and Windows environment.
Pipes are implemented with a finite-size, FIFO byte-stream buffer maintained by the kernel. A pipe is created by a pipe system call.
In the middle figure, it is a simple pipe structure.
A socket is a communication endpoint of a communication link managed by the transport services.

9. 2018/11/19
Socket
A Socket is a communication end point of a communication link managed by the transport services.
A socket is created by making a socket system call.
The socket system call is also used to specify various network protocols such as Internet TCP, UDP and IP.

10. Connectionless socket communication
2018/11/19
Peer processes
Peer processes
socket
socket
Logical communication endpoint(socket, LCD)
Logical communication endpoint(socket, LCD)
bind
bind
Physical communication endpoint (PCE)
Physical communication endpoint (PCE)
In this figure, it shows an example of a connectionless peer communication using socket, bind and sendto/recvfrom socket calls.
Since the communication is connectionless, each sendto/recvfrom call must contain the local socket descirptor and the remote physical communication endpoint.
In connectionless socket communication each peer process must know its remote physical communication endpoint. The explicit naming of the remote physical communication endpoint in the send/receive calls can be eliminated if a connect socket call is performed before data transfer begin. After the connect operation, data transfer may simply use send/receive or write/read without specifying the remote PCE.
OK, this is the connectionless socket communication
Send/recvfrom
Connectionless socket communication

11. Connection oriented client/server socket communication
2018/11/19
The next slide illustrates a connection-oriented client/server socket communication.
In the Unix implementation, the listen socket call is used to indicate that the server is willing to accept a connection and specifies how many pending requests can be queued.
The accept calls rendezvous with connect calls accumulated in the listen queue.
An accept call blocks if there is no pending connect.
Otherwise it removes a connection request from the queue and returns a new socket descriptor, which is used for communication with the connected client.
Connection oriented client/server socket communication

12. Secure Socket(I) The goal of Secure socket layer (SSL) is to provide:
2018/11/19
Secure Socket(I)
The goal of Secure socket layer (SSL) is to provide:
Privacy in socket communication by using symmetric cryptographic data encryption.
Integrity in socket data by using message integrity check.
Authenticity of servers and clients by using asymmetric public key cryptography
Sockets have become most popular message passing API.
Due to the widespread use of windows applications, a standard windows socket has been developed by the Winsock Standard Group.
Most recent version of the Windows Socket which is developed by WinSock Standard Group also includes a SSL (Secure Socket Layer) in the specification.

13. 2018/11/19
Secure Socket(II)
The heart of the SSL consists of two protocol layers. One is Handshake protocol, the other is a Record Layer protocol.
The Handshake protocol is responsible for establishing the write keys and MAC secret for validating the authenticity of clients and servers. This slide’s figure shows a simple scenario of the SSL Handshake protocol.
The Record Layer protocol is responsible for fragmentation, compression decompression, and encryption decryption of message records.

14. Group Communication & Multicast(I)
2018/11/19
Group Communication & Multicast(I)
Group: a collection of processes that act together
When a message is sent to a group, all its members receive the message
Group are dynamic
Create/destroy groups  group management
A process can join or leave a group  membership management
The communication models for message passing discussed are all examples of p2p communication. However, there is also group communications.

15. Group Communication & Multicast(II)
2018/11/19
Group Communication & Multicast(II)
Best-effort Multicast: The system needs only to guarantee the delivery of the multicast message to the reachable non-faulty processes.
Reliable Multicast: The multicast message should either be received by all of the servers or none of them.
Generically, there are two types of multicast application scenarios. The first is when a client wants to solicit a service from any server who can perform the service. The second is when a client needs to request a service from all members of a group of serves.
In the former cases, we use the best-effort multicast. That is…
It is not necessary for all servers to respond as long as at least one does.
In the latter case, we use the reliable multicast.

16. Multicast orders(I) s 2 1 G 1 s G 2 s G 1 s s 1 G G 2 G s G 2 1 s s 1
2018/11/19
Multicast orders(I) s 2 1 G 1 s G 2 s G 1 s s 1 G G 2 G s G 2
One problem in the reliable delivery issue is message delivery ordering.
When multiple messages are multicast to the same group, they may arrive at different members of the group in a different order.
This figure shows several group communication examples that require message ordering.
G represents group.
S represents sources.
Process s may be outside of the group or a member in the group. 1 s s 1 1 G 1 2 G s G 2 2 s 2

17. 2018/11/19
Multicast orders(II)
FIFO order: Multicast messages from a single source are delivered in the order that they were sent.
Causal order: Causally related messages from multiple sources are delivered in their causal order.
Total order: all messages multicast to a group are delivered to all members of group in the same order. A reliable and total order multicast is called an atomic multicast.
Here lists three multicast orderings. Their strictness are increasing.
First is FIFO order. Multicast messages from a single source are delivered in the order that they were sent.
Second is Causal order. Causally related messages from multiple sources are delivered in their causal order.
The last is Total order. All messages multicast to a group are delivered to all members of group in the same order. A reliable and total order multicast is called an atomic multicast.

18. Latest Relevant Research -- SOAP
2018/11/19
Latest Relevant Research -- SOAP
The Simple Object Access Protocol (SOAP) is an XML based protocol that is widely used over the Internet as it supports interoperability by establishing access among Web servers and clients from the same or different platforms.
SOAP was designed to be a simple message passing protocol.
It will not solve every problem.
Later, I discuss all of the strengths and weakness of SOAP and future plans for the protocol.

19. 2018/11/19
SOAP structure

20. SOAP message exchanges are quite elaborate;
2018/11/19
SOAP message exchanges are quite elaborate;
Packet Sizes
Latency
This problem has been investigated on two levels:
i) SOAP compression, to reduce message size prior to transmission;
ii) SOAP multicasting, to optimize SOAP network traffic.
the client program has to build the skeleton of the XML message, put the right values in it, and then send it to the remote service. In turn, the service parses the message, digging out the data it needs, and then goes through the same procedure to generate an XML reply. No wonder, then, that SOAP message processing produces considerable network traffic and causes high latency.

21. 2018/11/19
2011: Tekli, Joe; Damiani, Ernesto; Chbeir, Richard; , "Differential SOAP Multicasting,“
The proposed method is based on the well known concept of Tree Edit Distance to reduce similar part in SOAP message.
In addition, this technique exploits a dedicated differencing output format specifically designed to carry the minimum amount of diff-information.
There are several papers focus on this issue. They are main idea is differential SOAP multicasting.
One method has listed below.
First, Encoding the differences between SOAP messages to be multicast, including only their distinctive parts, so as to minimize aggregate message size, and thus network traffic.
The proposed method is based on the well known concept of Tree Edit Distance, built upon a novel filter-differencing architecture to reduce message aggregation time, identifying only those messages which are relevant for similarity evaluation.
In addition, this technique exploits a dedicated differencing output format specifically designed to carry the minimum amount of diff-information, in the multicast message, so as to minimize the multicast message size, and therefore reducing the network traffic.

22. 2018/11/19
Future Work
Future work will involve in researching better heuristic algorithms to further improve performance of building similarity based SOAP multicast tree.
SOAP Message Security Validation

23. 2018/11/19
References
Phan K.A. et al., Similarity-Based SOAP Multicast Protocol to Reduce Bandwidth and Latency in Web Services. IEEE TSC, 2008, 1:2(88-103)
Tekli, Joe; Damiani, Ernesto; Chbeir, Richard; , "Differential SOAP Multicasting," Web Services (ICWS), 2011 IEEE International Conference on , vol., no., pp.1-8, 4-9 July 2011
Werner C. et al., WSDL-Driven SOAP Compression. J. of WS Research, (1):18-35.
Phan K.A. et al., Minimal Traffic-Constrained Similarity-Based SOAP Multicast Routing Protocol. OTM Confederated Inter. Conf., LNCS, pp
"SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)". W3C. April 27, Retrieved

24. 2018/11/19
Thanks & Question?