Reliable Multicast pattern

From COMMDP
Jump to: navigation, search 
First: Request-Reply pattern | Return to ACP Patterns

This pattern first appeared in the paper "A Pattern Language for Application-level Communication Protocols"[1] published at IARA-ICSEA 2016 by Jorge Edison Lascano and Stephen Wright Clyde (authors of the page).

Reliable Multicast pattern

Name and Descrption

Reliable Multicast (RMC)

The RMC pattern is widely used in multicast or broadcast communication systems, where the request of processing is delegated to n Resource managers (RM), where n>1, and the execution needs to be synchronized in the n RMs. It may need a simultaneous processing of the request in every responder. Instances of this pattern can be found in bank transactions, parallel computing, etc.

Intent

The Reliable Multicast pattern builds on the multicast idiom to provide reliability and synchronization among a group of processes. Its solution is a protocol that starts with a process A sending a request message to a group of process, B = { b1, .., bn }. Each process bi sends a reply back to A when it receives the request and is ready to process it. After A receives reply from all B processes, then A will multicast a go-ahead message back out to all B message indicating that they can proceed with the processing of the request. In this way, the execution of the request is synchronized among all of the B processes. If A fails to receive a reply from every B process, it can resend the request to some or all of them until it gets a reply from all of them or terminates the conversation as failed. This pattern focuses on providing strong reliability and synchronization, but can also help with scalable distribution of resources.

Description

Problem

A client needs to access resources provided by one or more resource managers. And the resource managers have to process the request all at-once, in a transaction fashion-way.

Context

There is need of synchronized execution of a set of requests sent by only one initiator and several responders.

Solution

The client initiates the conversation by sending n requests to n resource managers, which receive the request, but don't process it immediately. Every resource manager sends back an acknowledgement telling the initiator that they received teh request and are ready to process it. The initiator will send a "go-ahead" message to every RM after it has received the n acknowledge messages.

One variation of RMC would be its combination with RRA after processing the request in every RM.

Process Roles

Initiator, Responder1, Responder2, ... , Respondern

Messages

Request, Ack1, Ack2, ... , Ackn, go ahead

Scenario

(A gets a list of Responders)
Initiator -> |Request| -> {Responder1, Responder2,  ... , Respondern}
Responder1 -> |Ack1| -> Initiator
Responder2 -> |Ack2| -> Initiator
...
Respondern -> |Ackn| -> Initiator
Initiator -> |go ahead| -> {Responder1, Responder2,  ... , Respondern}
(Responder1 processes |Request|)
(Responder2 processes |Request|)
...
(Respondern processes |Request|)

Semantics and Behavior

  • After the initiator sends the Request to n-Responders, it waits for the acknowledgement of every Responder, up to x time units (the timeout).
  • Responders wait for "go ahead" message from Initiator before start processing the Request.
  • The Initiator has a timeout/retry behavior on the Acks.
  • When it receives the n-Acks, it sends the "go ahead" signal to the n-Responders
  • Initiator considers the conversation successfully completed

Consequences

A sends a request to multiple responders, this request is processed in all the responders synchronously with a good level of reliability.

Consequences
Quality Rating Justification
Reliability
3
 This pattern qualifies under high-level of reliability. It fulfills three out of four criteria qualifications as elaborated with example below:
  1. The sender can distinguish a failed conversation. for example, JGroup uses a NAK to identify failure or undelivered messages.
  2. Receiver can also distinguish a failed conversation. for exaple, in JGroup, the member can also distinguish a failed conversation when it receives a NAK from JGroup
  3. It partially fulfills timely assurance i.e., only for the sender. for example, in JGroup, the member gives a timely assurance to the JGroup that it has received the message
  4. This pattern doesn’t provide sufficient information for (d)
Synchronicity
3
 This pattern ensures strong synchronization and ordered delivery of messages, initiator and responders coordinate the processing of the request.
Longevity
1
 This pattern does not directly address longevity
Adaptability for Scalable Distribution
2
 This pattern only addresses location transparency(a). i.e. changing the location of the RMs doesn’t affect the overall picture of reliable multicast.

Known uses

  • Multicast communication
  • Conference Groups
  • News feeds
  • Message distribution
  • Wireless communications
  • Digital-TV, for content protection, i.e. paying users
  • ads
  • software updates
  • software deployment

Aliases and Related Patterns

None

Related work

  • Multicast Protocol.[2]

Examples of Application

JGroup communication uses the term group and member. Member is a node and group is a cluster. A node is a process, residing on some host. A cluster can have one or more nodes belonging to it. Nodes can run on different hosts. [3]. JGroup has three parts:

  • Channel: They are simple and primitive and provide asynchronous message sending/reception, similar to UDP. It is connected to a protocol stack. Whenever the application sends a message, the channel passes it on to the protocol stack, which ultimately gets pushed on the network. Similarly the protocol stack receives the message and ultimately pushes it on to the channel.
  • Building blocks: (provides layers of abstraction between the channel and the application)
  • protocol stack: (implements the properties specified for a given channel)

JGroup achieves reliability by NAKACK, i.e., no message sent by a sender will ever be lost, as ACK messages are numbered with sequence numbers and retransmissions requests are sent to the sender if that sequence number is not received. Also FIFO(First-in-First-out), property ensures that all messages from a given sender are received in exactly the order in which they were sent. For example, when receiving P:1, P:3, P:4, a receiver delivers only P:1 and asks P for retransmission of message 2, queuing P3-4. When P2 is finally received, the receiver will deliver P2-4 to the application. [4]

JGroup Scenario

- In this reliable group communication, processes can join a group, send messages to all members or single members and receive messages from members in the group. A group is identified by its name. When a process joins a non-existing group, the group will be created automatically. The system keeps track of the members in every group and notifies group members when a new member joins, or an existing member leaves or crashes. 

First: Request-Reply pattern | Return to ACP Patterns

References

  1. ↑ Jorge Edison Lascano, Stephen Wright Clyde, A Pattern Language for Application-level Communication Protocols, in, Proceedings of The Eleventh International Conference on Software Engineering Advances ICSEA 2016, 2016, pp. 22-30
  2. ↑ S. Paul, “Reliable Multicast Protocol (RMP),” in Multicasting on the Internet and its Applications, Springer US, 1998, pp. 229–243.
  3. ↑ “Chapter 2. Architecture.” [Online]. Available: https://docs.jboss.org/hibernate/search/4.1/reference/en-US/html/search-architecture.html. [Accessed: 20-Feb-2017].
  4. ↑ “Reliable Multicasting with the JGroups Toolkit.” [Online]. Available: http://www.jgroups.org/manual/html_single/. [Accessed: 20-Feb-2017].
Retrieved from "http://commdp.serv.usu.edu/wiki/index.php?title=Reliable_Multicast_pattern&oldid=548"