Crates.io | krossbar-bus-lib |
lib.rs | krossbar-bus-lib |
version | 0.5.7 |
source | src |
created_at | 2024-05-15 13:34:39.48979 |
updated_at | 2024-06-07 12:43:50.067206 |
description | Krossbar bus library |
homepage | https://krossbar.rs |
repository | https://github.com/krossbar-platform/krossbar-bus |
max_upload_size | |
id | 1241087 |
size | 127,657 |
A library to register and connect Krossbar services
Krossbar services utilize UDS to communicate with each other. Krossbar hub acts as a point of rendezvous for the services, checking permissions and connecting counterparties.
The library uses krossbar_rpc::rpc::Rpc connections to comunicate.
To register a service call Service::new. This makes a call to the hub trying to register a service with a given name.
Service exposes two subsets of methods: to act as a message source, or a message consumer:
To act as a message source you have a bunch of method to register service endpoints:
To act as as message consumer, you have to connect to a client using Service::connect. As expected, hub needs to check if you are allowed to connect to the client, but after you've connected, there a couple of methods you can use:
In order to receive incoming connection and messages you need to poll the Service. There are two methods to do this:
Using Service::run if you don't need a service handle anymore. This is much more convenient way. You can spawn a task to just poll the service in a loop:
use std::path::PathBuf;
use tokio;
use krossbar_bus_lib::service::Service;
async fn example() {
let mut service = Service::new("com.echo.service", &PathBuf::from("/var/run/krossbar.hub.socket"))
.await
.expect("Failed to register service");
service
.register_method("method", |client_name, value: i32| async move {
println!("Client name: {client_name}");
return format!("Hello, {}", value);
})
.expect("Failed to register method");
tokio::spawn(service.run());
}
Using Service::poll if you still need a service handle to make new connections, or register new endpoints. You can use future combinators to poll both: service handle and endpoint handles.
use std::path::PathBuf;
use futures::StreamExt;
use tokio;
use krossbar_bus_lib::service::Service;
async fn example() {
let mut service = Service::new("com.signal.subscriber", &PathBuf::from("/var/run/krossbar.hub.socket"))
.await
.expect("Failed to register service");
let mut client = service.connect("com.signalling.service")
.await
.expect("Failed to register to a service");
let mut subscription = client.subscribe::<String>("signal")
.await
.expect("Failed ot subscribe ot a signal");
tokio::select! {
value = subscription.next() => {
println!("Signal data: {value:?}");
},
_ = service.poll() => {}
}
}
To be able to register as a service and receive connections, you need to maintain a service file for each of the services. The file filename is a service name. File content is a JSON, which contains a path to a binary, which is allowed to register the service name, and a list of allowed connections. Both support globs. See examples for a bunch of examples.
Having monitor
feature allows you to use Krossbar Monitor to monitor service communication. Refer to the corresponding crate for usage.
Having inspection
feature allows you to use Krossbar Connect tool to inspect service endpoints. Refer to the corresponding crate for usage.
Also, the tool allows you to call or subscribe to a service using CLI.
See examples dir for usage examples