About: Messaging

Using an abstract point of view, work that is to be done is always requested by a 'client' and performed by a 'server'.
This can also be applied to a simple call of a function, where the caller (the client) requests the function (the server) to work and return a result.

When the server is not directly accessible by the client (i.e. the function is not within the same process, but in another one - possibly even running on another host) both the request and the response have to be transported back and forth.

The information that is to be transported is sent and received in messages (or, also called: packets). There exist even more terms for the same thing, but the author stays with these two.

I differ by using 'packet' for low-level application and 'message' for higher application.

Note that this form of communication is also often called asynchronous communication in oppose to isochronous communication, where information is constantly transported (e.g. voice over a telephone line).
The term 'asynchronous' used in context of Semys is used for something else:

While the server is processing the request, the client is idling as it waits for the result. During that time the client can not do something else (continue to work) until it receives the response.

Instead of using another thread to work on other things, the client simply can release control of the current task and work on the other. The work on the server is being performed asynchronously.
As soon as the response returns and the client handles it, the first task is reactivated and continued.

This way only one thread is needed. Work that needs to be done is queued up and processed one by one, until another asynchronous request has been sent.

Reaching this stage, both the client and the server hardly differ anymore: The client sends a message to the server (where it is placed in it's queue), the server reacts to that message, processes it and sends back a response message. This response message is placed in the queue of the client which continues to form other requests - until the whole work is completed.

This leads to the next level of abstraction: The client typically wants a response from a request it previosly issued, describing the outcome of the work.
How 'good' or how 'bad' (error) the work has been done can be transmitted by extra members in the response message. There is no difference between a 'return value' and an 'exception' - The client only awaits a response message.

If the messaging is used within a process, the next benefit of exchanging data only via messages is that no thread local data needs to be secured by mutually exclusive locks.
Since the message queue is the only thing that is accessed by other threads (appending messages), it is also the only thing that needs to be locked.

Next to the response messages of the server based on the requested work, a notification message about connection loss to the server must also be considered as a valid 'response'.

Upon connection loss, a server stops any work it has been doing/started according to that connection - there is no entity anymore that may receive any results or could control further actions.

The client on the other side has to expect that the work is aborted or has not even been started after loosing connection to a server and has to act accordingly (Re-requesting to another server...) .

As a result: everything from a function call, request, result, exception and event can be described as a message.
Messages are put into a queue of a thread that handles them on a FIFO basis.

Goto: Main Page; This page is part of the Semys software documentation. See About: Documentation for details.