About Us Products Articles News Contact Support

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:

Sender-side channel is created by the client's agent, with server's target as the end-point. In fact, the channel is identified by the server target string that was used to send the outgoing message and it might be, for example, "tcp://serverhost:12345". This channel contains the outgoing and incoming queues where frames are stored for output or assembly. Such a channel is quite self-contained and autonomous, although all of its I/O operations are driven by the agent's I/O worker thread. This channel is created when the given target is used for the first time in the call to the ``send'' operation and the automatic connection option was used or when the explicit ``open connection'' operation is invoked.
Receiver-side channel is created by the server's agent from the listener which was addressed by the client. This channel contains the client's target (known as the source target) as its end-point and that target identifies the channel at the server side - this might be, for example, "tcp://clienthost:56748", which can reflect the client-side port number that was assigned for creating this connection. The channel contains also the outgoing and incoming frame queues and is similarly driven by the server agent's I/O worker thread. This channel is created when the listener detects the incoming connection.

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:

Message replies (send from servers to clients) use the same channel that was used to deliver the original request. No new physical connection is created for this purpose.
New outgoing messages that are sent from servers to clients (that is, when the server and client reverse their roles in communication) also use the same channel that was originally used to initiate the connection.

Note:

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.

Client-side channels are kept alive until the agent itself is destroyed or until the ``close'' operation is explicitly invoked.
Server-side channels for stream-based protocols (TCP/IP, Unix sockets and files) are kept alive until the physical underlying connection is closed or until the agent is destroyed or until the ``close'' operation is invoked, whichever comes first.
Server-side channels for datagram (UDP) communication are kept alive until the agent is destroyed or until the ``close'' operation is invoked.

Note:

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:

When the application needs real-time guarantees for message posting. Even though it might not be immediately obvious, this is actually the case with publish-subscribe scenario, where the publisher needs to send data to many subscribers with minimal jitter. The publisher decouples the connection creation from message posting in order to avoid interferences that might be introduced by automatic reconnection of failed subscribers without such explicit decoupling in place. Other jitter-sensitive applications will certainly need to adopt this approach as well.
When the application needs to reduce the number of open connections in order to save system resources. In many cases there is no need to keep all connections open all the time. A possible example might be a server that provides lookup services for other programs in a distributed system, which interact with the server for a short period of time (perhaps only at the initialization phase) and then go on with their work without any further interaction with that particular server. Without any explicit action on the server side the channels are accumulated as they are created for all clients and the system resources are wasted. In this case, the server can explicitly close the channel for each client after sending back the response.
When the UDP server needs to have a bounded limit on its resource and memory usage. Since server-side UDP channels are not closed automatically even when the respective clients terminate, the only way for the server to manage its channels' lifetime is to do it explicitly.

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