|
|
||
|
The YAMI4 messaging system supports several underlying transports - the actual set of transports depends on the library variant, but at the minimum both TCP and UDP are supported in a consistent way that for most uses allows a drop-in replacement of one with another.
That is, instead of the target name of the following form:
tcp://address:port
one could use its UDP alternative (or the other way round):
udp://address:port
The challenge in the library implementation was to manage both transports in a way that attempts to hide their natural differences - namely, that TCP is connection-based while UDP is a connection-less protocol. Message framing and frame assembly are taken care of automatically and most of the time the user need not think about the traps that can be hidden behind the details.
Still, some of the aspects of communication cannot be fully transparent and the one that is the subject of this tip is the lifetime of logical connections that the YAMI4 agent deals with.
The TCP transport (Unix sockets are in this category as well) can detect and report the End-Of-File condition, which happens when the other party closes its side of the connection. That is, when the client connects to the server, sends some messages and after a while closes the connection, the fact of connection being closed will be detected by the server. Depending on the network infrastructure setup this detection can be immediate or delayed by various obstructions, but the server always has means to detect the EOF condition caused by the client getting disconnected. This allows the server-side agent to clean up internal resources and even report that fact to the application via various callbacks. Thanks to this, the resource management on the server-side is simplified.
The UDP transport has no such mechanisms, as at its fundamental level it does not rely on the notion of connection. The communication happens in terms of packets and there is no way to declare that any given packet was the last one. In other words, if the client decides to "disconnect" (that is, to stop interacting), the server has no automatic way to detect it and therefore no way to decide that the internal resources related to that particular client should be cleaned.
For this reason programmers that rely on UDP in their systems should think about some way of dealing with this cleanup at the application level and in addition to do any necessary application-level cleanup, should also explicitly call the close_connection function on the agent.
The biggest problem in this scenario is of course the decision when that should happen - solutions like checking the time of last message that has arrived from any given source (note: the source property of the incoming message is also the name of the logical channel that is associated with the given "connection") and deciding on some reasonable domain-related timeout can do the trick.
Note also the the simplest solution is to close the logical connection systematically after receiving every single UDP message. This can be a good solution especially in those cases where messages are expected to arrive with very low frequency or even by design have the one-shot nature.
It is possible that future versions of YAMI4 will feature some ways to automate this strategy.
Previous tip: Let Me Think
Next tip: Connect Or Not