[NEW FEATURE] Native step 2 : Multiple nodes running

[nicolas-rabault]

In this second step of the Native development, our goal is to be able to run multiple Luos_engine binaries (nodes) to be able to list them during detection, and to make them communicate. We consider the step 1 ( #290 ) as completed

Or final goal will be to have the button running on another node that the Gate and still be able to catch it on the pyluos side :

To do that, our main focus will be on the Robus HAL.

Communication

To exchange information it could be great to rely on WebSocket and to be able to broadcast to all off them information. For broadcasting we could use MQTT with a broadcast topic.
This part is open to contribution and brainstorming

Detection

We will need to find a way to list other services and to send them node ID. To send them Id we need to be able to send a non broadcast message. If We use MQTT each node could create a topic with it's node name allowing anyone to reach this specific service.
This part is open to contribution and brainstorming

[nicolas-rabault]

@AltayAkkus made a proposition on #292 then we plan a call to discuss about it. In this comment I will try to resume this discussion and define more precisely how we plan to develop this.

First considered solution

One of the big challenge is that unlike half-duplex serial, websockets are point to point. Robus communication highly rely on the broadcasting aspect so to make it work the same we have to find a way to do that with WebSockets.
If we want any node to be able to broadcast to any other one we will have to list all the node on all the node and connect all the node to all the node allowing any node to send information to all other ones :

This is heavy for each nodes and the complexity and needed ressources will be multiplied by the number of node on the system.
To finish, this imply to have an efficient node detection system before being able to exchange information or to maintain a static list of node addresses...

Kept solution based on @AltayAkkus proposition

Instead of trying to emulate how Robus connections are made on each node we could centralise this emulation in a dedicated program:

This way nodes stay simple. They only need to connect to the Robus_emulator' program. Robus_emulator` will be able to list all the available nodes by listing the clients to its WebSocket server.

Communication

Each received messages will be re-sent to other nodes.

Detection

PTP signals will be emulated by specific PTP messages between nodes and Robus_emulator. Those messages are the only one that will be not re-sent to all the other nodes. Robus_emulator will be able to send a received poke from one PTP to the next available node. The state of each PTP connection will be an OR operation between the 2 ptp states, exactly the same way it's working on the real world.

Robus_emulator network representation

Nodes will be represented as a chained list allowing to add and remove nodes dynamically and reshaping the virtual network easily.
Also we will have a structure representing PTP links and storing the calculated state of the line depending on the different states of the PTP pins:

At each PTP state update we will recompute the line state then send an update to the other node if this update change the line state (line = PTPA || PTPB)

[JeromeGalan]

There are existing MQTT libs in C (such as this one : https://github.com/LiamBindle/MQTT-C).
There is no need to create a MQTT driver from scratch.

[JeromeGalan]

What about ISR emulation ? To simulate critical sections and realistic robus network messages, it could be great to have such a feature. Well, it's interesting for QA ! But users don't care about that.

[AltayAkkus]

I personally would refrain from MQTT as service discovery.
First off MQTT is a huge protocol, that can do a lot of things, using this for service discovery is extremely overkill.
The Broadcast also works via my proposition, in the same way the "real" Luos works.
If we would use MQTT we would have to inject the data into the PTP lines again, from the WebSocket server et cetera.

WebSockets are very performant, not Gigabit performant, but like 4k messages a second performant, I don't think there is a need for optimization.

@JeromeGalan can you elaborate on the ISR emulation? Injecting a fault, that one Node stops responding/broadcasting?
You could add such tools to your enterprise software package :D Adding it as a native feature, hm I dont know.

Excuse me for being absent so long, I am back to work and have a lot of things to do unfortunately

[JeromeGalan]

@AltayAkkus , for sure ISR emulation mocking can be a usefull feature for testing, monitoring and injecting strange behaviour. I'd already have such a need in a past life. But it's more interesting in embedded. For native, the question is open.

[nicolas-rabault]

Welcome back to work @AltayAkkus, to be honest we don't had any time either to work on this.