Second Channel pattern

From COMMDP
Jump to: navigation, search
Next: Front End 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).

Second Channel pattern

Name and Overview

Second Channel (2Ch)

The 2Ch pattern is found in applications where there is need of extensive data interchange and the messages can not be used as a carrier for control messages. i.e. piggy backed acknowledge is not allowed. Instances of this pattern can be found in long running conversations such as the file transfer protocol, where two different ports are used. one for data transfer and one for controlling the transference. Instances of 2Ch can be found in Real Time Communications (RTC) in the Browser, for example applications that use the WebRTC [2] framework, where a peer to peer communication is open, and a signaling method is used for control messages and to coordinate the communication. Implementations such as text, audio and video chatting [3].

Intent

The Second Channel pattern is also for situations involving long-running conversations, but ones dominated by significant amounts of data transfers instead of time-consuming actions. Because the large data transfers can delay intermediate state messages, this pattern’s solution suggests opening a second communication channel between A and B that is dedicated to data transfer, leaving the original communication channel available for intermediate state or control messages. The File Transfer Protocol (FTP) and its variations are classical examples of this pattern.

Description

Problem

One process wants to exchange data with another process, and at the same time, it needs to control the conversation.

Context

The amount of data is large or the exchange needs to occur over a long time.

Solution

The solution is for the two processes to coordinate on the creation of a second, dedicated communication channel for the exchange of sending messages, leaving the first channel open for controlling the conversation.

A possible variation of this pattern would be the case of a third party process handling the control messages.

Process Roles

Initiator, Responder

Messages

Request, State1, State2, … , Staten, Chb info, Data messages, Reply

Scenario

Initiator -> |Request| -> Responder
(Responder opens 2nd communication channel)
Responder -> |Chb info| -> Initiator
(Initiator connects to 2nd communication channel (Chb))
ASYNCHRONOUSLY:
{
cha while(messages)
 Initiator <-> |State1| <-> Responder
 Initiator <-> |State2| <-> Responder
 ...
 Initiator <-> |Staten| <-> Responder
chb while(messages)
 Initiator -> |Data messages| -> Responder
 Responder -> |Data messages| -> Initiator
}
...

options to finalize ???? or it just ends when there is no more messages???
- Responder -> |Reply| -> Initiator
- Responder -> |Staten| -> Initiator
- Initiator -> |Staten| -> Responder

Semantics and Behavior

  • The Init Reply (Chb info) should contain information necessary for the Initiator to connect to the second communication channel.
  • The Responder’s End Point for the 2nd communication channel must be accessible to the Initiator.
  • The individual subsequent replies (Data message interchange) on the 1st communication channel can follow any appropriate communication pattern.
  • The 2nd channel can be bi-directional or uni-directional
  • The data on the 2nd channel can be structured or unstructured
  • Conversation control operations should occur on the 1st channel
  • Conversation is over when, after a timeout, there is no more messages

Consequences

A conversation between A and B, i.e. a synchronized long running message interchange between A or B.

Consequences
Quality Rating Justification
Reliability
1
This pattern can provide a modest level of reliability. Specially it does not implement a full control whether the messages are being received or sent by any of both processes A or B. The control channel is more concerned on handling the availability of the communication channel.
Synchronicity
3
This pattern provides a high degree of synchronicity. Specially through the control channel established by B. A knows that B is available to receive its messages and vice-versa. Synchronizations is established by B and mostly managed by B, although A can send or request some control over the channel.
Longevity
3
2CH provides for long running conversations without other processes interruptions, as much as needed by A or B.
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

  • long conversations
  • extensive exchange of messages
  • real time communications
  • audio chat
  • text chat
  • video chat

Aliases and Related Work

Related work

  • Message Channel pattern, as part of Interface partitioning section in Pattern-Oriented Software Architecture Volume 4, (POSA 4), chapter 10[4]
  • WebRTC Framework [2]

Examples of Application

2Ch pattern occurs in applications such as file transfer protocols, as is the case of ftp [5], which uses a separate control and data connections for communication between the client and the server. A complete description of FTP can be found at RFC959 [6]. Other applications can be peer to peer text, audio and video chat applications, for example, implementations using the WebRTC framework[2].

FTP Scenario

- The User-protocol interpreter initiates the control connection,
- ftp commands containing the action, data port, transfer mode, representation type, and structure are generated and transmitted to the server via the control connection.
- standard replies are sent from Server Protocol interpreter back and forward.
- The user Data Transfer Process (DTP) listens on the specified port, 
- and the server DTP initiates the data connection and data transfer according to the provided commands.
Next: Front End 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 “WebRTC Home | WebRTC.” [Online]. Available: https://webrtc.org/. [Accessed: 09-Mar-2017].
  3. S. Yuzhuo and H. Kun, “Design and realization of chatting tool based on web,” in 2013 3rd International Conference on Consumer Electronics, Communications and Networks, 2013, pp. 225–228.
  4. F. Buschmann, K. Henney, and D. C. Schmidt, Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing, Volume 4 edition. Chichester England; New York: Wiley, 2007.
  5. “File Transfer Protocol,” Wikipedia. 17-Feb-2017.
  6. “File Transfer Protocol,” Wikipedia. 17-Feb-2017.