Tools to create code to do IPC over MQTT
Project description
Stinger IPC
StingerIPC provides inter-process communications (IPC) between a server and multiple clients running on the same or separate hosts. It uses an MQTT server to pass messages between processes, implementing several IPC patterns: signals, properties, and proceedures.
Project Status
This project is in early stages of active development. You should not use it in any of your projects, both because it doesn't have enough features yet to be useful, and also because things will probably be horribly broken on future updates.
Interface Description
StingerIPC takes a interface description file (.singeripc), and will generate code and documentation from it. A very brief example of a interface description is:
stingeripc:
version: 0.0.7
interface:
name: Example
version: 0.0.1
signals:
foo:
payload:
- name: message
type: string
methods:
addNumbers:
arguments:
- name: left
type: integer
- name: right
type: integer
returnValues:
- name: sum
type: integer
First class code generation
From the StingerIPC description file, we directly generate server and client code for these languages: Python3, C++11, and Rust.
Server Code
From the above description file, StingerIPC generates server code, which can be used like this:
# Python
conn = MqttConnection('localhost', 1883)
server = ExampleServer(conn)
server.emit_foo("Hello World")
@server.handle_add_numbers
def add_numbers(left: int, right: int) -> int:
return left + right
// C++
auto conn = std::make_shared<DefaultConnection>("localhost", 1883);
ExampleServer server(conn);
server.emitFoo("Hello World").wait();
server.registerAddNumbersHandler([](int left, int right) -> int
{
return left + right;
});
// Rust
let connection = Connection::new(String::from("tcp://localhost:1883"));
let mut server = SignalOnlyServer::new(connection);
server.emit_foo("Hello World".to_string());
server.register_add_numbers_handler(|left, right| {
left + right
});
Client Code
From the above description file, StingerIPC generates client code which can be used like this:
# Python
conn = MqttConnection('localhost', 1883)
client = ExampleClient(conn)
@client.receive_foo
def print_foo_receipt(message):
print(f"Got a 'foo' signal with message: {message}")
future = client.add_numbers(1, 2)
timeout = 5
print(future.result(timeout))
// C++
auto conn = std::make_shared<DefaultConnection>("localhost", 1883);
ExampleClient client(conn);
client.registerFooCallback([](const std::string& message) {
std::cout << message << std::endl;
});
std::cout << "One plus three is " << client.addNumbers(1, 3).wait() << std::endl;
// Rust
let connection = Connection::new(String::from("tcp://localhost:1883"));
let mut client = ExampleClient::new(connection);
client.set_signal_recv_callbacks_for_foo(|message| {
println!("{}", message);
});
client.add_numbers(1, 4);
AsyncAPI and second-class code generation
AsyncAPI is a specification format for describing asynchronous message APIs. Since StingerIPC uses and abstracts asynchonous messages between server and clients, we can describe a StingerIPC system with an AsyncAPI document.
From that AsyncAPI document, we can generate code and documentation in additional languages. While this code generation won't implement our standard IPC design patterns, it does make accessing the communications more easy.
Inter-process communication (IPC)
The motivation for this project is that I've seen embedded Linux projects that run several daemons that need to talk to each other, and for whatever reasons D-Bus wasn't a good option.
So this project is a way for those daemons/programs to communicate with each other through an MQTT broker running on the same device. The design goals of this project have been tuned toward this use case.
That being said, there is nothing prohibiting Stinger-IPC to be used for RPC: remote proceedure calls. RPC typically involves being able to call into a system from a different system. That certainly can be done by having the remote systems connect into the same MQTT broker as the local system. However, this isn't the primary use case, and design goals aren't geared to make Stinger-IPC the best solution for RPC (though don't let that stop you from using it that way). Specifically, Stinger-IPC requires the server and all clients to be running the same version of code. For systems where all the software ships together, this usually isn't a problem, but could be a problem for systems with remote connections.
Comparison to gRPC
gRPC is probably a better solution for handling RPC and connections from remote clients. It does a much better job at handling compatibility between different versions, supporting a wider number of languages, and transports messages more efficiently.
But gRPC, as most typically deployed, provide some challenges for use inside an embedded Linux system. gRPC typically wants secured HTTP/2 connections, which are just overkill for communications within a single device. Additionally, the protobuf code generation is just more complicated.
Design goals
- Low learning curve.
- No fancy/tricky code. Generated code should look like a a human wrote it for humans to use it.
- Useable for embedded Linux systems.
- Be described by an AsyncAPI spec.
License
Generator Code
The stinger-ipc generator (Python scripts, templates, and related files) is licensed under the MIT License. See the LICENSE file for details.
Generated Code
Code generated by stinger-ipc is NOT subject to the MIT License. As a special exception, you may use, modify, and distribute code generated by stinger-ipc under any license of your choosing, including proprietary licenses, without attribution or restriction.
This exception applies to all output produced by running the stinger-ipc code generator, regardless of the input files or configuration used. You are free to:
- Use generated code in commercial projects
- Relicense generated code under any terms
- Modify and distribute without attribution
- Include in proprietary software
The templates in stingeripc/templates/ automatically include a license notice in generated files to clarify this.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file stinger_ipc-0.6.4.tar.gz.
File metadata
- Download URL: stinger_ipc-0.6.4.tar.gz
- Upload date:
- Size: 133.9 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: uv/0.9.12 {"installer":{"name":"uv","version":"0.9.12"},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"25.10","id":"questing","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
3e7f080019f48dbd44f21d9988d6e41d85c1b91abe4c3fac8f833334b996bdec
|
|
| MD5 |
ae4534a100b9aafe49dddb082704eba9
|
|
| BLAKE2b-256 |
87ff6dc6c7afeda583ff82ccfdcb583394c848ebb3f0d6173e528e89df686de4
|
File details
Details for the file stinger_ipc-0.6.4-py3-none-any.whl.
File metadata
- Download URL: stinger_ipc-0.6.4-py3-none-any.whl
- Upload date:
- Size: 171.6 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: uv/0.9.12 {"installer":{"name":"uv","version":"0.9.12"},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"25.10","id":"questing","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
927499411ba9d42f13f484f27cba9cf4ae92e88a6d667523d8f077d5052e8ad3
|
|
| MD5 |
be7742cfe935e950f310ae88fc8fe3c2
|
|
| BLAKE2b-256 |
b76b57d8dfc3e81a43dc698baa56952cf9d201b3112dec1f77a94d075d1b778f
|