Communication-protocol Design Patterns (CommDP)

Revision as of 12:54, 29 June 2017 by Elascano (Talk | contribs) (Template for Communication-Protocol Patterns)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

CommDP is a pattern language for the design of application-level communication protocols. Like other pattern languages, it aims to capture proven solutions to re-occurring problems. However, unlike software design pattern languages, CommDP focuses on the communication protocols and not the code that implements those protocols.

The on-going enrichment and evolution of CommDP is a community effort. Collaborators are welcome. Many the original concepts were published in the paper, titled "A Pattern Language for Application-level Communication Protocols"[1] at IARA-ICSEA 2016 by Jorge Edison Lascano (PhD candidate at Utah State University) and Dr. Stephen Wright Clyde. Contributions have also been made by Dr. Ali Raza.


Communication-protocol Design Patterns (CommDP) capture proven solutions to recurring design problems for application-level communications. As with all software design patterns, the problem solved by a CommDP pattern exists within a certain context.

Qualities of Communication Protocols

Like software, Application-Layer communication protocol (ACP) suites, as whole, should possess certain desirable qualities that contribute to the overall success of a system. Some of these desirable qualities come directly from the software arena. For example, cohesion is the degree to which the elements of a software component align with a single purpose.[2] Cohesion and its definition can apply almost directly to ACP’s, but this is a subject for future research (see Section IX). Another desirable software quality directly applicable to ACP’s is modularization. Modularization is the degree to which a system is divided up into independent components.[3] When a system has good modularization, developers do not have to look very far beyond a component to understand it or reason about it. We believe the same to be true for ACP’s, but the details of modularization applied to ACPs is also a subject for another paper (see Section IX).

Although we believe cohesion and modularization are important qualities for ACP’s, they do not directly help in describing reoccurring communication problems nor are they good discriminators for reusable solutions, because all pattern solutions should, by definition, have good cohesion and modularization. So, we turn our attention to four other qualities with discriminating definitions for ACP’s, namely: reliability, synchronicity, longevity, and adaptability for scalable distribution.


For an ACP, reliability is the degree to which a process that sends a message as part of a conversation obtains an assurance that the intended recipient(s) received it, entirety and uncorrupted, and reacted as prescribed in the ACP.


In the most general sense, synchronization deals with the coordinated execution of actions in a distributed system and what the state information is necessary for that coordination.


Longevity is the degree to which an ACP can support long-running conversations caused by long-running operations.

Adaptability for Scalable Distribution

ACPs can support scalability by providing location transparency and/or replication transparency, and by allowing resources (data, operations, or objects) to be distributed across multiple hosts.

Template for Communication-Protocol Patterns

In order to describe every pattern, we follow GoF template and adapted to our pattern language. This Pattern Template mainly defines the problem and the solution that every pattern is concerned with. Its sections are Name, Intent, Description: (Problem, Context, Solution), Consequences, Known uses, Aliases and Related Work, and Examples of Application . Here the template in detail

ACP Idioms

Before launching into a description of CommDP’s patterns, it is important to first introduce three fundamental building blocks for all ACPs: point-to-point send, multicast, and broadcast. These are idioms instead of patterns because their usage depends on the lower layer communication protocols and because, by themselves, they do not address the qualities discussed in Qualities of Communication Protocols.

Point-to-point Send

A point-to-point send is the transmission of a single message from one process to another, such as a message sent over a TCP connection or via a UDP datagram. An underlying communication subsystem may provide some reliability relative to the transmission but, at the application-level, a single message does not allow the sender to know if the receiver processed the message or anything about the receiver’s state, nor does it help with longevity or adaptability for scalable distribution.

Multicast Send

A multicast send is the transmission of a single message to a set of receiving processes.[4] It can be implemented at virtually any layer in communication hierarchy, including the physical layer. Mechanisms for identifying the group of receiving processes vary from sender determined to receiver subscriptions. By themselves, multicast are idioms for ACPs.


The same (of Multicast) is true for broadcast. Broadcast is the transmission of messages to all connected receivers. It can also be sent from multiple senders[4]

ACP Patterns

The next Table, COMMDP Patterns, lists the nine patterns currently in CommDP, along with their rankings from their consequences relative to the characteristics discussed in Qualities of Communication Protocols: (R=Reliability, S=Synchronicity, L=Longevity, and A=Adaptability for Scalable Distribution).

CommDP Patterns
Name Consequences
Request-Reply 2 2 1 1
Request-Reply-Acknowledge 3 3 1 1
Idempotent Retry 3 1 1 1
Intermediate State Messages 3 3 3 1
Second Channel 1 3 3 1
Front End 1 1 1 3
Proxy 1 1 1 3
Reliable Multicast 3 3 1 2
Publish-Subscribe 2 1 1 3

Following are brief descriptions of each pattern, Click on their titles to see a complete definition according to our Pattern Template.

Request-Reply pattern

RR is undoubtedly the most common. It addresses the problem where a process, A, needs to access or use shared resources in another process, B, with a reasonable degree of reliability and synchronicity.

Request-Reply with Acknowledge pattern

RRA 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.

Idempotent Retry pattern

IPR[5] captures different solution to the problem of processing duplicate requests. Like Request-Reply, its solution consists of A sending a request to B with a timeout/retry behavior and B sending a reply back to A. But, unlike Request-Reply, the semantics of the protocol dedicate the processing of the request must be idempotent. This pattern applies to situations where the requested processing is relatively light, i.e., less expensive than caching replies. Read more about IPR on its source: Service Design Patterns

Intermediate State Message pattern

IMSM is also similar to Request-Reply, but addresses the problem of long-running conversations due to request actions taking substantial amounts of time to complete.

Second Channel pattern

2Ch is also for situations involving long-running conversations, but ones dominated by significant amounts of data transfers instead of time-consuming actions.

Front End pattern

FE addresses the problems of making the location of shared resource transparent to the client, allowing the number of resources to change dynamically.

Proxy pattern

Like the Front End', the PXY introduces a process between a resource client and a resource manager.

Reliable Multicast pattern

RMC 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 processes, B = { b1, .., bn }.

Publisher-Subscriber pattern

P-S[6] pattern is a powerful mechanism for decoupling message senders (publisher) from message receivers (subscribers). With this pattern, an intermediate process acts as a store-and-forward buffer for message transmission with the capabilities for managing subscribers and delivering individual message to multiple subscribers. Read more about P-S from its source: Pattern-Oriented Software Architecture: A pattern Language for distributed Computing Vol. 4

Pattern Language for composition

Patterns are rarely used in isolation; instead, developers combine their solutions to solve complex problems. Virtually any of the CommDP patterns could be combined with any other pattern, but the more useful combinations are ones that have complimentary characteristics, like Request-Reply with Second Data Channel or Request-Reply Acknowledge with Front End.

To ensure that the CommDP pattern set was as minimal as possible, we did not include in any pattern in CommDP that was simply an aggregation of two or more patterns. For example, there is a common type of distributed system that deals with information flow and processing. In such systems, a process A might send a request to B through a series of intermediate proxy-like processes that transform or augment data in request on its way to B. At each intermediate step, a reply is sent back to A, informing it of the message’s process. Eventually, when the transformed message arrives at B and processes it, then B sends a final reply message back to A. This particular solution offers good reliability, synchronization, longevity, and adaptability to scalable distribution, but it is actually just a composition of the Proxy pattern (applied perhaps multiple times) and the Intermediate State Message pattern.

Theoretical Background and further reading

In this section, you can find brief descriptions of Communication Protocols and Design Patterns, also there is a set of a comprehensive literature references for additional reading on their respective fields.

Protocols and Protocol Suites

Design Patterns and Pattern Languages

Published papers

  • 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


  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. E. Yourdon and L. L. Constantine, Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, 1st ed. Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 1979.
  3. “Modularity,” Wikipedia, the free encyclopedia. 11-Apr-2016.
  4. 4.0 4.1 A. S. Tanenbaum and D. Wetherall, Computer networks, 5th ed. Boston: Pearson Prentice Hall, 2011.
  6. F. Buschmann, K. Henney, and D. C. Schmidt, Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing, Volume 4 edition. Wiley, 2007.