MQTT / UDP, Pre-Spring Results: Remote Configuration and Digital Signature

Winter is ending, and this is a reason to draw another line and tell what's new in MQTT / UDP.

For starters, links to previous intro and article .

Thanks to everyone who responded with interest and separately to those who shared their thoughts. You helped me a lot with the digital signature approach. So, what has changed in a big way:

• A flexible protocol extension mechanism appeared: Tagged Tail Records, TTRs
• On its basis, a digital signature package was made.
• The mechanism of remote component configuration is made.
• Raised the full CI cycle: assembly, unit tests, end-to-end protocol tests (4 * 4 programming languages)
• The C implementation now supports different architectures and can integrate with different operating systems and monitors.
• There are public packages for Python and Lois, although, of course, they are already outdated.

Well, a lot of the little things: integration with OpenHAB, config files and logging, checking compatibility with the cloud MQTT service, made a test case for Wemos D1 (NodeMCU), made a test case for atmega128 + ethernet (not arduino), made an example of a protocol connector on Java (CCU825), made an example of a controller informer in the desktop tray (at last I can turn on the light in the room with two mouse clicks :), and more.

Now in order.

Tagged Tail Entries

I felt cramped in the MQTT package. I added tailing additives to the package in the form of tag-length-content, in which you can now put the necessary data. Today it is the package id, the package id to which we respond (for QoS, this is still in operation) and the digital signature, if enabled. The date-time is also planned in milliseconds of the moment of measuring the magnitude and the moment of sending the packet (as a palliative of the moment of measurement), and then arbitrary extensions are possible within the framework of the UDP packet size.

(SVG is not inserted, the illustration is here )

It already works everywhere except Lua. (Actually, Lua disappointed me, and only NodeMCU keeps it, and then I will try to go to Python there).

Digital signature

I was afraid to approach this weight, but after the appearance of tag extensions everything became quite simple. The sent package is signed according to the HMAC MD5 standard (I considered others too long for short UDP packets), a check is made at the entrance. Whether or not to accept the package without a signature is left to the application code. True, in Java there is a switch "reject all unsigned", but this seems to be maximalism.

Remote configuration

In fact, everything is simple again: there is a desktop program (Java, it works everywhere), which makes a request (SUBSCRIBE package) for a topic of a certain type ( $SYS/conf/# ). All nodes that can be remotely configured respond to the current values ​​of the configurable parameters. The program from this synthesizes a simple UI with names and input fields, the user changes the settings, the commands for updating fly back. The entire infrastructure in the libraries, from the side of the application code, you only need to give a list of parameters and be able to write / read them to a file or NVRAM.

Architecture and system-dependent code for C

Now you can add settings for the architecture (toolchain) and glue code for the target OS or monitor. This is tested on three configurations — unix / cygwin (./configure), mingw, and NUT / OS (without configure).

Well, and probably for today. There is no time for details, but if there is interest, I will write in more detail.

Documentation for the project , more than aspirations, is still quite relevant, and it is decently written there. Sorry for the lack of the Russian language, but I don’t have much time for this, I would like to translate based on the infrastructure, but I haven’t found any acceptable public service (online editor) for translating the paragraph into a paragraph.

Well, the repository itself .