OpenSync BUS
- Shibshankar Talukder
General
Currently OpenSync relies on OVSDB config/status tables and custom unix sockets apis for inter-process communication. We have requests from multiple sources to support a BUS architecture in OpenSync. Introducing a BUS in opensync should help us in:
moving to a modular architecture
standardize the IPC between OpenSync managers
easier integration into various platforms (OpenWRT, RDK, PRPL,...)
adding data models other than OVSDB such as TR181
Northbound API
No northbound API changes - no OVSDB or MQTT changes.
Southbound API
Since we intend to support different underlying APIs, we will use a wrapper library that sits on top of the UBUS/RBUS APIs. The name of the OpenSync wrapper library is osbus. Below are described bus concepts and osbus API mappings.
BUS message handling
The messages that are exchanged on the BUS are a JSON-like structure. This is valid for both ubus and rbus. However the message is not a textual representation of a JSON but a binary one and it supports some additional field types such as binary buffers. For OpenSync we’ll introduce our own message api that can translate a messages between different representations - opensync internal, ubus, rbus, json
OpenSync | UBUS | RBUS |
osbus_msg_new_*() osbus_msg_get_*() osbus_msg_set_*() osbus_msg_add_*() osbus_msg_map_*() | blob_buf_*() blobmsg_data_*() blobmsg_get_*() blobmsg_add_*() blobmsg_open_*() blobmsg_close_*() | rbusObject_*() rbusProperty_*() rbusValue_*()
|
Method invocation (1:1)
Method invocation uses a 1 to 1 communication delivery with a request and a reply sent back.
OpenSync | UBUS | RBUS |
osbus_method_invoke() | ubus_invoke() | rbusMethod_Invoke() |
Events (1:N)
Events provide a one to N communication delivery, with no reply. Unfortunately ubus and rbus use different naming conventions for this but we’ll pick rbus naming for this.
OpenSync | UBUS | RBUS |
osbus_event_subscribe() osbus_event_publish()
| ubus_register_subscriber() ubus_unregister_subscriber() ubus_subscribe() ubus_unsubscribe() ubus_notify() ubus_notify_async() | rbusEvent_SubscribeEx() rbusEvent_UnsubscribeEx() rbusEvent_Publish()
|
Topics (M:N)
Topics provide a M to N communication delivery, with no reply. Unfortunately ubus and rbus use different naming conventions for this but we’ll pick rbus naming for this.
OpenSync | UBUS | RBUS |
osbus_topic_listen() osbus_topic_send()
| ubus_register_event_handler() ubus_unregister_event_handler() ubus_send_event() | rbusMessage_AddListener() rbusMessage_RemoveListener() rbusMessage_Send() |
Data Model
A data model provides a set of parameters which can be set, get and subscribed to change events. This concept is fully integrated in RBUS but not in UBUS. In UBUS this is implemented as a set of method calls, so there is no standardized interface for this in UBUS.
OpenSync | UBUS | RBUS |
not used
| ubus_invoke()
| rbus_regDataElements() rbus_unregDataElements() rbus_get() rbus_set() rbusTable_addRow() rbusTable_removeRow() RbusTable_getRowNames() rbusElementInfo_get() |
Resources
[openwrt] process communication using ubus
Requirements
Here write what kind of OpenSync requirements are needed, like:
SDK with UBUS or RBUS enabled (OpenWRT has ubus support out of the box, for BCM SDK changes are done as patches on top of the SDK)
RAM: 512MB or more
CPU: quad-core or better