Loading... (0%)

ClearConnect is a platform that supports a client-server topology.

Clients connect to servers using TCP/IP.


The Core Components



The core of the platform is the registry, this knows about every agent and service on the platform. An agent registers with the registry and also registers the services it creates. The registry monitors the status of agents and the services, informing all connected agents when any service disconnects from the platform.


An agent is used to create services and make connections to other services. A connection to a service is made by creating a proxy. The agent always goes to the registry to find the connection details for a service when creating a proxy.


A service is used to produce data. Data is represented in a record structure composed of key-value pairs. The keys are strings, the values are integral, decimal, string or binary data. As data changes, the changes are published to subscribers of the data. The subscribers are the proxies created by other agents. A service can also publish RPCs that allow proxies to invoke functions on the service.

Atomic Data Changes

A fundamental principle in the platform is atomic changes for data. Changes to the values of record fields are grouped together into a single change that is published as an ‘atomic change’. All subscribers receive this atomic change and this allows services to control the consistency of the changes that proxies will receive.

A Closer Look


The core architecture of the platform is supported by the DataFission framework, this provides the means for creating and updating data records, publishing atomic changes and handling RPCs.


A Context holds records. All record management and subscription activities go through this. A ProxyContext provides READ-ONLY access to record changes in a remote Context. It is an important concept that records can only be changed in the local Context; a ProxyContext cannot change records in the remote Context. Note that a ProxyContext uses its own local Context to replicate the records and changes received from the remote Context.


A Context can support TCP connections to multiple ProxyContexts. The record subscriptions are managed per connected ProxyContext. If a TCP connection fails or a Context bounces, the ProxyContext will continue to re-connect. On reconnecting, the ProxyContext will re-sync all subscribed records with the Context.

Remote Procedure Calls

A Context can publish RPCs that a ProxyContext can invoke; this provides functional interaction between a Context and ProxyContext.