Explain the internal working of dbus-broker's message dispatch?

dbus-broker was built specifically to remove the userspace bottlenecks present in the reference dbus-daemon's message routing, and its internal design leans heavily on splitting work between a lightweight controller process and the kernel itself wherever possible.

Rather than every message being individually copied and re-sent by the daemon to each recipient in userspace, dbus-broker is structured to let the kernel's own AF_UNIX socket machinery do as much of the heavy lifting as it can, minimizing the number of userspace copies and context switches per message. It also splits responsibilities internally between a privileged controller that manages policy, name ownership, and activation, and per-connection worker logic that handles the actual message forwarding, so that policy decisions don't have to be re-evaluated on the hot path for every single message once a connection's permissions are established.

The practical result is that under heavy signal or method-call load, especially with many connections and frequent broadcasts, dbus-broker shows measurably lower CPU overhead and latency than the reference implementation, which is the primary reason distributions adopted it as the default even though it remains wire-protocol compatible with plain dbus-daemon clients.