Request-Reply with Acknowledge pattern

From COMMDP
Jump to: navigation, search
Next: Intermediate State Message 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).

Request-Reply with Acknowledge

Name and Overview

Request-Reply with Acknowledge (RRA)

The RRA pattern is a protocol design pattern specially concerned with implementations of "at most once" semantic [2], where the server stores (caches) its reply data in case of a duplicate request, in order to save processing time for a faster response. Eventually after receiving the acknowledgment, the server disposes of the temporal data, and terminates the conversation. A as much as B are well informed about each other state. At most once semantics, assures that the server executes the request at most once, even when A sends duplicated requests [3].

Intent

The Request-Reply-Acknowledge pattern extends this solution with a third message (an acknowledgement) that A sends to B after receiving the reply, and gives B a timeout/retry behavior with respect to its sending of the reply and waiting for an acknowledgement. This pattern is useful in situations were significant processing may occur on A after receiving the reply or when it is problematic for B to reprocess duplicated requests caused by A’s timeout/retry behavior. With this pattern, instead of reprocessing a duplicate requests, B can simply cache its replies and resends them to A when necessary. The acknowledgement tells B that A has received the reply and, thus, can remove it from its cache. This pattern offers more reliability and synchronization than request-reply, but at the cost of an additional message.

Description

Problem

A client needs to access a shared resource (e.g, a service) provided by resource manager, with a high degree of reliability.

Context

“at most once” semantics needed for the execution of the requested service, i.e. the responder saves the previous requests, in case of duplicate requests, it replies back without need of processing. Also the server saves all requests. Once the server receives the acknowledgement, it can safely discard that information.[2]

Solution

The client initiates the conversation by sending a request to the resource manager, which receives the request, processes it, and sends by a reply. The client has a timeout/retry behavior while waiting for the reply. When it gets the reply, it sends back an acknowledgement (message has been received) to the Responder. The Responder has timeout/retry behavior while waiting for the acknowledgement. Additionally,the server may cache its reply processed data.

Process Roles

Initiator, Responder

In a client-server architecture and in many distributed systems, in general, the client is a conversation initiator and The resource manager is a responder

Messages

Request, Reply, Acknowledgement (Ack)

Scenario

Initiator -> |Request| -> Responder
(Responder processes the Request)
Responder -> |Reply| -> Initiator
Initiator -> |Ack| -> Responder

Semantics and Behavior

  • The Initiator has a timeout/retry behavior on the Reply.
  • The Responder may save the Request to save processing time in case of a duplicate request
  • When the Initiator receives a Reply, it sends back an Ack and considers the conversation successfully completed.
  • The Responder has a timeout/retry behavior on the Ack.
  • When it receives the Ack, it considers the conversation successfully completed and removes the previous request.

Consequences

One message is sent from A to B with a high level of reliability and synchronicity allowing "at most once semantics" implementations, i.e. B knows that its Reply was received and can removed its temporal (cached) processed reply from its memory.

Consequences
Quality Rating Justification
Reliability
3
This pattern can provide a high level of reliability. Specially when B receives an assurance message (acknowledgement) that tells both processes that the communication was properly managed. i.e. B as much as A has sent and received their correspondent messages. It adds one level of reliability to the RR pattern, which only controls its reliability by the reception of the reply message. In this case, RRA pattern, reliability is concerned with both, initiator and responder processes and reliability is handled through the reply and acknowledgement messages respectively. Complying with the at-most-once semantic [2]
Synchronicity
3
This pattern provides a high level of synchronization. In addition to the synchronization provided by RR, it tells B whether its reply has been received or not. A and B coordinate the end of the communication by mutual agreement. No resent or persistent data is needed, and the timeout period expires.
Longevity
1
This pattern is not directly concerned with long conversations, but could be combined with patterns that do address this quality
Adaptability for Scalable Distribution
1
This pattern does not directly address scalable distribution, but could be combined with patterns that do allow for scalable distribution

Known uses

  • Reliable communications
  • Secure communications.
  • Connection-oriented communications such as the establishment of an HTTPS communication.
  • Communications that may need re-transmistions.
  • One way and two way communications
  • Synchronous calls
  • Designing Remote Procedure Calls applications,
  • Basic pattern to be reused in other communication patterns that need a good level of reliability.
  • Stateless servers.

Aliases and Related Work

Aliases

  • Request-Reply with Piggy-Backed Acknowledgements. Implemented in The Constrained Application Protocol -CoAP (RFC7252 [4]) for improving REST through TCP performance [5] [6].

RRA pattern is usually combined with idempotent retry to allow the "at-least-one" semantics[7] additional to the at-most-once semantic.

Related work

  • Modeling and Formal Verification of Communication Protocols for Remote Procedure Call [8]
  • Modeling and Verification of Some Communication Protocols [9]
  • Request-Reply-Acknowledge Protocols (section 20.6)[2]

Examples of Application

Instances of RRA occur when the server needs to know that its request was properly recieved by the client. One tipical example is the RPC protocol over UDP [7], where the RCP application must implement its own acknowledgement protocol, which is usually the reply from the client to the server saying that the request was properly received. This is used specifically to implement the "at most once and exactly once semantics", so when the resource manager receives its acknowledge, it can discard its cached information. A variation of this protocol can be found on Network File Sharing write() operations [7], where an acknowledge can be included in the reply message, to tell the client that the data was received and processed.

RPC over UDP Scenario

- The client sends a request to the server, in the reply, the server can attach the ACK request, then the client sends another ack. A timeout period of 0.5 to 1.0 seconds could be useful in these cases [7].

Next: Intermediate State Message 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. 2.0 2.1 2.2 2.3 K. A. Robbins and S. Robbins, UNIX Systems Programming: Communication, Concurrency, and Threads. Prentice Hall Professional, 2003.
  3. “Semantics.” [Online]. Available: http://www.cs.unc.edu/~dewan/242/s04/notes/ipc/node30.html. [Accessed: 07-Mar-2017]
  4. Z. Shelby, K. Huartke, and C. Bormann, “The Constrained Application Protocol (CoAP).” [Online]. Available: https://tools.ietf.org/html/rfc7252. [Accessed: 17-Feb-2017].
  5. https://www.safaribooksonline.com/library/view/http-the-definitive/1565925092/ch04s02.html
  6. D. Gourley, B. Totty, M. Sayer, A. Aggarwal, and S. Reddy, HTTP: The Definitive Guide: The Definitive Guide. O’Reilly Media, Inc., 2002. pp. 80
  7. 7.0 7.1 7.2 7.3 “11   UDP Transport — An Introduction to Computer Networks, edition 1.9.0.” [Online]. Available: http://intronetworks.cs.luc.edu/current/html/udp.html. [Accessed: 21-Feb-2017].
  8. N. Halder, A. T. Islam, and J. B. Song, “Modeling and Formal Verification of Communication Protocols for Remote Procedure Call,” IJCSNS, vol. 7, no. 7, p. 63, 2007.
  9. K. H. Talukder and K. Harada, “Modeling and verification of some communication protocols,” in 2006 8th International Conference Advanced Communication Technology, 2006, vol. 3, p. 6 pp.-2198.