The release of the alpha version of the Internet of Things protocol stack
Hello! The festive atmosphere is already knocking on the screens of monitors and arrives by spam to your email addresses. So we decided to fulfill our promise and bring our stack to the light.
Let's get to the main point: what have we done about it? Immediately make a reservation: we will not compare the MOAR and IPv6 stack, because now talking about IPv6 is almost the same as talking about teenage sex: everyone talks about it, few people know anything about it and only a few have tried it .
We will call the node one device with one stack instance. The node was created to test the operation of the stack in relation to external sensors.
')
We needed the most transportable solution, and initially everything was packed in a simple cardboard box. But it was not enough for a long time, but we were annoyed to constantly open the box for information, and given that all the elements were attached to the wires, the complexity of use at one point overpowered laziness, and it was suggested to make a case. Access to a 3D printer quickly put an end to the question of how to make it. The test device turned out quite successful and made its way with us from Kaliningrad to Helsinki and back by Russian Post.
In the release there is an example on the basis of which it will be possible to understand how to use the stack in your applications. We will develop the educational base and work to make the adaptation of our solution to your projects as comfortable as possible.
Having dealt with peripheral issues, we proceed to consider the structure of the stack.
The logical structure of the MOAR stack contains several levels:
Interface layer - provides a direct connection to the nearest nodes via some physical or logical channel. Interface levels can be several, one for each physical or logical data exchange interface. The level either works with the interface driver, or it performs its role.
The link layer - selects the most appropriate method of communication (interface) with each of the nearest nodes and performs related tasks.
Routing level (“routing”) - provides algorithms for finding the most optimal data transfer routes.
View Level - provides cryptography and data partitioning, as well as inverse transformations.
Service Level - provides an API for using the MOAR stack from other applications.
At the moment, each level is executed in a separate thread of the main process, but for security purposes it is possible to separate the levels depending on the privileges necessary for their work.
Well, we proceed to the description of the installation process and configuration. First, download the repository, you can do it by reference , or, using git, go to the desired folder and execute the command:
Most of the directories in the MOAR repository stack have a special purpose:
The folder structure is more or less clear; let's proceed to compiling and building the project:
Go to the root folder:
and sequentially execute the following commands:
After a successful build, the config, lib and bin directories should appear in the root. In the current implementation, the installation into the system is not provided, however, the moard can be run as a daemon, and, of course, you can use screen or LSB scripts for autorun.
Consider the configuration files:
Along the path
Now consider the configs of the levels, by the way they are located at:
common fields for level configuration files:
When building and debugging the stack in Clion, you should pay attention to the location of the compiled files, depending on the IDE version it may differ, it is possible that the environment variable LD_LIBRARY_PATH can be set in the settings of the assembly target with the appropriate paths
Finally, we come to the first run of the stack. There are not many arguments to launch moard (just for this reason, --help xD is empty):
MOAR stack start sequence:
0. We read moard arguments, if on the way to -c there is no file we drop out with an error.
1. If the -c argument is not used, look for the default configuration file in
2. If the configuration file is found, load it, go to
3. Load the modules in the paths specified in
4. If a library with a level of this type has already been loaded, then subsequent attempts to load a level of the same type are ignored. (Except for interface)
5. Everything! You can interact with the stack API via the socket specified in
The MOAR stack is a software solution that can be installed on any device running Linux. We do not limit MOAR stack users to our solution only, and we want you to treat it as a tool for your own projects, and not as a platform with a rigidly defined architecture. Publishing technical documentation is only the first step. Forgive us, Arduino fans, but we believe that making our solutions without restrictions on existing development kits is more interesting and not much more difficult. And if someone decides to try to assemble another meteorological station with a soldering iron and a MOAR stack, then we will be happy.
With open source publishing the stack version for the MCU, the situation is more complicated. Unfortunately, we live in a world where you have to pay for food, and sometimes we ourselves want to eat. The stack under the MCU has a more specialized structure and purpose, which are not fully compatible with open source ideas, therefore, we intend to make solutions for MCUs commercial. As a result, the code published in open source will lag behind commercial versions by about a year.
Starting today, the MOAR stack will be in alpha stage for some time, and we do not recommend using it in work projects to avoid problems with their performance. For those who decide to try our stack, we suggest using repositories with source codes and documentation. There you can find recommendations for its use. We found the creation of a separate website or forum inappropriate at the moment: the available channels of communication will be sufficient for prompt editing and feedback.
For this, let me leave: we congratulate you on the New Year and for our part we promise to please you with new releases next year.
Let's get to the main point: what have we done about it? Immediately make a reservation: we will not compare the MOAR and IPv6 stack, because now talking about IPv6 is almost the same as talking about teenage sex: everyone talks about it, few people know anything about it and only a few have tried it .
A few words about our test node
We will call the node one device with one stack instance. The node was created to test the operation of the stack in relation to external sensors.
')
We needed the most transportable solution, and initially everything was packed in a simple cardboard box. But it was not enough for a long time, but we were annoyed to constantly open the box for information, and given that all the elements were attached to the wires, the complexity of use at one point overpowered laziness, and it was suggested to make a case. Access to a 3D printer quickly put an end to the question of how to make it. The test device turned out quite successful and made its way with us from Kaliningrad to Helsinki and back by Russian Post.
Examples
In the release there is an example on the basis of which it will be possible to understand how to use the stack in your applications. We will develop the educational base and work to make the adaptation of our solution to your projects as comfortable as possible.
Having dealt with peripheral issues, we proceed to consider the structure of the stack.
The logical structure of the MOAR stack contains several levels:
Interface layer - provides a direct connection to the nearest nodes via some physical or logical channel. Interface levels can be several, one for each physical or logical data exchange interface. The level either works with the interface driver, or it performs its role.
The link layer - selects the most appropriate method of communication (interface) with each of the nearest nodes and performs related tasks.
Routing level (“routing”) - provides algorithms for finding the most optimal data transfer routes.
View Level - provides cryptography and data partitioning, as well as inverse transformations.
Service Level - provides an API for using the MOAR stack from other applications.
At the moment, each level is executed in a separate thread of the main process, but for security purposes it is possible to separate the levels depending on the privileges necessary for their work.
Well, we proceed to the description of the installation process and configuration. First, download the repository, you can do it by reference , or, using git, go to the desired folder and execute the command:
git clone https://git@github.com:moarstack/moarstack.git Most of the directories in the MOAR repository stack have a special purpose:
./ - files presented in the root directory (such as CMakeLists.txt) are designed to build the entire project and all other projects in internal directories (sometimes located in one subdirectory, as is done for levels).
layers / - directories with headers (* .h) and source codes (* .c) for each level, including common files with source codes and header files for all levels. Also in this directory, you can add other levels to compile with the stack
interface /, channel /, routing /, presentation /, service / - directories with files with source codes and header files related only to a specific level.
shared / - files with definitions common to all levels.
libmoar / - source files and header files that can be used in other projects to link to the MOAR stack and use it for data transfer. Thus, these files implement the API functionality for the MOAR stack.
moard / - files with source codes and header files that combine all levels into a linux daemon
tools / - source files and header files for additional utilities using the MOAR stack, or ensuring the operation of the MOAR stack. For example, the mockit utility is a virtual data transmission medium that allows you to debug the work of several instances of the stack, taking into account the attenuation of the radio signal in the medium (in its simplest form).
The folder structure is more or less clear; let's proceed to compiling and building the project:
Go to the root folder:
d moarstack_linux and sequentially execute the following commands:
cmake . make After a successful build, the config, lib and bin directories should appear in the root. In the current implementation, the installation into the system is not provided, however, the moard can be run as a daemon, and, of course, you can use screen or LSB scripts for autorun.
Consider the configuration files:
Along the path
config/moarstack/ is the main configuration file moar.confmoardSettings.LogPath = /var/log/moard.log - the location of the log filemoardSettings.LayersEnabledDir = layers_enabled - directory relative to moar.conf where the configuration of the other layers is locatednodeaddress.address = 0123456789abcdef - node address in hex, 8 bytes (must be different for nodes, in the current implementation of the stack static addressing. In a strong simplification, this address can be represented as an analogue of the IP address in the TCP / IP stack)ifaceSocket.FileName = /tmp/moarIfaceChannel.sock - socket for interaction of interface levels with the channel levelserviceSocket.FileName = /tmp/moarServiceApi.sock - a socket for interaction of the service level with applications, the API works through itNow consider the configs of the levels, by the way they are located at:
config/<moardSettings.LayersEnabledDir>/*.conf - level configscommon fields for level configuration files:
libraryLocation.FileName = - the file name of the compiled dynamic library. It can be either a relative or full path, or just the file name. In the latter case, the search for the library in the file system is assigned to ld.so.When building and debugging the stack in Clion, you should pay attention to the location of the compiled files, depending on the IDE version it may differ, it is possible that the environment variable LD_LIBRARY_PATH can be set in the settings of the assembly target with the appropriate paths
Finally, we come to the first run of the stack. There are not many arguments to launch moard (just for this reason, --help xD is empty):
--help -h - in the future there will be a page with a description of the arguments--config=<filename.conf> -c <file.conf> - the name of the configuration file, besides the obvious, allows you to run multiple copies of the stack with different parametersMOAR stack start sequence:
0. We read moard arguments, if on the way to -c there is no file we drop out with an error.
1. If the -c argument is not used, look for the default configuration file in
../config/moarstack/moar.conf (if not found, we fall out with an error)2. If the configuration file is found, load it, go to
<moardSettings.LayersEnabledDir>/ and read there all the *.conf files there.3. Load the modules in the paths specified in
*.conf .4. If a library with a level of this type has already been loaded, then subsequent attempts to load a level of the same type are ignored. (Except for interface)
5. Everything! You can interact with the stack API via the socket specified in
serviceSocket.FileNameWhy did you choose Linux and why did you not include a stack for the MCU in the release?
The MOAR stack is a software solution that can be installed on any device running Linux. We do not limit MOAR stack users to our solution only, and we want you to treat it as a tool for your own projects, and not as a platform with a rigidly defined architecture. Publishing technical documentation is only the first step. Forgive us, Arduino fans, but we believe that making our solutions without restrictions on existing development kits is more interesting and not much more difficult. And if someone decides to try to assemble another meteorological station with a soldering iron and a MOAR stack, then we will be happy.
With open source publishing the stack version for the MCU, the situation is more complicated. Unfortunately, we live in a world where you have to pay for food, and sometimes we ourselves want to eat. The stack under the MCU has a more specialized structure and purpose, which are not fully compatible with open source ideas, therefore, we intend to make solutions for MCUs commercial. As a result, the code published in open source will lag behind commercial versions by about a year.
Feedback.
Starting today, the MOAR stack will be in alpha stage for some time, and we do not recommend using it in work projects to avoid problems with their performance. For those who decide to try our stack, we suggest using repositories with source codes and documentation. There you can find recommendations for its use. We found the creation of a separate website or forum inappropriate at the moment: the available channels of communication will be sufficient for prompt editing and feedback.
For this, let me leave: we congratulate you on the New Year and for our part we promise to please you with new releases next year.
Source: https://habr.com/ru/post/318342/
All Articles