Mirrors/VILLASnode
1
0
Fork 0
mirror of https://git.rwth-aachen.de/acs/public/villas/node/ synced 2025-03-09 00:00:00 +01:00
Code Issues Releases Wiki Activity

wrote some more documentation

Browse source 
git-svn-id: https://zerberus.eonerc.rwth-aachen.de:8443/svn/s2ss/trunk@189 8ec27952-4edc-4aab-86aa-e87bb2611832
This commit is contained in:
Steffen Vogel 2014-08-31 17:30:45 +00:00
parent 5ff2459606
commit a466a8f694
1 changed files with 51 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

72
documentation/Concept.md
View file

@ -1,43 +1,73 @@
# Concept
The server is designed around the concept of _nodes_ and _paths_.
It's the task of the server to forward real-time simulation data between multiple parties.
In doing so, the server has to perform simple checks and collects statistics.
From the viewpoint of the communication parters the server is nearly transparent.
Hence, it's cruical to keep the added overhead as low as possible (in terms of latency).
A path is a **unidirectional** connection between two nodes.
## Nodes
Messages from the incoming node get forwarded to the outgoing node.
All communication partners are represented by nodes.
Possible types of nodes are:
* Simulators (OPAL, RTDS)
* Servers (S2SS instances)
* Workstations (Simulink, Labview, ...)
* Data Loggers
* etc..
@see node for implementation details.
## Paths
A path is a **unidirectional** connection between incoming and outgoing nodes.
A path simply forwards messages from the incoming node to the outgoing node.
By default the server does not alter message contents.
It only checks if the message headers are valid (sequence number, cryptographic signature..)
However every path supports optional callback function which allow user-defined operations on the message contents.
For bidirectional communication a corresponding path in the reverse direction must be added.
The server is designed to allow multiple outgoing nodes as an extension.
@todo This has **not** been implemented at the moment!
The server is designed to allow multiple outgoing and incoming nodes per path as an extension.
@todo This has **not** been implemented at the moment but will come in future versions.
@diafile path_simple.dia
## Path
@todo Add documentation
@see path For a detailed descriptions of the fields.
## Node
@todo Add documentation
@see node For a detailed descriptions of the fields.
@see path for implementation details.
## Message
@todo Add documentation
@diafile msg_format.dia
A message contains a variable number of values.
Usually a a simulator sends one message per timestep.
@see msg For a detailed descriptions of the fields.
Simulation data is encapsulated in UDP packages in sent over IP networks like the internet.
We designed a lightweight message format (or protocol) to facilitate a fast transmission.
@diafile msg_format.dia
### Protocol details
There are several types of messages:
* **Data**: contains simulation data.
* **Control**: start/stops a new simulation case.
* **Config**: used to pass settings between nodes.
* **Sync**: used to syncrhonize the clocks between nodes.
For now, only the first type (data) is implemented.
Therefore the complete protocol is **stateless**.
Later we might want to support more complex simulation scenarios which require some kind of controlling.
Except for the simulation data, all values are sent in **network byte order** (big endian)!
The endianess of the simulation data is indicated by a single bit in the message header.
This allows us to reduce the amount of conversions during one transfer.
@see msg for implementation details.
## Interface
@todo Add documentation
@see interface For a detailed descriptions of the fields.
@see interface for implementation details.