A PlugNode has been designed for obtaining functionality from other program modules as well as for exposing current program module's functionality to the outside. It encompasses connections over a network to remote program modules as well as direct connections based on function pointers to locally available program modules.
A program module is understood as an instance of a source program which may be written in an arbitrary programming language and which may follow any programming paradigm. Between many others, an instance of a C++ class could become a program module in the sense of this description at runtime if it has been derived from the PlugNode class or if it maintains a member variable of that type. It may be obvious but should be admitted here that a different instance from the same source program will become a program module of its own and thus it will communicate to other program modules and in particular with those modules that have been created from the same program source.
The basic structure for all communication, remote as well as local messaging, is based on equilateral pyramids (tetrahedron). The current program module is thought to be in the center of two merged tetrahedrons where one tetrahedron is pointing to the front with one of its edges and the second tetrahedron is pointing to the back with one of its edges. This picture has been drawn to facilitate the understanding of the complex communication structure which results from connecting multiple program modules together in a network.
By convention, all remote connections will be represented by blue color and the local connections will be represented by red color.
Any edge of a blue pyramid can be connected to a blue edge of another pyramid in order to communicate to that pyramid's program module. The picture shows in a simplified two-dimensional way how a current program module in the center is connected to multiple other program modules on all of its edges. A fourth connected program module is not shown but will be present either in the front or in the back of the center pyramid.
In analogy to remote communication, a program module can be connected to upto four locally available other program modules directly. Far more than those one plus four PlugNodes can be connected in a local tetrahedron structure and they will establish a common local messaging group. Once a wanted communication peer has been discovered in that local messaging group a direct and fast connection can be established based on a function pointer. The combination of a flexible messaging structure with the possibility of a direct shortcut provides for an uncompared scalability along with high performance features.
When one module uses a service from a second module those modules are said to be connected by a service connection. In opposite to well known uni-directional service providers like a HTTP server or a local function call a service connection is a very symmetric setup. The client side will know how to reach the server and the server will know as well about how to reach each client that has subscribed to its service. This symmetry is especially important for a graceful shutdown of a service where all clients have to be informed that the service is no longer available and must not be called any longer. The server will use the client connectors in this case in order to revoke its connector from the clients' list of connectors.
When looking at usual implementations for remote and local services one will most often find solutions that are based on the assumption that a service provider is available almost all the time. A HTTP server in the Internet is an example that is based on that assumption as well as a common function call in a program is based on the same assumption.
While designing systems based on independent modules one will become aware that the previous assumption will no longer be valid. Remote modules may shutdown their service while a client is still running as well as a locally available module could stop running while client modules that are connected to it will still continue working. Those roughly described use cases provide to the requirement of a symmetric implementation where each of the two communication partners is allowed to inform the peer about finishing work. The following procedures support such a symmetric approach.
When a client needs a service it will ask the local respectively the remote network of co-workers about a suitable server that is able to provide desired service. The client will specify an "inbox" where offers can be sent to. In case of a local service discovery the "inbox" would be a function pointer which can be called with the offered service's service function as an argument. On the other hand, in case of a remote service the "inbox" would represent an IP address and a port where an information about the offered service's accessibility can be sent to.
Once the client has received one or multiple offers it is said that a temporary service connection has been established. This service connection will be called temporary since either of the service discover and service offer messages will timeout. The timeout value is determined by the sender of the particular message. As long as the service offer timeout has not been reached the service requesting module could decide to accept an offer and would just use the offered service.
A service providing module will be bound to its offer till the end of the self-specified service offer timeout. On the other hand it can revoke an offer if circumstances demand for it but only as long as the original service discover timeout has not elapsed since the service requesting module can be safely reached but till that time. Therefore, in a usual setup a service providing module would set the service offer timeout before or equal to the service discover timeout since otherwise it would loose the ability to revoke its offer.
While a valid service connection is present the initiator of that service connection can use the offered service at any time. For doing so, the service requesting module will send out a service request. The service providing module will generate a response and will send it back to the service requesting module but only if the request timeout has not elapsed yet. Otherwise the response will not be sent but will be silently discarded.
When sending a response back to the service requesting module the service providing module can decide to extend the offer for a repeated service. In this case a new offer timeout will be sent together with the response. As already described in service arbitration, an offer can be revoked as long as the service requesting module's timeout (request timeout in this case) has not elapsed.
A service connection will stay valid as long as its timeout has not been reached. However, it can be shutdown during its active time from both sides. If a client does not need a service connection any longer it will send a "service release" message to the service provider.
On the other hand, if a server wants to shutdown its service it will send a "service invalidate" message to all peers that still maintain a valid service connection at that time with the service provider.
The range of offered services encompasses everything where one program module may use a service from a second program module. In the following, some samples for those service offers will be given without claiming the listing to be comprehensive.