Integration / D Bus Interview Questions
Explain the lifecycle of a D-Bus connection from handshake to bus registration?
A D-Bus connection goes through a defined sequence of steps before it can send or receive ordinary messages, distinct from the application-level method calls and signals that happen afterward.
flowchart TD
A[Open socket to bus address] --> B[SASL AUTH handshake, e.g. EXTERNAL]
B --> C[BEGIN sent, switches to D-Bus message stream]
C --> D[Client sends Hello method call to org.freedesktop.DBus]
D --> E[Bus daemon assigns unique connection name, e.g. :1.42]
E --> F[Connection can now send/receive method calls and signals]
F --> G[Optional: RequestName to claim a well-known name]
G --> H[Optional: AddMatch to subscribe to signals]
- The client opens a socket to the bus's transport address, typically a Unix domain socket path.
- It performs the SASL-based authentication handshake, most commonly the
EXTERNALmechanism relying on the kernel-verified UID. - After a successful
BEGIN, the socket switches into carrying the binary D-Bus message stream. - The client sends a
Hellomethod call to the bus daemon's own object, which is required before any other bus traffic is accepted. - The bus daemon replies with the connection's assigned unique name, such as
:1.42, formally admitting it onto the bus. - From this point the connection is fully live, and it can optionally call
RequestNameto claim a well-known name andAddMatchto subscribe to signals.
Which step must happen before any other bus traffic is accepted from a new connection?
The SASL handshake occurs:
More Related questions...
