YAMI Home

Concept

Specification

Implementation

What next?

Questions
& Answers

Comments

Implementation

[Downloads] [Internal model] [Connection modes] [Performance]

Simplex, duplex and recurring firewall issues.

From the very beginning, the main principle in YAMI was that all the Agents provide a network that is a basis for user applications.
Agents communicate to perform tasks necessary to provide a uniform communication infrastructure. In order to do so, Agents need to send one another various messages. These messages are treated uniformly by the Agents, no matter what was their meaning from the user application's point of view.
For example, some messages carry requests, some other carry responses, some others carry rejections, etc. The purpose of each message is not relevant from the low-level point of view, since everything that one Agent sends to another is just a message. The purpose of the message becomes visible only after it is delivered, when the Agent parses it - only then that low-level message becomes what from the user application's point of view is a request, a response, a rejection, etc.

In order to realise this concept, each Agent is given a queue of sending connections, which is used to send whatever is needed to other Agents. This means that what from the programmer's viewpoint is a message with reply, is implemented as two separate messages sent between peer Agents. In other words, communication between Agents is performed in the simplex mode, where each connection is used to send message only in one direction. If two-way communication is requested, then two separate connections are established.
The following figure explains it:

So what's wrong with it?

Many YAMI users write programs that work in the network with a firewall.
The popular firewall setting allows the client machine to call the world (to establish a TCP connection with external IP address) and also allows returning packets that are part of the already established connection. The typical firewall does not allow external components to establish any connection with components located behind the firewall.
This means that Agents separated by a firewall do not see each other in the same way: the Agent located in the external network (WAN) cannot call the local (LAN) Agent.
The figure below shows the problem:

The solution was to enable Agents to communicate in duplex mode.
In such mode, Agent can reuse the connection established by the other Agent to send him back whatever is necessary. Usually, the messages that go back through the same connection are just responses, rejections, etc. for the originating request. This is exactly how typical web browsers, mail clients and other internet-related applications work.
Such communication mode makes it possible to use clients and servers separated by firewalls:

The possibility to use duplex connections was added in YAMI 3.0, but the original simplex mode is still in use, since each mode has its own advantages and disadvantages:

Simplex mode:

• Allows to use small connections pools even in the presence of unlimited number of Agents communicating with each other, because simplex connections are never fixed - they can be reused if possible, but they can be also dropped at any time if the number of connections is greater that the capacity of the pool.

Duplex mode:

• Allows to use YAMI software in more restricted network environment. In addition, the connections are fixed and exist as long and both communicating parties are alive. This allows to use simpler protocol, but at the risk of blocking network resources on the server machine, if the number of connected clients is very large.

Normally (in non-restricted network), using simplex connection should not be a problem. You can consider using duplex mode when there is a firewall between client and server or when you need maximum performance in terms of number of messages per second.

Note that it is perfectly possible to use both modes at the same time, even between the same pair of communicating Agents. In such a setting, however, the relative ordering of messages is not guaranteed between channels.