Inspirel banner

Programming Distributed Systems with YAMI4

8.1 Channel Management

All YAMI4 libraries introduce an important concept of a channel, although the high-level services of Ada, C++, Java, .NET and Python libraries manage to hide that concept from the regular user.

Even though there is no particular reason to manage channels explicitly in the typical application code - and example programs provided together with the YAMI4 distribution can be taken as a proof of this - it is reasonable to understand the channel life-cycle and there are several use cases where the application can benefit from controlled channel lifetime management.

Channels are agent's internal data structures that take care of communication with a single remote end-point. In the simplest example of client-server interaction, when the client connects to the server, two channels are created:

The sender's channel is created automatically by the ``send'' operation only when the automatic connection option is chosen when that operation is called. This is the default and corresponds to the most typical scenario, but in some cases users might want to have complete control over when the outgoing channel is created. The reason for this is that creating a new connection is a potentially blocking operation that can introduce a delay in the calling thread. Users that expect real-time guarantees will certainly want to decouple the phase of creating connection (with the explicit call to ``open connection'' operation), which can block, from the phase of posting messages to the already existing channel, which never blocks. The auto-connect flag of ``send'' can be used to select the preferred option.

Once the channels are created, they are reused for all subsequent communication that names these channels by the appropriate target. This means that when the client requests a new message for the same server destination, the same client-side channel will be used as long as it exists. Similarly, when the server requests to send a message (or reply) to the target that corresponds to the existing channel, that channel will be reused. There are two important consequences of this:


The latter of these two consequences allows to set up a communication channel over a typical firewall by first creating a connection in the direction that is allowed by the firewall and then proceed with client-server interactions even if at the level of their logical direction they would violate the firewall settings.

The two example channels above are created synchronously and at a known point in time, but the exact time of their destruction depends on the actual transport protocol.


Server-side channels for UDP communication are not closed automatically when the respective client terminates. The reason for this is that in the absence of physical connection (UDP is a connection-less protocol) there is no provision to communicate the fact of client termination to the server. In other words, the UDP server has no chance to learn that any one of its existing clients is down.

Taking into account the above explanations, the three use-cases where the application code can benefit from explicit channel management are:

In either case, the YAMI4 agent is able to properly treat the channel close request in the presence of outgoing frames that are still waiting in that channel's outgoing queue - the request to close the channel respects the priorities of waiting frames so that low-priority close request is only registered and becomes effective only when all the higher-priority frames are physically sent. Still, registration of the close request prevents the new frames from being inserted into the queue, irrespective of their priority.

There is a separate ``hard close'' operation that allows to bypass this queue integrity mechanism and it can be used to unconditionally (and immediately) close the given channel without respect to messages that can be waiting in its outgoing queue. This operation can be helpful for error recovery purposes - there might be network problems that prevent any frames from being successfully flushed and subsequently prevent the channel from ever getting closed with the above ``soft'' method - the hard close operation can be used to forcibly close such misbehaving channel. Otherwise this operation should not be overused.

8.1.1 Connection Event Notifications