Client

The client architecture of OctoMY™

Topics

  • client
  • architecture

Client architecture

We have a comms working together when OctoMY™ nodes communicate with eachother.

Nodes will learn of eachoter through the discovery and pairing process. A communication channel is set up between pairs of nodes over a carrier.

All this is orchestrated through the use of the service management architecture, where each part is wrapped in a service, and groups of services are named and can be activated together.

Further, separate types of courier have been made to handle the transfer of different types of data, taking care to spend as little bandwidth as possible.

But what couriers will be active at which moment? And what actual data will the couriers send?

This is where the final piece of the puzzle comes into play, namely the "client" architecture.

When two nodes discover each other and the user carries out the pairing procedure, each node will have an "associate" entry in their respective addressbook identifying the other.

When the comms service is activated as part of the "online" service level, all associates in the addressbook are instanciated into clients in the node's client list.

Clients are running communication envoys, each entry represents a remote node and maintains the best known state of that node at any given moment.

There is a node base client which contains the client mechanism and then there are agent clients, remote clients and hub clients specializations of the base node client that actually hold the state for each respective node type.

The node client has the following:


Debug enabled