The channel communication pattern involves two peers. This pattern is a bidirectional communication: two nodes communicate with each other, sending messages without a strong relationship between each message. The following figure shows how this pattern works:

Although this communication pattern can be used over all kinds of communication channel, it is mostly used in network communications.

The differences between intra-process, inter-process, and network channels are as follows:

• Intra-process channels are quite rare. These would involve recursive calls to inter-dependent functions. Not something to be used on a daily basis!
• Inter-process communication is also quite rare, although more natural to implement than intra-process channels. This pattern is possible with many IPC brokers. However there are not many use-cases where two components talk to each other with a loose coupling between each other's messages.
• Network channels, on the other hand, have a very popular use-case for this communication pattern: chat services. On such services, the messages emitted by each peer are not technically linked to the other messages. Hopefully these messages are semantically linked together, but only for the end-users who wrote the payload of these messages.

Despite its limited usages, the channel pattern can be used as a base for other communication patterns. So, implementing it is a requirement before dealing with more evolved patterns. Channel communication requires a bidirectional channel. However, observables are unidirectional channels. So how can a bidirectional channel be implemented on top of unidirectional channels? The solution is easy: by using two unidirectional channels communicating in the opposite direction, and linking them logically. This forms a bidirectional channel. The following figure shows the channel pattern implemented on top of two observables:

On this implementation, each node subscribes to an observable of the other node. The two observables must be logically linked so that a node can use several channels, either with the same peer, or with other peers: This ensures that a message is sent to the correct peer. The following figure shows a sequence diagram for the messages being sent on the network link to establish a channel:

This sequence diagram is based on the one of the publish/subscribe patterns, but duplicated: each node subscribes to an observable of the remote node. However, this is done strictly sequentially so that the two observables are linked together.

The first step consists of both peers connecting together. One peer must be a TCP Server while the other must be a TCP Client. In this case, the choice of whether a node should be a server or a client is independent of the fact that the node is a producer or a receiver since it is both.

Then, one of the nodes initiates the creation of the channel. It does so by subscribing to the observable of the peer. This step is the same as for publish/subscribe. Once this observable is subscribed, the other node subscribes to the observable of the first node. At that point, the channel is available and both nodes can communicate with each other. Linking the two observables together is done on top of the publish/subscribe sequence described in the previous section. In practice, a channel component is in charge of this, via the composition of an observable and an observer.