D-BUS Specification

Following the mandatory fields, there are zero or more named fields (see the section called “Header Fields”), and then nul bytes padding the header such that its total length in bytes is a multiple of 8.

The header MUST begin with the following mandatory fields in the following order:

Types that can appear in the second byte of the header:

Flags that can appear in the third byte of the header:

In addition to the required header information mentioned in the section called “Header Encoding”, the header may contain zero or more named header fields. Future versions of this protocol specification may add new fields. Implementations must ignore fields they do not understand. Implementations must not invent their own header fields; only changes to this specification may introduce new header fields.

Header field names MUST consist of a single byte, possible values of which are defined below. Following the name, the field MUST have a type code represented as a single unsigned byte, and then a properly-aligned value of that type. See the section called “Message Arguments” for a description of how each type is encoded. If an implementation sees a header field name that it does not understand, it MUST ignore that field.

Here are the currently-defined named header fields:

To allow implementations to keep the header and the body in a single buffer while keeping data types aligned, the total length of the header must be a multiple of 8 bytes. To achieve this, the header MUST be padded with nul bytes to align its total length on an 8-byte boundary. The minimum number of padding bytes MUST be used. Because zero is an invalid field name, implementations can distinguish padding (which must be zero initialized) from additional named fields.

The message body is made up of arguments. Each argument is a type code, represented by a single unsigned byte, followed by the aligned value of the argument in a type-dependent format. Alignment padding between the typecode and the value is initialized to zero.

The types are encoded as follows:

The various names in D-BUS messages have some restrictions.

Each of the message types (METHOD_CALL, METHOD_RETURN, ERROR, and SIGNAL) has its own expected usage conventions and header fields.

            org.freedesktop.DBus.ActivateService (in STRING service_name, in UINT32 flags,
                                                  out UINT32 resultcode)
          

            unsigned int org::freedesktop::DBus::ActivateService (const char  *service_name, 
                                                                  unsigned int flags);
          

            void org::freedesktop::DBus::ActivateService (const char   *service_name, 
                                                          unsigned int  flags,
                                                          unsigned int *resultcode);
          

            org.freedesktop.DBus.ServiceLost (STRING service_name)
          

The protocol is a line-based protocol, where each line ends with \r\n. Each line begins with an all-caps ASCII command name containing only the character range [A-Z], a space, then any arguments for the command, then the \r\n ending the line. The protocol is case-sensitive. All bytes must be in the ASCII character set. Commands from the client to the server are as follows:

From server to client are as follows:

Immediately after connecting to the server, the client must send a single nul byte. This byte may be accompanied by credentials information on some operating systems that use sendmsg() with SCM_CREDS or SCM_CREDENTIALS to pass credentials over UNIX domain sockets. However, the nul byte MUST be sent even on other kinds of socket, and even on operating systems that do not require a byte to be sent in order to transmit credentials. The text protocol described in this document begins after the single nul byte. If the first byte received from the client is not a nul byte, the server may disconnect that client.

A nul byte in any context other than the initial byte is an error; the protocol is ASCII-only.

The credentials sent along with the nul byte may be used with the SASL mechanism EXTERNAL.

If an AUTH command has no arguments, it is a request to list available mechanisms. The server SHOULD respond with a REJECTED command listing the mechanisms it understands.

If an AUTH command specifies a mechanism, and the server supports said mechanism, the server SHOULD begin exchanging SASL challenge-response data with the client using DATA commands.

If the server does not support the mechanism given in the AUTH command, it SHOULD send a REJECTED command listing the mechanisms it does support.

If the [initial-response] argument is provided, it is intended for use with mechanisms that have no initial challenge (or an empty initial challenge), as if it were the argument to an initial DATA command. If the selected mechanism has an initial challenge, the server should reject authentication by sending REJECTED.

If authentication succeeds after exchanging DATA commands, an OK command should be sent to the client.

The first octet received by the client after the \r\n of the OK command MUST be the first octet of the authenticated/encrypted stream of D-BUS messages.

The first octet received by the server after the \r\n of the BEGIN command from the client MUST be the first octet of the authenticated/encrypted stream of D-BUS messages.

At any time up to sending the BEGIN command, the client may send a CANCEL command. On receiving the CANCEL command, the server MUST send a REJECTED command and abort the current authentication exchange.

The DATA command may come from either client or server, and simply contains a base64-encoded block of data to be interpreted according to the SASL mechanism in use.

Some SASL mechanisms support sending an "empty string"; FIXME we need some way to do this.

The BEGIN command acknowledges that the client has received an OK command from the server, and that the stream of messages is about to begin.

The first octet received by the server after the \r\n of the BEGIN command from the client MUST be the first octet of the authenticated/encrypted stream of D-BUS messages.

The REJECTED command indicates that the current authentication exchange has failed, and further exchange of DATA is inappropriate. The client would normally try another mechanism, or try providing different responses to challenges.

Optionally, the REJECTED command has a space-separated list of available auth mechanisms as arguments. If a server ever provides a list of supported mechanisms, it MUST provide the same list each time it sends a REJECTED message. Clients are free to ignore all lists received after the first.

The OK command indicates that the client has been authenticated, and that further communication will be a stream of D-BUS messages (optionally encrypted, as negotiated) rather than this protocol.

The first octet received by the client after the \r\n of the OK command MUST be the first octet of the authenticated/encrypted stream of D-BUS messages.

The client MUST respond to the OK command by sending a BEGIN command, followed by its stream of messages, or by disconnecting. The server MUST NOT accept additional commands using this protocol after the OK command has been sent.

The ERROR command indicates that either server or client did not know a command, does not accept the given command in the current context, or did not understand the arguments to the command. This allows the protocol to be extended; a client or server can send a command present or permitted only in new protocol versions, and if an ERROR is received instead of an appropriate response, fall back to using some other technique.

If an ERROR is sent, the server or client that sent the error MUST continue as if the command causing the ERROR had never been received. However, the the server or client receiving the error should try something other than whatever caused the error; if only canceling/rejecting the authentication.

This section documents the auth protocol in terms of a state machine for the client and the server. This is probably the most robust way to implement the protocol.

This section describes some new authentication mechanisms. D-BUS also allows any standard SASL mechanism of course.

          org.freedesktop.Peer.Ping ()
        

On receipt of the METHOD_CALL message org.freedesktop.Peer.Ping, an application should do nothing other than reply with a METHOD_RETURN as usual.

[FIXME this is just a bogus made-up method that isn't implemented or thought through, to save an example of table formatting for the argument descriptions]

          org.freedesktop.Props.Get (in STRING property_name,
                                     out ANY_OR_NIL property_value)
        

Message arguments:

The message bus accepts connections from one or more applications. Once connected, applications can send and receive messages from the message bus, as in the peer-to-peer case.

The message bus keeps track of a set of services. A service is simply a name, such as com.yoyodyne.Screensaver, which can be owned by one or more of the connected applications. The message bus itself always owns the special service org.freedesktop.DBus.

Services may have secondary owners. Secondary owners of a service are kept in a queue; if the primary owner of a service disconnects, or releases the service, the next secondary owner becomes the new owner of the service.

Messages may have a SERVICE field (see the section called “Header Fields”). When the message bus receives a message, if the SERVICE field is absent, the message is taken to be a standard peer-to-peer message and interpreted by the message bus itself. For example, sending an org.freedesktop.Peer.Ping message with no SERVICE will cause the message bus itself to reply to the ping immediately; the message bus would never make this message visible to other applications.

If the SERVICE field is present, then it indicates a request for the message bus to route the message. In the usual case, messages are routed to the owner of the named service. Messages may also be broadcast by sending them to the special service org.freedesktop.DBus.Broadcast. Broadcast messages are sent to all applications with message matching rules that match the message.

Continuing the org.freedesktop.Peer.Ping example, if the ping message were sent with a SERVICE name of com.yoyodyne.Screensaver, then the ping would be forwarded, and the Yoyodyne Corporation screensaver application would be expected to reply to the ping. If org.freedesktop.Peer.Ping were sent to org.freedesktop.DBus.Broadcast, then multiple applications might receive the ping, and all would normally reply to it.

A service is a name that identifies a certain application. Each application connected to the message bus has at least one service name assigned at connection time and returned in response to the org.freedesktop.DBus.Hello message. This automatically-assigned service name is called the application's base service. Base service names are unique and MUST never be reused for two different applications.

Ownership of the base service is a prerequisite for interaction with the message bus. It logically follows that the base service is always the first service that an application comes to own, and the last service that it loses ownership of.

Base service names must begin with the character ':' (ASCII colon character); service names that are not base service names must not begin with this character. (The bus must reject any attempt by an application to manually create a service name beginning with ':'.) This restriction categorically prevents "spoofing"; messages sent to a base service name will always go to a single application instance and that instance only.

An application can request additional service names to be associated with it using the org.freedesktop.DBus.AcquireService message. [FIXME what service names are allowed; ASCII or unicode; length limit; etc.]

[FIXME this needs more detail, and should move the service-related message descriptions up into this section perhaps] Service ownership handling can be specified in the flags part of the org.freedesktop.DBus.AcquireService message. If an application specifies the DBUS_SERVICE_FLAGS_PROHIBIT_REPLACEMENT flag, then all applications trying to acquire the service will be put in a queue. When the primary owner disconnects from the bus or removes ownership from the service, the next application in the queue will be the primary owner. If the DBUS_SERVICE_FLAGS_PROHIBIT_REPLACEMENT flag is not specified, then the primary owner will lose ownership whenever another application requests ownership of the service.

When a client disconnects from the bus, all the services that the clients own are deleted, or in the case of a service that prohibits replacement, ownership is transferred to the next client in the queue, if any.

When a message is received by the message bus, the message's sndr header field MUST be set to the base service of the application which sent the message. If the service already has a sndr field, the pre-existing field is replaced. This rule means that a replies are always sent to the base service name, i.e. to the same application that sent the message being replied to.

[FIXME go into detail about broadcast, multicast, unicast, etc.]

Activation means to locate a service owner for a service that is currently unowned. For now, it means to launch an executable that will take ownership of a particular service.

To find an executable corresponding to a particular service, the bus daemon looks for service description files. Service description files define a mapping from service names to executables. Different kinds of message bus will look for these files in different places, see the section called “Well-known Message Bus Instances”.

[FIXME the file format should be much better specified than "similar to .desktop entries" esp. since desktop entries are already badly-specified. ;-)] Service description files have the ".service" file extension. The message bus will only load service description files ending with .service; all other files will be ignored. The file format is similar to that of desktop entries. All service description files must be in UTF-8 encoding. To ensure that there will be no name collisions, service files must be namespaced using the same mechanism as messages and service names.

            # Sample service description file
            [D-BUS Service]
            Name=org.gnome.ConfigurationDatabase
            Exec=/usr/libexec/gconfd-2
          

When an application requests a service to be activated, the bus daemon tries to find it in the list of activation entries. It then tries to spawn the executable associated with it. If this fails, it will report an error. [FIXME what happens if two .service files offer the same service; what kind of error is reported, should we have a way for the client to choose one?]

The executable launched will have the environment variable DBUS_ACTIVATION_ADDRESS set to the address of the message bus so it can connect and register the appropriate services.

The executable being launched may want to know whether the message bus activating it is one of the well-known message buses (see the section called “Well-known Message Bus Instances”). To facilitate this, the bus MUST also set the DBUS_ACTIVATION_BUS_TYPE environment variable if it is one of the well-known buses. The currently-defined values for this variable are system for the systemwide message bus, and session for the per-login-session message bus. The activated executable must still connect to the address given in DBUS_ACTIVATION_ADDRESS, but may assume that the resulting connection is to the well-known bus.

[FIXME there should be a timeout somewhere, either specified in the .service file, by the client, or just a global value and if the client being activated fails to connect within that timeout, an error should be sent back.]

Two standard message bus instances are defined here, along with how to locate them and where their service files live.

The special message bus service org.freedesktop.DBus responds to a number of messages, allowing applications to interact with the message bus.

            STRING Hello ()
          

            STRING_ARRAY ListServices ()
          

            BOOLEAN ServiceExists (in STRING service_name)
          

            UINT32 AcquireService (in STRING service_name)
          

            ServiceAcquired (in STRING service_name)
          

            ServiceLost (in STRING service_name)
          

            ServiceCreated (in STRING service_name)
          

            ServiceDeleted (in STRING service_name)
          

            UINT32 ActivateService (in STRING service_name, in UINT32 flags)
          

            void NoMemory ()
          

            void ServiceDoesNotExist (in STRING error)