CCSP Message Bus

CCSP Message Bus is used by the CCSP components to communicate with each other and send notifications to registered subscribers in a single processor environment. CCSP message bus uses D-Bus/R-Bus for IPC.

D-Bus

This section is not intended to be a tutorial on D-Bus. However there are a few points that need to be well understood.

In D-Bus, the bus is a central concept. It is the channel through which applications can do the method calls, send signals and listen to signals. There are two predefined buses: the session bus and the system bus.

• The session bus is meant for communication between applications that are connected to the same session
• The system bus is meant for communication when applications (or services) running with disparate sessions wish to communicate with each other. Most common use for this bus is sending system wide notifications when system wide events occur.

Normally only one system bus will exist, but there can be several session buses.

A bus exists in the system in the form of a bus daemon, a process that specializes in passing messages from a process to another. Sending a message using D-Bus will always involve the following steps (under normal conditions):

• Creation and sending of the message to the bus daemon. This will cause at minimum two context switches.
• Processing of the message by the bus daemon and forwarding it to the target process. This will again cause at minimum two context switches.
• The target component will receive the message. Depending on the message type, it will either need to acknowledge it, respond with a reply or ignore it. Acknowledgement or replies will cause further context switches.

In addition to the context switches, described above, the data from the “replies” gets copied when it enters the D-Bus library, copied again as it enters the sockets to the bus, which then sends it into another socket to the client, which then makes a copy. These copies can be really expensive.

Coupled together, the above rules indicate that D-Bus is not efficient in transferring large amounts of data between processes.

D-Bus, however, provides a useful feature that allows passing UNIX file descriptors over the bus. The idea is to use DBus for flexible IPC method calls between a client and a server and a dedicated pipe for passing large results from the server back to the client. This allows very fast transmission rates, while keeping the comfort of using DBus for inter process method calls. The file descriptor may even point to a shared memory object allocated via shm_open (). Data Plane deals with this in greater detail.

D-Bus Bindings

D-Bus Bindings must be auto generated using a D-Bus binding tool such as dbus-binding-tool from D-Bus-Glib, using the introspection XML file that defines the component’s interface and supported signals. The Adapter bindings should only be thin glue for bridging Component interfaces. In other words, there should not be any component functionality directly implemented in the bindings, other than just calling into the component’s interface.

<D-Bus Arc diagram>

R-Bus

RBus is a 3 layered RPC communication bus.

• At the lowest layer, it is rtMessage, which provides basic messaging capabilities across Unix domain or TCP sockets.
• Above that is "rbus-core", which is an intermediate layer that offers RPC and eventing capabilities.
• At the top is a simple, unified and powerful, public facing Bus APIs (known as rbus APIs), meant to be used by different apps.
• Rbus daemon is the rtMessage routing daemon.

Features of R-Bus

• Simplified APIs
• Pub / Sub (event / notification) support
• Methods support
• Aligns well with TR 369 (USP)

<R-Bus arc diagram>