The following communication patterns are supported out-of-the-box:
The following channels are supported:
async channels between threads/futures (Rust only)
UNIX sockets (local machine, Linux/BSD)
TCP sockets (Linux/BSD/Windows)
A client should register with a name “group.subgroup.client” (subgroups are optional). The client’s name can not start with dot (“.”, reserved for internal broker clients) if registered via IPC.
The client’s name must be unique, otherwise the broker refuses the registration.
Broadcast messages are sent to multiple clients at once. Use “?” for any part of the path, “*” as the ending for wildcards. E.g.:
?.test.* - the message is sent to clients g1.test.client1, g1.test.subgroup.client2 etc.
Use MQTT-format for topics: “+” for any part of the path, “#” as the ending for wildcards. E.g. a client, subscribed to +/topic/# receives publications sent to x/topic/event, x/topic/sub/event etc.
BUS/RT frames have 4 types of QoS:
No (0) - does not need confirmation, non-real-time
Processed (1) - needs confirmation from the broker, non-real-time
Realtime (2) - does not need confirmation, real-time
RealtimeProcessed (3) - needs confirmation from the broker, real-time
When a real-time frame is send to a socket, its write buffer is flushed immediately. Otherwise, a “buf_ttl” delay may occur (>1ms), unless any data is sent after and the buffer is flushed automatically.
BUS/RT has a very simple optional security model in favor of simplicity and speed. Also, BUS/RT is not designed to work via unstable connections, all clients should be connected either from the local machine or using high-speed reliable local network communications.
If you need a pub/sub server for a wide area network, try PSRT - industrial Pub/Sub for WAN.
ipc - enable IPC client
rpc - enable optional RPC layer
broker - enable broker
full - IPC+RPC+broker
server - build stand-alone broker server
cli - build CLI tool
std-alloc - forcibly use the standard memory allocator for server/cli (enable in case of problems with jemalloc)
Use “Realtime” or “RealtimeProcessed” QoS for softly-loaded networks to get minimal latencies.
Use high-capacity queues (both client and server) to deal with short high-load peaks.
For permanently loaded networks, the opposite strategy is recommended - keep queues as small as possible (256-512 elements), otherwise the broker can be easily flooded with more active clients.
If large payloads are expected, consider to increase client/server buffers.