[Architecture]: Signal routing

[wolf-null]

The mirror consistency problem

AwooNet uses Stages to traverse all the nodes and updates it's states (or the states of the mirror, for instance, mostly to build the metrics of the whole network for monitoring purposes). Technically, Stages implements a Visitor pattern.

On a local machine, if a Node updates it's state (own local database), this update is also mirrored to the local MasterHost via DataSignal.

If two MasterHosts (Local and Remote) are interconnected via some sort of virtual ProcessHost (which works via network), then this DataSignal has to be also retransmitted to the remote host (if we do wand to hold the consistency of mirrors... and we actually do due to the horizontality of MasterHosts)

MasterHost doesn't know if it's PocessHost is it real (local ProcessHost) or a virtual (networking) one. This is why it should be somehow a way to tell to MasterHost to retransmit all DataSignals for certain Hosts. On the other hand, this 'retransmission' of signals might be useful for advanced applications.

This leads us to the need of implementation of more advanced routing algorithms than dst --> dst which is now used.

[wolf-null]

The node also has no idea about it's mirrors. This is why it can't send additional update signals to certain MasterHosts. For a Node there is only one MasterHost and all other Nodes.

Needless to mention: signal routing is already a responsibility of a Host.

[wolf-null]

One can propose a simple algorithm.

1. Adding node causes a signal:
   • When the node is being added to a ProcessHost, the latter emits a SignalAddNode to the master Host
   • When virtual ProcessHost is being registred or when it receives a message from the remote host, it emits SignalAddNode as if it would be a regular local ProcessHost
2. The (local) MasterHost holds the "routing table". It is a python dict object which has the form dst_node : dst_hosts <List[Host]>.
   • When a node is added via ProcessHost's interface, the latter reemit SignalAddNode to it's MasterHost which adds the Node into the routing table with respective ProcessHost paired to it.
   • When a node is added via MasterHost's interface, the latter orders the decided ProcessHost to spawn a node inside it. Then the MasterHosts adds the Node into the routing table with the respective ProcessHost paired to it.
3. Updating data
   • If a node updates it's data (state) via set or append, it emits DataSignal from itself to itself. Since all mirrors has the same node name, MasterHost will use the routing table to find all Hosts mapped to it and send the message.
   • To avoid switching loops, the signals has a "trace" or "tail" property which holds all places the signal was sent to. This is to be discussed later.
   • A configuration of routing tables of all MasterHosts in the network can implement symmetric mirroring or to prevent it.
   • Since there is only one real (non-mirror) node assumed existing in the network, it is reasonable to transmit DataUpdate signals to all mirrors whereas the MessageSignals are more reasonable to be redirected only to the Host where the original (non-mirror) node is situated. This means, that the different type of messages has different routing tables, which is lead by the hierarchy of inheritance.
     4. Each virtual ProcessHosts sends specific signal to the MasterHost it belongs to, which tells the MasterHost to add those virtual Host as the listener for all AddNode signals sent to the Master.
   • This literally means that Nodes and Hosts passes the routing right the same way. This is due to the Horizontality Principle:

All Nodes and Hosts interact via the same signaling interface.