dbus-1.10.6/doc/dcop-howto.txt 0000644 0001750 0001750 00000051320 12602773110 016127 0 ustar 00smcv smcv 0000000 0000000 DCOP: Desktop COmmunications Protocol
Preston Brown
October 14, 1999
Revised and extended by Matthias Ettrich
Mar 29, 2000
Extended with DCOP Signals by Waldo Bastian
Feb 19, 2001
Motivation and Background:
--------------------------
The motivation behind building a protocol like DCOP is simple. For
the past year, we have been attempting to enable interprocess
communication between KDE applications. KDE already has an extremely
simple IPC mechanism called KWMcom, which is (was!) used for communicating
between the panel and the window manager for instance. It is about as
simple as it gets, passing messages via X Atoms. For this reason it
is limited in the size and complexity of the data that can be passed
(X atoms must be small to remain efficient) and it also makes it so
that X is required. CORBA was thought to be a more effective IPC/RPC
solution. However, after a year of attempting to make heavy use of
CORBA in KDE, we have realized that it is a bit slow and memory
intensive for simple use. It also has no authentication available.
What we really needed was an extremely simple protocol with basic
authorization, along the lines of MIT-MAGIC-COOKIE, as used by X. It
would not be able to do NEARLY what CORBA was able to do, but for the
simple tasks required it would be sufficient. Some examples of such
tasks might be an application sending a message to the panel saying,
"I have started, stop displaying the 'application starting' wait
state," or having a new application that starts query to see if any
other applications of the same name are running. If they are, simply
call a function on the remote application to create a new window,
rather than starting a new process.
Implementation:
---------------
DCOP is a simple IPC/RPC mechanism built to operate over sockets.
Either unix domain sockets or tcp/ip sockets are supported. DCOP is
built on top of the Inter Client Exchange (ICE) protocol, which comes
standard as a part of X11R6 and later. It also depends on Qt, but
beyond that it does not require any other libraries. Because of this,
it is extremely lightweight, enabling it to be linked into all KDE
applications with low overhead.
Model:
------
The model is simple. Each application using DCOP is a client. They
communicate to each other through a DCOP server, which functions like
a traffic director, dispatching messages/calls to the proper
destinations. All clients are peers of each other.
Two types of actions are possible with DCOP: "send and forget"
messages, which do not block, and "calls," which block waiting for
some data to be returned.
Any data that will be sent is serialized (marshalled, for you CORBA
types) using the built-in QDataStream operators available in all of
the Qt classes. This is fast and easy. In fact it's so little work
that you can easily write the marshalling code by hand. In addition,
there's a simple IDL-like compiler available (dcopidl and dcopidl2cpp)
that generates stubs and skeletons for you. Using the dcopidl compiler
has the additional benefit of type safety.
This HOWTO describes the manual method first and covers the dcopidl
compiler later.
Establishing the Connection:
----------------------------
KApplication has gained a method called "KApplication::dcopClient()"
which returns a pointer to a DCOPClient instance. The first time this
method is called, the client class will be created. DCOPClients have
unique identifiers attached to them which are based on what
KApplication::name() returns. In fact, if there is only a single
instance of the program running, the appId will be equal to
KApplication::name().
To actually enable DCOP communication to begin, you must use
DCOPClient::attach(). This will attempt to attach to the DCOP server.
If no server is found or there is any other type of error, attach()
will return false. KApplication will catch a dcop signal and display an
appropriate error message box in that case.
After connecting with the server via DCOPClient::attach(), you need to
register this appId with the server so it knows about you. Otherwise,
you are communicating anonymously. Use the
DCOPClient::registerAs(const QCString &name) to do so. In the simple
case:
/*
* returns the appId that is actually registered, which _may_ be
* different from what you passed
*/
appId = client->registerAs(kApp->name());
If you never retrieve the DCOPClient pointer from KApplication, the
object will not be created and thus there will be no memory overhead.
You may also detach from the server by calling DCOPClient::detach().
If you wish to attach again you will need to re-register as well. If
you only wish to change the ID under which you are registered, simply
call DCOPClient::registerAs() with the new name.
KUniqueApplication automatically registers itself to DCOP. If you
are using KUniqueApplication you should not attach or register
yourself, this is already done. The appId is by definition
equal to kapp->name(). You can retrieve the registered DCOP client
by calling kapp->dcopClient().
Sending Data to a Remote Application:
-------------------------------------
To actually communicate, you have one of two choices. You may either
call the "send" or the "call" method. Both methods require three
identification parameters: an application identifier, a remote object,
a remote function. Sending is asynchronous (i.e. it returns immediately)
and may or may not result in your own application being sent a message at
some point in the future. Then "send" requires one and "call" requires
two data parameters.
The remote object must be specified as an object hierarchy. That is,
if the toplevel object is called "fooObject" and has the child
"barObject", you would reference this object as "fooObject/barObject".
Functions must be described by a full function signature. If the
remote function is called "doIt", and it takes an int, it would be
described as "doIt(int)". Please note that the return type is not
specified here, as it is not part of the function signature (or at
least the C++ understanding of a function signature). You will get
the return type of a function back as an extra parameter to
DCOPClient::call(). See the section on call() for more details.
In order to actually get the data to the remote client, it must be
"serialized" via a QDataStream operating on a QByteArray. This is how
the data parameter is "built". A few examples will make clear how this
works.
Say you want to call "doIt" as described above, and not block (or wait
for a response). You will not receive the return value of the remotely
called function, but you will not hang while the RPC is processed either.
The return value of send() indicates whether DCOP communication succeeded
or not.
QByteArray data;
QDataStream arg(data, IO_WriteOnly);
arg << 5;
if (!client->send("someAppId", "fooObject/barObject", "doIt(int)",
data))
qDebug("there was some error using DCOP.");
OK, now let's say we wanted to get the data back from the remotely
called function. You have to execute a call() instead of a send().
The returned value will then be available in the data parameter "reply".
The actual return value of call() is still whether or not DCOP
communication was successful.
QByteArray data, replyData;
QCString replyType;
QDataStream arg(data, IO_WriteOnly);
arg << 5;
if (!client->call("someAppId", "fooObject/barObject", "doIt(int)",
data, replyType, replyData))
qDebug("there was some error using DCOP.");
else {
QDataStream reply(replyData, IO_ReadOnly);
if (replyType == "QString") {
QString result;
reply >> result;
print("the result is: %s",result.latin1());
} else
qDebug("doIt returned an unexpected type of reply!");
}
N.B.: You cannot call() a method belonging to an application which has
registered with an unique numeric id appended to its textual name (see
dcopclient.h for more info). In this case, DCOP would not know which
application it should connect with to call the method. This is not an issue
with send(), as you can broadcast to all applications that have registered
with appname- by using a wildcard (e.g. 'konsole-*'), which
will send your signal to all applications called 'konsole'.
Receiving Data via DCOP:
------------------------
Currently the only real way to receive data from DCOP is to multiply
inherit from the normal class that you are inheriting (usually some
sort of QWidget subclass or QObject) as well as the DCOPObject class.
DCOPObject provides one very important method: DCOPObject::process().
This is a pure virtual method that you must implement in order to
process DCOP messages that you receive. It takes a function
signature, QByteArray of parameters, and a reference to a QByteArray
for the reply data that you must fill in.
Think of DCOPObject::process() as a sort of dispatch agent. In the
future, there will probably be a precompiler for your sources to write
this method for you. However, until that point you need to examine
the incoming function signature and take action accordingly. Here is
an example implementation.
bool BarObject::process(const QCString &fun, const QByteArray &data,
QCString &replyType, QByteArray &replyData)
{
if (fun == "doIt(int)") {
QDataStream arg(data, IO_ReadOnly);
int i; // parameter
arg >> i;
QString result = self->doIt (i);
QDataStream reply(replyData, IO_WriteOnly);
reply << result;
replyType = "QString";
return true;
} else {
qDebug("unknown function call to BarObject::process()");
return false;
}
}
Receiving Calls and processing them:
------------------------------------
If your applications is able to process incoming function calls
right away the above code is all you need. When your application
needs to do more complex tasks you might want to do the processing
out of 'process' function call and send the result back later when
it becomes available.
For this you can ask your DCOPClient for a transactionId. You can
then return from the 'process' function and when the result is
available finish the transaction. In the mean time your application
can receive incoming DCOP function calls from other clients.
Such code could like this:
bool BarObject::process(const QCString &fun, const QByteArray &data,
QCString &, QByteArray &)
{
if (fun == "doIt(int)") {
QDataStream arg(data, IO_ReadOnly);
int i; // parameter
arg >> i;
QString result = self->doIt(i);
DCOPClientTransaction *myTransaction;
myTransaction = kapp->dcopClient()->beginTransaction();
// start processing...
// Calls slotProcessingDone when finished.
startProcessing( myTransaction, i);
return true;
} else {
qDebug("unknown function call to BarObject::process()");
return false;
}
}
slotProcessingDone(DCOPClientTransaction *myTransaction, const QString &result)
{
QCString replyType = "QString";
QByteArray replyData;
QDataStream reply(replyData, IO_WriteOnly);
reply << result;
kapp->dcopClient()->endTransaction( myTransaction, replyType, replyData );
}
DCOP Signals
------------
Sometimes a component wants to send notifications via DCOP to other
components but does not know which components will be interested in these
notifications. One could use a broadcast in such a case but this is a very
crude method. For a more sophisticated method DCOP signals have been invented.
DCOP signals are very similair to Qt signals, there are some differences
though. A DCOP signal can be connected to a DCOP function. Whenever the DCOP
signal gets emitted, the DCOP functions to which the signal is connected are
being called. DCOP signals are, just like Qt signals, one way. They do not
provide a return value.
A DCOP signal originates from a DCOP Object/DCOP Client combination (sender).
It can be connected to a function of another DCOP Object/DCOP Client
combination (receiver).
There are two major differences between connections of Qt signals and
connections of DCOP signals. In DCOP, unlike Qt, a signal connections can
have an anonymous sender and, unlike Qt, a DCOP signal connection can be
non-volatile.
With DCOP one can connect a signal without specifying the sending DCOP Object
or DCOP Client. In that case signals from any DCOP Object and/or DCOP Client
will be delivered. This allows the specification of certain events without
tying oneself to a certain object that implementes the events.
Another DCOP feature are so called non-volatile connections. With Qt signal
connections, the connection gets deleted when either sender or receiver of
the signal gets deleted. A volatile DCOP signal connection will behave the
same. However, a non-volatile DCOP signal connection will not get deleted
when the sending object gets deleted. Once a new object gets created with
the same name as the original sending object, the connection will be restored.
There is no difference between the two when the receiving object gets deleted,
in that case the signal connection will always be deleted.
A receiver can create a non-volatile connection while the sender doesn't (yet)
exist. An anonymous DCOP connection should always be non-volatile.
The following example shows how KLauncher emits a signal whenever it notices
that an application that was started via KLauncher terminates.
QByteArray params;
QDataStream stream(params, IO_WriteOnly);
stream << pid;
kapp->dcopClient()->emitDCOPSignal("clientDied(pid_t)", params);
The task manager of the KDE panel connects to this signal. It uses an
anonymous connection (it doesn't require that the signal is being emitted
by KLauncher) that is non-volatile:
connectDCOPSignal(0, 0, "clientDied(pid_t)", "clientDied(pid_t)", false);
It connects the clientDied(pid_t) signal to its own clientDied(pid_t) DCOP
function. In this case the signal and the function to call have the same name.
This isn't needed as long as the arguments of both signal and receiving function
match. The receiving function may ignore one or more of the trailing arguments
of the signal. E.g. it is allowed to connect the clientDied(pid_t) signal to
a clientDied(void) DCOP function.
Using the dcopidl compiler
---------------------
dcopidl makes setting up a DCOP server easy. Instead of having to implement
the process() method and unmarshalling (retrieving from QByteArray) parameters
manually, you can let dcopidl create the necessary code on your behalf.
This also allows you to describe the interface for your class in a
single, separate header file.
Writing an IDL file is very similar to writing a normal C++ header. An
exception is the keyword 'ASYNC'. It indicates that a call to this
function shall be processed asynchronously. For the C++ compiler, it
expands to 'void'.
Example:
#ifndef MY_INTERFACE_H
#define MY_INTERFACE_H
#include
class MyInterface : virtual public DCOPObject
{
K_DCOP
k_dcop:
virtual ASYNC myAsynchronousMethod(QString someParameter) = 0;
virtual QRect mySynchronousMethod() = 0;
};
#endif
As you can see, you're essentially declaring an abstract base class, which
virtually inherits from DCOPObject.
If you're using the standard KDE build scripts, then you can simply
add this file (which you would call MyInterface.h) to your sources
directory. Then you edit your Makefile.am, adding 'MyInterface.skel'
to your SOURCES list and MyInterface.h to include_HEADERS.
The build scripts will use dcopidl to parse MyInterface.h, converting
it to an XML description in MyInterface.kidl. Next, a file called
MyInterface_skel.cpp will automatically be created, compiled and
linked with your binary.
The next thing you have to do is to choose which of your classes will
implement the interface described in MyInterface.h. Alter the inheritance
of this class such that it virtually inherits from MyInterface. Then
add declarations to your class interface similar to those on MyInterface.h,
but virtual, not pure virtual.
Example:
class MyClass: public QObject, virtual public MyInterface
{
Q_OBJECT
public:
MyClass();
~MyClass();
ASYNC myAsynchronousMethod(QString someParameter);
QRect mySynchronousMethod();
};
Note: (Qt issue) Remember that if you are inheriting from QObject, you must
place it first in the list of inherited classes.
In the implementation of your class' ctor, you must explicitly initialize
those classes from which you are inheriting from. This is, of course, good
practise, but it is essential here as you need to tell DCOPObject the name of
the interface which your are implementing.
Example:
MyClass::MyClass()
: QObject(),
DCOPObject("MyInterface")
{
// whatever...
}
Now you can simply implement the methods you have declared in your interface,
exactly the same as you would normally.
Example:
void MyClass::myAsynchronousMethod(QString someParameter)
{
qDebug("myAsyncMethod called with param `" + someParameter + "'");
}
It is not necessary (though very clean) to define an interface as an
abstract class of its own, like we did in the example above. We could
just as well have defined a k_dcop section directly within MyClass:
class MyClass: public QObject, virtual public DCOPObject
{
Q_OBJECT
K_DCOP
public:
MyClass();
~MyClass();
k_dcop:
ASYNC myAsynchronousMethod(QString someParameter);
QRect mySynchronousMethod();
};
In addition to skeletons, dcopidl2cpp also generate stubs. Those make
it easy to call a DCOP interface without doing the marshalling
manually. To use a stub, add MyInterface.stub to the SOURCES list of
your Makefile.am. The stub class will then be called MyInterface_stub.
Conclusion:
-----------
Hopefully this document will get you well on your way into the world
of inter-process communication with KDE! Please direct all comments
and/or suggestions to Preston Brown and Matthias
Ettrich .
Inter-user communication
------------------------
Sometimes it might be interesting to use DCOP between processes
belonging to different users, e.g. a frontend process running
with the user's id, and a backend process running as root.
To do this, two steps have to be taken:
a) both processes need to talk to the same DCOP server
b) the authentication must be ensured
For the first step, you simply pass the server address (as
found in .DCOPserver) to the second process. For the authentication,
you can use the ICEAUTHORITY environment variable to tell the
second process where to find the authentication information.
(Note that this implies that the second process is able to
read the authentication file, so it will probably only work
if the second process runs as root. If it should run as another
user, a similar approach to what kdesu does with xauth must
be taken. In fact, it would be a very good idea to add DCOP
support to kdesu!)
For example
ICEAUTHORITY=~user/.ICEauthority kdesu root -c kcmroot -dcopserver `cat ~user/.DCOPserver`
will, after kdesu got the root password, execute kcmroot as root, talking
to the user's dcop server.
NOTE: DCOP communication is not encrypted, so please do not
pass important information around this way.
Performance Tests:
------------------
A few back-of-the-napkin tests folks:
Code:
#include
int main(int argc, char **argv)
{
KApplication *app;
app = new KApplication(argc, argv, "testit");
return app->exec();
}
Compiled with:
g++ -O2 -o testit testit.cpp -I$QTDIR/include -L$QTDIR/lib -lkdecore
on Linux yields the following memory use statistics:
VmSize: 8076 kB
VmLck: 0 kB
VmRSS: 4532 kB
VmData: 208 kB
VmStk: 20 kB
VmExe: 4 kB
VmLib: 6588 kB
If I create the KApplication's DCOPClient, and call attach() and
registerAs(), it changes to this:
VmSize: 8080 kB
VmLck: 0 kB
VmRSS: 4624 kB
VmData: 208 kB
VmStk: 20 kB
VmExe: 4 kB
VmLib: 6588 kB
Basically it appears that using DCOP causes 100k more memory to be
resident, but no more data or stack. So this will be shared between all
processes, right? 100k to enable DCOP in all apps doesn't seem bad at
all. :)
OK now for some timings. Just creating a KApplication and then exiting
(i.e. removing the call to KApplication::exec) takes this much time:
0.28user 0.02system 0:00.32elapsed 92%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1084major+62minor)pagefaults 0swaps
I.e. about 1/3 of a second on my PII-233. Now, if we create our DCOP
object and attach to the server, it takes this long:
0.27user 0.03system 0:00.34elapsed 87%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1107major+65minor)pagefaults 0swaps
I.e. about 1/3 of a second. Basically DCOPClient creation and attaching
gets lost in the statistical variation ("noise"). I was getting times
between .32 and .48 over several runs for both of the example programs, so
obviously system load is more relevant than the extra two calls to
DCOPClient::attach and DCOPClient::registerAs, as well as the actual
DCOPClient constructor time.
dbus-1.10.6/doc/dbus-api-design.duck 0000644 0001750 0001750 00000116303 12602773110 017131 0 ustar 00smcv smcv 0000000 0000000 = D-Bus API Design Guidelines
@link[guide >index]
@credit[type="author copyright"]
@name Philip Withnall
@email philip.withnall@collabora.co.uk
@years 2015
@desc Guidelines for writing high quality D-Bus APIs
@revision[date=2015-02-05 status=draft]
[synopsis]
[title]
Summary
The most common use for D-Bus is in implementing a service which will be
consumed by multiple client programs, and hence all interfaces exported on the
bus form a public API. Designing a D-Bus API is like designing any other API:
there is a lot of flexibility, but there are design patterns to follow and
anti-patterns to avoid.
This guide aims to explain the best practices for writing D-Bus APIs. These
have been refined over several years of use of D-Bus in many projects.
Pointers will be given for implementing APIs using common D-Bus
libraries like
$link[>>https://developer.gnome.org/gio/stable/gdbus-convenience.html](GDBus),
but detailed implementation instructions are left to the libraries’
documentation. Note that you should $em(not) use dbus-glib to implement D-Bus
services as it is deprecated and unmaintained. Most services should also avoid
libdbus (dbus-1), which is a low-level library and is awkward to use
correctly: it is designed to be used via a language binding such as
$link[>>http://qt-project.org/doc/qt-4.8/qtdbus.html](QtDBus).
For documentation on D-Bus itself, see the
$link[>>http://dbus.freedesktop.org/doc/dbus-specification.html](D-Bus
specification).
[links section]
== APIs
[id="apis"]
A D-Bus API is a specification of one or more interfaces, which will be
implemented by objects exposed by a service on the bus. Typically an API is
designed as a set of $link[>#interface-files](interface files), and the
implementation of the service follows those files. Some projects, however,
choose to define the API in the code for the service, and to export XML
interface files from the running service
$link[>>http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-introspectable](using
D-Bus introspection). Both are valid approaches.
For simplicity, this document uses the XML descriptions of D-Bus interfaces as
the canonical representation.
== Interface files
[id="interface-files"]
A D-Bus interface file is an XML file which describes one or more D-Bus
interfaces, and is the best way of describing a D-Bus API in a machine
readable way. The format is described in the
$link[>>http://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format](D-Bus
specification), and is supported by tools such as $cmd(gdbus-codegen).
Interface files for public API should be installed to
$code($var($$(datadir$))/dbus-1/interfaces) so that other services can load
them. Private APIs should not be installed. There should be one file installed
per D-Bus interface, named after the interface, containing a single top-level
$code() element with a single $code() beneath it. For example,
interface $code(com.example.MyService1.Manager) would be described by file
$file($var($$(datadir$))/dbus-1/interfaces/com.example.MyService1.Manager.xml):
[listing]
[title]
Example D-Bus Interface XML
[desc]
A brief example interface XML document.
[code mime="application/xml"]
Name of new contactE-mail address of new contactID of newly added contact
Adds a new contact to the address book with their name and
e-mail address.
If an interface defined by service A needs to be used by client B, client B
should declare a build time dependency on service A, and use the installed copy
of the interface file for any code generation it has to do. It should $em(not)
have a local copy of the interface, as that could then go out of sync with the
canonical copy in service A’s git repository.
== API versioning
[id="api-versioning"]
$link[>>http://ometer.com/parallel.html](Just like C APIs), D-Bus interfaces
should be designed to be usable in parallel with API-incompatible versions. This
is achieved by including a version number in each interface name, service name
and object path which is incremented on every backwards-incompatible change.
Version numbers should be included in all APIs from the first release, as that
means moving to a new version is as simple as incrementing the number, rather
than inserting a number everywhere, which takes more effort.
New API can be added to a D-Bus interface without incrementing the version
number, as such additions are still backwards-compatible. However, clients
should gracefully handle the $code(org.freedesktop.DBus.Error.UnknownMethod)
error reply from all D-Bus method calls if they want to run against older
versions of the service which don’t implement new methods. (This also prevents
use of generated bindings; any method which a client wants to gracefully fall
back from should be called using a generic D-Bus method invocation rather than
a specific generated binding.)
When API is broken, changed or removed, the service’s version number must be
bumped; for example, from $code(com.example.MyService1)
to $code(com.example.MyService2). If backwards compatibility is maintained in
the service by implementing both the old and new interfaces, the service can
own $em(both) well-known names and clients can use whichever they support.
As discussed in $link[>#annotations], new or deprecated APIs should be marked in
the interface XML using annotations.
Note, however, that supporting multiple interface versions simultaneously
requires that $em(object paths) are versioned as well, so objects $em(must not)
be put on the bus at the root path (‘/’). This is for technical reasons: signals
sent from a D-Bus service have the originating service name overwritten by its
unique name (e.g. $code(com.example.MyService2) is overwritten by $code(:1:15)).
If object paths are shared between objects implementing two versions of the
service’s interface, client programs cannot tell which object a signal has come
from. The solution is to include the version number in all object paths, for
example $code(/com/example/MyService1/Manager) instead of $code(/) or
$code(/com/example/MyService/Manager).
In summary, version numbers should be included in all service names, interface
names and object paths:
[list]
* $code(com.example.MyService1)
* $code(com.example.MyService1.InterestingInterface)
* $code(com.example.MyService1.OtherInterface)
* $code(/com/example/MyService1/Manager)
* $code(/com/example/MyService1/OtherObject)
== API design
[id="api-design"]
D-Bus API design is broadly the same as C API design, but there are a few
additional points to bear in mind which arise both from D-Bus’ features
(explicit errors, signals and properties), and from its implementation as an IPC
system.
D-Bus method calls are much more expensive than C function calls, typically
taking on the order of milliseconds to complete a round trip. Therefore, the
design should minimize the number of method calls needed to perform an
operation.
The type system is very expressive, especially compared to C’s, and APIs should
take full advantage of it.
Similarly, its support for signals and properties differentiates it from normal
C APIs, and well written D-Bus APIs make full use of these features where
appropriate. They can be coupled with standard interfaces defined in the D-Bus
specification to allow for consistent access to properties and objects in a
hierarchy.
=== Minimizing Round Trips
[id="round-trips"]
Each D-Bus method call is a round trip from a client program to a service and
back again, which is expensive — taking on the order of a millisecond. One of
the top priorities in D-Bus API design is to minimize the number of round trips
needed by clients. This can be achieved by a combination of providing specific
convenience APIs and designing APIs which operate on large data sets in a single
call, rather than requiring as many calls as elements in the data set.
Consider an address book API, $code(com.example.MyService1.AddressBook). It
might have an $code(AddContact(ss$) → (u$)) method to add a contact (taking name
and e-mail address parameters and returning a unique contact ID), and a
$code(RemoveContact(u$)) method to remove one by ID. In the normal case of
operating on single contacts in the address book, these calls are optimal.
However, if the user wants to import a list of contacts, or delete multiple
contacts simultaneously, one call has to be made per contact — this could take
a long time for large contact lists.
Instead of the $code(AddContact) and $code(RemoveContact) methods, the interface
could have an $code(UpdateContacts(a(ss$)au$) → (au$)) method, which takes an array
of structs containing the new contacts’ details, and an array of IDs of the
contacts to delete, and returns an array of IDs for the new contacts. This
reduces the number of round trips needed to one.
Adding convenience APIs to replace a series of common method calls with a single
method call specifically for that task is best done after the API has been
profiled and bottlenecks identified, otherwise it could lead to premature
optimization. One area where convenience methods can typically be added
is during initialization of a client, where multiple method calls are needed to
establish its state with the service.
=== Taking Advantage of the Type System
[id="type-system"]
D-Bus’ type system is similar to Python’s, but with a terser syntax which may be
unfamiliar to C developers. The key to using the type system effectively is
to expose as much structure in types as possible. In particular, sending
structured strings over D-Bus should be avoided, as they need to be built and
parsed; both are complex operations which are prone to bugs.
For APIs being used in constrained situations, enumerated values should be
transmitted as unsigned integers. For APIs which need to be extended by third
parties or which are used in more loosely coupled systems, enumerated values
should be strings in some defined format.
Transmitting values as integers means string parsing and matching can be
avoided, the messages are more compact, and typos can be more easily avoided by
developers (if, for example, C enums are used in the implementation).
Transmitting values as strings means additional values can be defined by third
parties without fear of conflicting over integer values; for instance by using
the same reverse-domain-name namespacing as D-Bus interfaces.
In both cases, the interface documentation should describe the meaning of each
value. It should state whether the type can be extended in future and, if so,
how the service and client should handle unrecognized values — typically by
considering them equal to an ‘unknown’ or ‘failure’ value. Conventionally, zero
is used as the ‘unknown’ value.
[example]
For example, instead of:
[code style="invalid" mime="application/xml"]
Use:
[code style="valid" mime="application/xml"]
Similarly, enumerated values should be used instead of booleans, as they allow
extra values to be added in future, and there is no ambiguity about the sense of
the boolean value.
[example]
For example, instead of:
[code style="invalid" mime="application/xml"]
Be more explicit than a boolean:
[code style="valid" mime="application/xml"]
Enumerated values should also be used instead of $em(human readable) strings,
which should not be sent over the bus if possible. The service and client could
be running in different locales, and hence interpret any human readable strings
differently, or present them to the user in the wrong language. Transmit an
enumerated value and convert it to a human readable string in the client.
In situations where a service has received a human readable string from
somewhere else, it should pass it on unmodified to the client, ideally with its
locale alongside. Passing human readable information to a client is better than
passing nothing.
[example]
For example, instead of:
[code style="invalid" mime="application/xml"]
The progress should be reported as an enumerated value:
[code style="valid" mime="application/xml"]
D-Bus has none of the problems of signed versus unsigned integers which C has
(specifically, it does not do implicit sign conversion), so integer types should
always be chosen to be an appropriate size and signedness for the data they
could possibly contain. Typically, unsigned values are more frequently needed
than signed values.
Structures can be used almost anywhere in a D-Bus type, and arrays of structures
are particularly useful. Structures should be used wherever data fields are
related. Note, however, that structures are not extensible in future, so always
consider $link[>#extensibility].
[example]
For example, instead of several identically-indexed arrays containing
different properties of the same set of items:
[code style="invalid" mime="application/xml"]
The arrays can be combined into a single array of structures:
[code style="invalid" mime="application/xml"]
Note that D-Bus arrays are automatically transmitted with their length, so there
is no need to null-terminate them or encode their length separately.
[comment]
FIXME: Mention maybe types and the extended kdbus/GVariant type system once
that’s stable and round-trip-ability is no longer a concern.
=== Extensibility
[id="extensibility"]
Some D-Bus APIs have very well-defined use cases, and will never need extension.
Others are used in more loosely coupled systems which may change over time, and
hence should be designed to be extensible from the beginning without the need
to break API in future. This is a trade off between having a more complex API,
and being able to easily extend it in future.
The key tool for extensibility in D-Bus is $code(a{sv}), the dictionary mapping
strings to variants. If well-defined namespaced strings are used as the
dictionary keys, arbitrary D-Bus peers can add whatever information they need
into the dictionary. Any other peer which understands it can query and retrieve
the information; other peers will ignore it.
The canonical example of an extensible API using $code(a{sv}) is
$link[>>http://telepathy.freedesktop.org/spec/](Telepathy). It uses $code(a{sv})
values as the final element in structures to allow them to be extended in
future.
A secondary tool is the use of flag fields in method calls. The set of accepted
flags is entirely under the control of the interface designer and, as with
enumerated types, can be extended in future without breaking API. Adding more
flags allows the functionality of the method call to be tweaked.
=== Using Signals, Properties and Errors
[id="using-the-features"]
D-Bus method calls are explicitly asynchronous due to the latency inherent in
IPC. This means that peers should not block on receiving a reply from a method
call; they should schedule other work (in a main loop) and handle the reply when
it is received. Even though method replies may take a while, the caller is
$em(guaranteed) to receive exactly one reply eventually. This reply could be the
return value from the method, an error from the method, or an error from the
D-Bus daemon indicating the service failed in some way (e.g. due to crashing).
Because of this, service implementations should be careful to always reply
exactly once to each method call. Replying at the end of a long-running
operation is correct — the client will patiently wait until the operation has
finished and the reply is received.
Note that D-Bus client bindings may implement synthetic timeouts of several
tens of seconds, unless explicitly disabled for a call. For very long-running
operations, you should disable the client bindings’ timeout and make it clear
in the client’s UI that the application has not frozen and is simply running a
long operation.
An anti-pattern to avoid in this situation is to start a long-running operation
when a method call is received, then to never reply to the method call and
instead notify the client of completion of the operation via a signal. This
approach is incorrect as signal emissions do not have a one-to-one relationship
with method calls — the signal could theoretically be emitted multiple times, or
never, which the client would not be able to handle.
Similarly, use a D-Bus error reply to signify failure of an operation triggered
by a method call, rather than using a custom error code in the method’s
reply. This means that a reply always indicates success, and an error always
indicates failure — rather than a reply indicating either depending on its
parameters, and having to return dummy values in the other parameters. Using
D-Bus error replies also means such failures can be highlighted in debugging
tools, simplifying debugging.
Clients should handle all possible standard and documented D-Bus errors for each
method call. IPC inherently has more potential failures than normal C function
calls, and clients should be prepared to handle all of them gracefully.
=== Using Standard Interfaces
[id="standard-interfaces"]
Use standard D-Bus interfaces where possible.
==== Properties
[id="interface-properties"]
The D-Bus specification defines the
$link[>>http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties]($code(org.freedesktop.DBus.Properties))
interface, which should be used by all objects to notify clients of changes
to their property values, with the $code(PropertiesChanged) signal. This signal
eliminates the need for individual $code($var(PropertyName)Changed) signals, and
allows multiple properties to be notified in a single signal emission, reducing
IPC round trips. Similarly, the $code(Get) and $code(Set) methods can be used to
manipulate properties on an object, eliminating redundant
$code(Get$var(PropertyName)) and $code(Set$var(PropertyName)) methods.
[example]
For example, consider an object implementing an interface
$code(com.example.MyService1.SomeInterface) with methods:
[list]
* $code(GetName($) → (s$))
* $code(SetName(s$) → ($))
* $code(GetStatus($) → (u$))
* $code(RunOperation(ss$) → (u$))
and signals:
[list]
* $code(NameChanged(u$))
* $code(StatusChanged(u$))
The interface could be cut down to a single method:
[list]
* $code(RunOperation(ss$) → (u$))
The object could then implement the $code(org.freedesktop.DBus.Properties)
interface and define properties:
[list]
* $code(Name) of type $code(s), read–write
* $code(Status) of type $code(u), read-only
The $code(NameChanged) and $code(StatusChanged) signals would be replaced by
$code(org.freedesktop.DBus.Properties.PropertiesChanged).
==== Object Manager
[id="interface-object-manager"]
The specification also defines the
$link[>>http://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-objectmanager]($code(org.freedesktop.DBus.ObjectManager))
interface, which should be used whenever a service needs to expose a variable
number of objects of the same class in a flat or tree-like structure, and
clients are expected to be interested in most or all of the objects. For
example, this could be used by an address book service which exposes multiple
address books, each as a separate object. The $code(GetManagedObjects) method
allows the full object tree to be queried, returning all the objects’ properties
too, eliminating the need for further IPC round trips to query the properties.
If clients are not expected to be interested in most of the exposed objects,
$code(ObjectManager) should $em(not) be used, as it will send all of the objects
to each client anyway, wasting bus bandwidth. A file manager, therefore, should
not expose the entire file system hierarchy using $code(ObjectManager).
[example]
For example, consider an object implementing an interface
$code(com.example.MyService1.AddressBookManager) with methods:
[list]
* $code(GetAddressBooks($) → (ao$))
and signals:
[list]
* $code(AddressBookAdded(o$))
* $code(AddressBookRemoved(o$))
If the manager object is at path
$code(/com/example/MyService1/AddressBookManager), each address book is a
child object, e.g.
$code(/com/example/MyService1/AddressBookManager/SomeAddressBook).
The interface could be eliminated, and the
$code(org.freedesktop.DBus.ObjectManager) interface implemented on the manager
object instead.
Calls to $code(GetAddressBooks) would become calls to $code(GetManagedObjects)
and emissions of the $code(AddressBookAdded) and $code(AddressBookRemoved)
signals would become emissions of $code(InterfacesAdded) and
$code(InterfacesRemoved).
=== Naming Conventions
[id="naming-conventions"]
All D-Bus names, from service names through to method parameters, follow a set
of conventions. Following these conventions makes APIs more natural to use and
consistent with all other services on the system.
Services use reverse-domain-name notation, based on the domain name of the
project providing the service (all in lower case), plus a unique name for the
service (in camel case).
[example]
For example, version 2 of an address book application called $code(ContactDex)
provided by a software vendor whose website is $code(chocolateteapot.com)
would use service name $code(com.chocolateteapot.ContactDex2).
Almost all names use camel case with no underscores, as in the examples below.
Method and signal parameters are an exception, using
$code(lowercase_with_underscores). Type information is never encoded in the
parameter name (i.e. $em(not)
$link[>>http://en.wikipedia.org/wiki/Hungarian_notation](Hungarian notation)).
[example]
[terms]
- Service Name
* $code(com.example.MyService1)
- Interface Name
* $code(com.example.MyService1.SomeInterface)
- Object Path (Root Object)
* $code(/com/example/MyService1)
- Object Path (Child Object)
* $code(/com/example/MyService1/SomeChild)
- Object Path (Grandchild Object)
* $code(/com/example/MyService1/AnotherChild/Grandchild1)
- Method Name
* $code(com.example.MyService1.SomeInterface.MethodName)
- Signal Name
* $code(com.example.MyService1.SomeInterface.SignalName)
- Property Name
* $code(com.example.MyService1.SomeInterface.PropertyName)
See also: $link[>#api-versioning].
== Code generation
[id="code-generation"]
Rather than manually implementing both the server and client sides of a D-Bus
interface, it is often easier to write the interface XML description and use a
tool such as
$link[>>https://developer.gnome.org/gio/stable/gdbus-codegen.html]($cmd(gdbus-codegen))
to generate type-safe C APIs, then build the implementation using those. This
avoids the tedious and error-prone process of writing code to build and read
D-Bus parameter variants for each method call.
Use of code generators is beyond the scope of this guide; for more information,
see the
$link[>>https://developer.gnome.org/gio/stable/gdbus-codegen.html]($cmd(gdbus-codegen)
manual).
== Annotations
[id="annotations"]
Annotations may be added to the interface XML to expose metadata on the API
which can be used by documentation or code generation tools to modify their
output. Some standard annotations are given in the
$link[>>http://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format](D-Bus
specification), but further annotations may be defined by specific tools.
For example, $cmd(gdbus-codegen) defines several useful annotations, listed on
its man page.
The following annotations are the most useful:
[terms]
- $code(org.freedesktop.DBus.Deprecated)
* Mark a symbol as deprecated. This should be used whenever the API is changed,
specifying the version introducing the deprecation, the reason for
deprecation, and a replacement symbol to use.
- $code(org.gtk.GDBus.Since)
* Mark a symbol as having been added to the API after the initial release. This
should include the version the symbol was first added in.
- $code(org.gtk.GDBus.C.Name) and $code(org.freedesktop.DBus.GLib.CSymbol)
* Both used interchangeably to hint at a C function name to use when generating
code for a symbol. Use of this annotation can make generated bindings a lot
more pleasant to use.
- $code(org.freedesktop.DBus.Property.EmitsChangedSignal)
* Indicate whether a property is expected to emit change signals. This can
affect code generation, but is also useful documentation, as client programs
then know when to expect property change notifications and when they have to
requery.
== Documentation
[id="documentation"]
Also just like C APIs, D-Bus APIs must be documented. There are several methods
for documenting the interfaces, methods, properties and signals in a D-Bus
interface XML file, each unfortunately with their own downsides. You should
choose the method which best matches the tooling and workflow you are using.
=== XML Comments
XML comments containing documentation in the
$link[>>https://developer.gnome.org/gtk-doc-manual/stable/documenting_syntax.html.en](gtk-doc
format) is the recommended format for use with
$link[>>https://developer.gnome.org/gio/stable/gdbus-codegen.html]($cmd(gdbus-codegen)).
Using $cmd(gdbus-codegen), these comments can be extracted, converted to DocBook
format and included in the project’s API manual. For example:
[listing]
[title]
Documentation Comments in D-Bus Interface XML
[desc]
Example gtk-doc–style documentation comments in the introspection XML for
the $code(org.freedesktop.DBus.Properties) interface.
[code mime="application/xml"]
[comment]
FIXME: This is only present to fix
$link[>>https://github.com/projectmallard/mallard-ducktype/issues/2].
=== XML Annotations
Documentation can also be added as annotation elements in the XML. This format
is also supported by $cmd(gdbus-codegen), but gtk-doc comments are preferred.
For example:
[listing]
[title]
Documentation Annotations in D-Bus Interface XML
[desc]
Example GDBus documentation annotations in the introspection XML for
the $code(org.freedesktop.DBus.Properties) interface.
[code mime="application/xml"]
[comment]
FIXME: This is only present to fix
$link[>>https://github.com/projectmallard/mallard-ducktype/issues/2].
== Service files
[id="service-files"]
Each D-Bus service must install a $file(.service) file describing its service
name and the command to run to start the service. This allows for service
activation (see the
$link[>>http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services](D-Bus
specification)).
Service files must be named after the service’s well-known name, for example
file $file(com.example.MyService1.service) for well-known name
$code(com.example.MyService1). Files must be installed in
$file($var($$(datadir$))/dbus-1/services) for the session bus and
$file($var($$(datadir$))/dbus-1/system-services) for the system bus. Note, however,
that services on the system bus almost always need a
$link[>#security-policies](security policy) as well.
== Security Policies
[id="security-policies"]
At a high level, the D-Bus security model is:
[list]
* There is a system bus, and zero or more session buses.
* Any process may connect to the system bus. The system bus limits which can own
names or send method calls, and only processes running as privileged users can
receive unicast messages not addressed to them. Every process may receive
broadcasts.
* Each session bus has an owner (a user). Only its owner may connect; on
general-purpose Linux, a session bus is not treated as a privilege boundary,
so there is no further privilege separation between processes on it.
Full coverage of securing D-Bus services is beyond the scope of this guide,
however there are some steps which you can take when designing an API to ease
security policy implementation.
D-Bus security policies are written as XML files in
$file($var($$(sysconfdir$)/dbus-1/system.d)) and
$file($var($$(sysconfdir$)/dbus-1/session.d)) and use an allow/deny model, where
each message (method call, signal emission, etc.) can be allowed or denied
according to the sum of all policy rules which match it. Each $code() or
$code() rule in the policy should have the $code(own),
$code(send_destination) or $code(receive_sender) attribute set.
When designing an API, bear in mind the need to write and install such a
security policy, and consider splitting up methods or providing more restricted
versions which accept constrained parameters, so that they can be exposed with
less restrictive security policies if needed by less trusted clients.
Secondly, the default D-Bus security policy for the system bus is restrictive
enough to allow sensitive data, such as passwords, to be safely sent over the
bus in unicast messages (including unicast signals); so there is no need to
complicate APIs by implementing extra security. Note, however, that sensitive
data must $em(not) be sent in broadcast signals, as they can be seen by all
peers on the bus. The default policy for the session bus is not restrictive, but
it is typically not a security boundary.
== Debugging
[id="debugging"]
Debugging services running on D-Bus can be tricky, especially if they are
launched via service activation and hence in an environment out of your control.
Three main tools are available: D-Bus Monitor, Bustle and D-Feet.
=== D-Bus Monitor
[id="dbus-monitor"]
$link[>>http://dbus.freedesktop.org/doc/dbus-monitor.1.html]($cmd(dbus-monitor))
is a core D-Bus tool, and allows eavesdropping on the session or system bus,
printing all messages it sees. The messages may be filtered using a standard
$link[>>http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-routing-match-rules](D-Bus
match rule) to make the stream more manageable.
Previous versions of D-Bus have required the security policy for the system bus
to be manually relaxed to allow eavesdropping on all messages. This meant that
debugging it was difficult and insecure. The latest versions of D-Bus add
support for monitor-only connections for the root user, which means that
$cmd(dbus-monitor) can be run as root to painlessly monitor all messages on the
system bus without modifying its security policy.
=== Bustle
[id="bustle"]
$link[>>http://willthompson.co.uk/bustle/](Bustle) is a graphical version of
$cmd(dbus-monitor), with a UI focused on profiling D-Bus performance by plotting
messages on a timeline. It is ideal for finding bottlenecks in IPC performance
between a service and client.
=== D-Feet
[id="d-feet"]
$link[>>https://wiki.gnome.org/Apps/DFeet](D-Feet) is an introspection tool for
D-Bus, which displays all peers on the bus graphically, with their objects,
interfaces, methods, signals and properties listed for examination. It is useful
for debugging all kinds of issues related to presence of services on the bus
and the objects they expose.
dbus-1.10.6/doc/dbus-tutorial.xml 0000644 0001750 0001750 00000075314 12602773110 016634 0 ustar 00smcv smcv 0000000 0000000
D-Bus TutorialVersion 0.5.020 August 2006HavocPenningtonRed Hat, Inc.hp@pobox.comDavidWheelerJohnPalmieriRed Hat, Inc.johnp@redhat.comColinWaltersRed Hat, Inc.walters@redhat.comTutorial Work In Progress
This tutorial is not complete; it probably contains some useful information, but
also has plenty of gaps. Right now, you'll also need to refer to the D-Bus specification,
Doxygen reference documentation, and look at some examples of how other apps use D-Bus.
Enhancing the tutorial is definitely encouraged - send your patches or suggestions to the
mailing list. If you create a D-Bus binding, please add a section to the tutorial for your
binding, if only a short section with a couple of examples.
What is D-Bus?
D-Bus is a system for interprocess communication
(IPC). Architecturally, it has several layers:
A library, libdbus, that allows two
applications to connect to each other and exchange messages.
A message bus daemon executable, built on
libdbus, that multiple applications can connect to. The daemon can
route messages from one application to zero or more other
applications.
Wrapper libraries or bindings
based on particular application frameworks. For example, libdbus-glib and
libdbus-qt. There are also bindings to languages such as
Python. These wrapper libraries are the API most people should use,
as they simplify the details of D-Bus programming. libdbus is
intended to be a low-level backend for the higher level bindings.
Much of the libdbus API is only useful for binding implementation.
libdbus only supports one-to-one connections, just like a raw network
socket. However, rather than sending byte streams over the connection, you
send messages. Messages have a header identifying
the kind of message, and a body containing a data payload. libdbus also
abstracts the exact transport used (sockets vs. whatever else), and
handles details such as authentication.
The message bus daemon forms the hub of a wheel. Each spoke of the wheel
is a one-to-one connection to an application using libdbus. An
application sends a message to the bus daemon over its spoke, and the bus
daemon forwards the message to other connected applications as
appropriate. Think of the daemon as a router.
The bus daemon has multiple instances on a typical computer. The
first instance is a machine-global singleton, that is, a system daemon
similar to sendmail or Apache. This instance has heavy security
restrictions on what messages it will accept, and is used for systemwide
communication. The other instances are created one per user login session.
These instances allow applications in the user's session to communicate
with one another.
The systemwide and per-user daemons are separate. Normal within-session
IPC does not involve the systemwide message bus process and vice versa.
D-Bus applications
There are many, many technologies in the world that have "Inter-process
communication" or "networking" in their stated purpose: CORBA, DCE, DCOM, DCOP, XML-RPC, SOAP, MBUS, Internet Communications Engine (ICE),
and probably hundreds more.
Each of these is tailored for particular kinds of application.
D-Bus is designed for two specific cases:
Communication between desktop applications in the same desktop
session; to allow integration of the desktop session as a whole,
and address issues of process lifecycle (when do desktop components
start and stop running).
Communication between the desktop session and the operating system,
where the operating system would typically include the kernel
and any system daemons or processes.
For the within-desktop-session use case, the GNOME and KDE desktops
have significant previous experience with different IPC solutions
such as CORBA and DCOP. D-Bus is built on that experience and
carefully tailored to meet the needs of these desktop projects
in particular. D-Bus may or may not be appropriate for other
applications; the FAQ has some comparisons to other IPC systems.
The problem solved by the systemwide or communication-with-the-OS case
is explained well by the following text from the Linux Hotplug project:
A gap in current Linux support is that policies with any sort of
dynamic "interact with user" component aren't currently
supported. For example, that's often needed the first time a network
adapter or printer is connected, and to determine appropriate places
to mount disk drives. It would seem that such actions could be
supported for any case where a responsible human can be identified:
single user workstations, or any system which is remotely
administered.
This is a classic "remote sysadmin" problem, where in this case
hotplugging needs to deliver an event from one security domain
(operating system kernel, in this case) to another (desktop for
logged-in user, or remote sysadmin). Any effective response must go
the other way: the remote domain taking some action that lets the
kernel expose the desired device capabilities. (The action can often
be taken asynchronously, for example letting new hardware be idle
until a meeting finishes.) At this writing, Linux doesn't have
widely adopted solutions to such problems. However, the new D-Bus
work may begin to solve that problem.
D-Bus may happen to be useful for purposes other than the one it was
designed for. Its general properties that distinguish it from
other forms of IPC are:
Binary protocol designed to be used asynchronously
(similar in spirit to the X Window System protocol).
Stateful, reliable connections held open over time.
The message bus is a daemon, not a "swarm" or
distributed architecture.
Many implementation and deployment issues are specified rather
than left ambiguous/configurable/pluggable.
Semantics are similar to the existing DCOP system, allowing
KDE to adopt it more easily.
Security features to support the systemwide mode of the
message bus.
Concepts
Some basic concepts apply no matter what application framework you're
using to write a D-Bus application. The exact code you write will be
different for GLib vs. Qt vs. Python applications, however.
Here is a diagram (pngsvg) that may help you visualize the concepts
that follow.
Native Objects and Object Paths
Your programming framework probably defines what an "object" is like;
usually with a base class. For example: java.lang.Object, GObject, QObject,
python's base Object, or whatever. Let's call this a native object.
The low-level D-Bus protocol, and corresponding libdbus API, does not care about native objects.
However, it provides a concept called an
object path. The idea of an object path is that
higher-level bindings can name native object instances, and allow remote applications
to refer to them.
The object path
looks like a filesystem path, for example an object could be
named /org/kde/kspread/sheets/3/cells/4/5.
Human-readable paths are nice, but you are free to create an
object named /com/mycompany/c5yo817y0c1y1c5b
if it makes sense for your application.
Namespacing object paths is smart, by starting them with the components
of a domain name you own (e.g. /org/kde). This
keeps different code modules in the same process from stepping
on one another's toes.
Methods and Signals
Each object has members; the two kinds of member
are methods and
signals. Methods are operations that can be
invoked on an object, with optional input (aka arguments or "in
parameters") and output (aka return values or "out parameters").
Signals are broadcasts from the object to any interested observers
of the object; signals may contain a data payload.
Both methods and signals are referred to by name, such as
"Frobate" or "OnClicked".
Interfaces
Each object supports one or more interfaces.
Think of an interface as a named group of methods and signals,
just as it is in GLib or Qt or Java. Interfaces define the
type of an object instance.
DBus identifies interfaces with a simple namespaced string,
something like org.freedesktop.Introspectable.
Most bindings will map these interface names directly to
the appropriate programming language construct, for example
to Java interfaces or C++ pure virtual classes.
Proxies
A proxy object is a convenient native object created to
represent a remote object in another process. The low-level DBus API involves manually creating
a method call message, sending it, then manually receiving and processing
the method reply message. Higher-level bindings provide proxies as an alternative.
Proxies look like a normal native object; but when you invoke a method on the proxy
object, the binding converts it into a DBus method call message, waits for the reply
message, unpacks the return value, and returns it from the native method..
In pseudocode, programming without proxies might look like this:
Message message = new Message("/remote/object/path", "MethodName", arg1, arg2);
Connection connection = getBusConnection();
connection.send(message);
Message reply = connection.waitForReply(message);
if (reply.isError()) {
} else {
Object returnValue = reply.getReturnValue();
}
Programming with proxies might look like this:
Proxy proxy = new Proxy(getBusConnection(), "/remote/object/path");
Object returnValue = proxy.MethodName(arg1, arg2);
Bus Names
When each application connects to the bus daemon, the daemon immediately
assigns it a name, called the unique connection name.
A unique name begins with a ':' (colon) character. These names are never
reused during the lifetime of the bus daemon - that is, you know
a given name will always refer to the same application.
An example of a unique name might be
:34-907. The numbers after the colon have
no meaning other than their uniqueness.
When a name is mapped
to a particular application's connection, that application is said to
own that name.
Applications may ask to own additional well-known
names. For example, you could write a specification to
define a name called com.mycompany.TextEditor.
Your definition could specify that to own this name, an application
should have an object at the path
/com/mycompany/TextFileManager supporting the
interface org.freedesktop.FileHandler.
Applications could then send messages to this bus name,
object, and interface to execute method calls.
You could think of the unique names as IP addresses, and the
well-known names as domain names. So
com.mycompany.TextEditor might map to something like
:34-907 just as mycompany.com maps
to something like 192.168.0.5.
Names have a second important use, other than routing messages. They
are used to track lifecycle. When an application exits (or crashes), its
connection to the message bus will be closed by the operating system
kernel. The message bus then sends out notification messages telling
remaining applications that the application's names have lost their
owner. By tracking these notifications, your application can reliably
monitor the lifetime of other applications.
Bus names can also be used to coordinate single-instance applications.
If you want to be sure only one
com.mycompany.TextEditor application is running for
example, have the text editor application exit if the bus name already
has an owner.
Addresses
Applications using D-Bus are either servers or clients. A server
listens for incoming connections; a client connects to a server. Once
the connection is established, it is a symmetric flow of messages; the
client-server distinction only matters when setting up the
connection.
If you're using the bus daemon, as you probably are, your application
will be a client of the bus daemon. That is, the bus daemon listens
for connections and your application initiates a connection to the bus
daemon.
A D-Bus address specifies where a server will
listen, and where a client will connect. For example, the address
unix:path=/tmp/abcdef specifies that the server will
listen on a UNIX domain socket at the path
/tmp/abcdef and the client will connect to that
socket. An address can also specify TCP/IP sockets, or any other
transport defined in future iterations of the D-Bus specification.
When using D-Bus with a message bus daemon,
libdbus automatically discovers the address of the per-session bus
daemon by reading an environment variable. It discovers the
systemwide bus daemon by checking a well-known UNIX domain socket path
(though you can override this address with an environment variable).
If you're using D-Bus without a bus daemon, it's up to you to
define which application will be the server and which will be
the client, and specify a mechanism for them to agree on
the server's address. This is an unusual case.
Big Conceptual Picture
Pulling all these concepts together, to specify a particular
method call on a particular object instance, a number of
nested components have to be named:
Address -> [Bus Name] -> Path -> Interface -> Method
The bus name is in brackets to indicate that it's optional -- you only
provide a name to route the method call to the right application
when using the bus daemon. If you have a direct connection to another
application, bus names aren't used; there's no bus daemon.
The interface is also optional, primarily for historical
reasons; DCOP does not require specifying the interface,
instead simply forbidding duplicate method names
on the same object instance. D-Bus will thus let you
omit the interface, but if your method name is ambiguous
it is undefined which method will be invoked.
Messages - Behind the Scenes
D-Bus works by sending messages between processes. If you're using
a sufficiently high-level binding, you may never work with messages directly.
There are 4 message types:
Method call messages ask to invoke a method
on an object.
Method return messages return the results
of invoking a method.
Error messages return an exception caused by
invoking a method.
Signal messages are notifications that a given signal
has been emitted (that an event has occurred).
You could also think of these as "event" messages.
A method call maps very simply to messages: you send a method call
message, and receive either a method return message or an error message
in reply.
Each message has a header, including fields,
and a body, including arguments. You can think
of the header as the routing information for the message, and the body as the payload.
Header fields might include the sender bus name, destination bus name, method or signal name,
and so forth. One of the header fields is a type signature describing the
values found in the body. For example, the letter "i" means "32-bit integer" so the signature
"ii" means the payload has two 32-bit integers.
Calling a Method - Behind the Scenes
A method call in DBus consists of two messages; a method call message sent from process A to process B,
and a matching method reply message sent from process B to process A. Both the call and the reply messages
are routed through the bus daemon. The caller includes a different serial number in each call message, and the
reply message includes this number to allow the caller to match replies to calls.
The call message will contain any arguments to the method.
The reply message may indicate an error, or may contain data returned by the method.
A method invocation in DBus happens as follows:
The language binding may provide a proxy, such that invoking a method on
an in-process object invokes a method on a remote object in another process. If so, the
application calls a method on the proxy, and the proxy
constructs a method call message to send to the remote process.
For more low-level APIs, the application may construct a method call message itself, without
using a proxy.
In either case, the method call message contains: a bus name belonging to the remote process; the name of the method;
the arguments to the method; an object path inside the remote process; and optionally the name of the
interface that specifies the method.
The method call message is sent to the bus daemon.
The bus daemon looks at the destination bus name. If a process owns that name,
the bus daemon forwards the method call to that process. Otherwise, the bus daemon
creates an error message and sends it back as the reply to the method call message.
The receiving process unpacks the method call message. In a simple low-level API situation, it
may immediately run the method and send a method reply message to the bus daemon.
When using a high-level binding API, the binding might examine the object path, interface,
and method name, and convert the method call message into an invocation of a method on
a native object (GObject, java.lang.Object, QObject, etc.), then convert the return
value from the native method into a method reply message.
The bus daemon receives the method reply message and sends it to the process that
made the method call.
The process that made the method call looks at the method reply and makes use of any
return values included in the reply. The reply may also indicate that an error occurred.
When using a binding, the method reply message may be converted into the return value of
of a proxy method, or into an exception.
The bus daemon never reorders messages. That is, if you send two method call messages to the same recipient,
they will be received in the order they were sent. The recipient is not required to reply to the calls
in order, however; for example, it may process each method call in a separate thread, and return reply messages
in an undefined order depending on when the threads complete. Method calls have a unique serial
number used by the method caller to match reply messages to call messages.
Emitting a Signal - Behind the Scenes
A signal in DBus consists of a single message, sent by one process to any number of other processes.
That is, a signal is a unidirectional broadcast. The signal may contain arguments (a data payload), but
because it is a broadcast, it never has a "return value." Contrast this with a method call
(see ) where the method call message has a matching method reply message.
The emitter (aka sender) of a signal has no knowledge of the signal recipients. Recipients register
with the bus daemon to receive signals based on "match rules" - these rules would typically include the sender and
the signal name. The bus daemon sends each signal only to recipients who have expressed interest in that
signal.
A signal in DBus happens as follows:
A signal message is created and sent to the bus daemon. When using the low-level API this may be
done manually, with certain bindings it may be done for you by the binding when a native object
emits a native signal or event.
The signal message contains the name of the interface that specifies the signal;
the name of the signal; the bus name of the process sending the signal; and
any arguments
Any process on the message bus can register "match rules" indicating which signals it
is interested in. The bus has a list of registered match rules.
The bus daemon examines the signal and determines which processes are interested in it.
It sends the signal message to these processes.
Each process receiving the signal decides what to do with it; if using a binding,
the binding may choose to emit a native signal on a proxy object. If using the
low-level API, the process may just look at the signal sender and name and decide
what to do based on that.
Introspection
D-Bus objects may support the interface org.freedesktop.DBus.Introspectable.
This interface has one method Introspect which takes no arguments and returns
an XML string. The XML string describes the interfaces, methods, and signals of the object.
See the D-Bus specification for more details on this introspection format.
GLib APIs
The recommended GLib API for D-Bus is GDBus, which has been
distributed with GLib since version 2.26. It is not documented here.
See the
GLib documentation for details of how to use GDBus.
An older API, dbus-glib, also exists. It is deprecated and should
not be used in new code. Whenever possible, porting existing code
from dbus-glib to GDBus is also recommended.
Python API
The Python API, dbus-python, is now documented separately in
the dbus-python tutorial (also available in doc/tutorial.txt,
and doc/tutorial.html if built with python-docutils, in the dbus-python
source distribution).
Qt API
The Qt binding for libdbus, QtDBus, has been distributed with Qt
since version 4.2. It is not documented here. See
the Qt
documentation for details of how to use QtDBus.
dbus-1.10.6/doc/dbus-test-plan.xml 0000644 0001750 0001750 00000021276 12602773110 016676 0 ustar 00smcv smcv 0000000 0000000
D-Bus Test Plan14 February 2003AndersCarlssonCodeFactory ABandersca@codefactory.seIntroduction
This document tries to explain the details of the test plan for D-Bus
The importance of testing
As with any big library or program, testing is important. It
can help find bugs and regressions and make the code better
overall.
D-Bus is a large and complex piece of software (about 25,000
lines of code for the client library, and 2,500 lines of code
for the bus daemon) and it's therefore important to try to make sure
that all parts of the software is functioning correctly.
D-Bus can be built with support for testing by passing
--enable-tests. to the configure script. It
is recommended that production systems build without testing
since that reduces the D-Bus client library size.
Testing the D-Bus client library
The tests for the client library consist of the test-dbus
program which is a unit test for all aspects of the client
library. Whenever a bug in the client library is found and
fixed, a test is added to make sure that the bug won't occur again.
Data Structures
The D-Bus client library consists of some data structures that
are used internally; a linked list class, a hashtable class and
a string class. All aspects of those are tested by test-dbus.
Message loader
The message loader is the part of D-Bus that takes messages in
raw character form and parses them, turning them into DBusMessages.
This is one of the parts of D-Bus that
must be absolutely bug-free and
robust. The message loader should be able to handle invalid
and incomplete messages without crashing. Not doing so is a
serious issue and can easily result in D-Bus being exploitable
to DoS attacks.
To solve these problems, there is a testing feature called the
Message Builder. The message builder can take a serialized
message in string-form and convert it into a raw character
string which can then be loaded by the message loader.
Example of a message in string form
# Standard org.freedesktop.DBus.Hello message
VALID_HEADER
FIELD_NAME name
TYPE STRING
STRING 'org.freedesktop.DBus.Hello'
FIELD_NAME srvc
TYPE STRING
STRING 'org.freedesktop.DBus'
ALIGN 8
END_LENGTH Header
START_LENGTH Body
END_LENGTH Body
The file format of messages in string form is documented in
the D-Bus Reference Manual.
The message test part of test-dbus is using the message
builder to build different kinds of messages, both valid,
invalid, and invalid ones, to make sure that the loader won't
crash or leak memory of any of those, and that the loader
knows if a message is valid or not.
There is also a test program called
break-loader that loads a message in
string-form into raw character form using the message
builder. It then randomly changes the message, it can for
example replace single bytes of data or modify the length of
the message. This is to simulate network errors. The
break-loader program saves all the messages leading to errors
so it can easily be run for a long period of time.
Authentication
For testing authentication, there is a testing feature that
can read authentication sequences from a file and play them
back to a dummy server and client to make sure that
authentication is working according to the specification.
Example of an authentication script
## this tests a successful auth of type EXTERNAL
SERVER
SEND 'AUTH EXTERNAL USERNAME_HEX'
EXPECT_COMMAND OK
EXPECT_STATE WAITING_FOR_INPUT
SEND 'BEGIN'
EXPECT_STATE AUTHENTICATED
Testing the D-Bus bus daemon
Since the D-Bus bus daemon is using the D-Bus client library it
will benefit from all tests done on the client library, but
there is still the issue of testing client-server communication.
This is more complicated since it it may require another process
running.
The debug transport
In D-Bus, a transport is a class that
handles sending and receiving raw data over a certain
medium. The transport that is used most in D-Bus is the UNIX
transport with sends and recevies data over a UNIX socket. A
transport that tunnels data through X11 client messages is
also under development.
The D-Bus debug transport is a specialized transport that
works in-process. This means that a client and server that
exists in the same process can talk to eachother without using
a socket.
The test-bus program
The test-bus program is a program that is used to test various
parts of the D-Bus bus daemon; robustness and that it conforms
to the specifications.
The test program has the necessary code from the bus daemon
linked in, and it uses the debug transport for
communication. This means that the bus daemon code can be
tested without the real bus actually running, which makes
testing easier.
The test-bus program should test all major features of the
bus, such as service registration, notification when things
occurs and message matching.
Other testsOut-Of-Memory robustness
Since D-Bus should be able to be used in embedded devices, and
also as a system service, it should be able to cope with
low-memory situations without exiting or crashing.
In practice, this means that both the client and server code
must be able to handle dbus_malloc returning NULL.
To test this, two environment variables
exist. DBUS_MALLOC_FAIL_NTH will make every
nth call to dbus_malloc return NULL, and
DBUS_MALLOC_FAIL_GREATER_THAN will make any
dbus_malloc call with a request for more than the specified
number of bytes fail.
Memory leaks and code robustness
Naturally there are some things that tests can't be written
for, for example things like memory leaks and out-of-bounds
memory reading or writing.
Luckily there exists good tools for catching such errors. One
free good tool is Valgrind, which runs the program in a
virtual CPU which makes catching errors easy. All test programs can be run under Valgrind,
dbus-1.10.6/doc/dbus-specification.xml 0000644 0001750 0001750 00001031767 12624705346 017630 0 ustar 00smcv smcv 0000000 0000000
D-Bus SpecificationVersion 0.262015-02-19HavocPenningtonRed Hat, Inc.hp@pobox.comAndersCarlssonCodeFactory ABandersca@codefactory.seAlexanderLarssonRed Hat, Inc.alexl@redhat.comSvenHerzbergImendio ABsven@imendio.comSimonMcVittieCollabora Ltd.simon.mcvittie@collabora.co.ukDavidZeuthenzeuthen@gmail.com0.262015-02-19smcv, rh
GetConnectionCredentials can return LinuxSecurityLabel or
WindowsSID; add privileged BecomeMonitor method
0.252014-11-10smcv, lennart
ALLOW_INTERACTIVE_AUTHORIZATION flag, EmitsChangedSignal=const
0.242014-10-01SMcV
non-method-calls never expect a reply even without NO_REPLY_EXPECTED;
document how to quote match rules
0.232014-01-06SMcV, CY
method call messages with no INTERFACE may be considered an error;
document tcp:bind=... and nonce-tcp:bind=...; define listenable
and connectable addresses
0.222013-10-09add GetConnectionCredentials, document
GetAtdAuditSessionData, document GetConnectionSELinuxSecurityContext,
document and correct .service file syntax and naming
0.212013-04-25smcvallow Unicode noncharacters in UTF-8 (Unicode
Corrigendum #9)0.2022 February 2013smcv, waltersreorganise for clarity, remove false claims about
basic types, mention /o/fd/DBus0.1920 February 2012smcv/lpformally define unique connection names and well-known
bus names; document best practices for interface, bus, member and
error names, and object paths; document the search path for session
and system services on Unix; document the systemd transport0.1829 July 2011smcvdefine eavesdropping, unicast, broadcast; add eavesdrop
match keyword; promote type system to a top-level section0.171 June 2011smcv/davidzdefine ObjectManager; reserve extra pseudo-type-codes used
by GVariant0.1611 April 2011add path_namespace, arg0namespace; argNpath matches object
paths0.153 November 20100.1412 May 20100.1323 Dezember 20090.127 November, 20060.116 February 20050.1028 January 20050.97 Januar 20050.806 September 2003First released document.Introduction
D-Bus is a system for low-overhead, easy to use
interprocess communication (IPC). In more detail:
D-Bus is low-overhead because it uses a
binary protocol, and does not have to convert to and from a text
format such as XML. Because D-Bus is intended for potentially
high-resolution same-machine IPC, not primarily for Internet IPC,
this is an interesting optimization. D-Bus is also designed to
avoid round trips and allow asynchronous operation, much like
the X protocol.
D-Bus is easy to use because it works in terms
of messages rather than byte streams, and
automatically handles a lot of the hard IPC issues. Also, the D-Bus
library is designed to be wrapped in a way that lets developers use
their framework's existing object/type system, rather than learning
a new one specifically for IPC.
The base D-Bus protocol is a one-to-one (peer-to-peer or client-server)
protocol, specified in . That is, it is
a system for one application to talk to a single other
application. However, the primary intended application of the protocol is the
D-Bus message bus, specified in . The message bus is a special application that
accepts connections from multiple other applications, and forwards
messages among them.
Uses of D-Bus include notification of system changes (notification of when
a camera is plugged in to a computer, or a new version of some software
has been installed), or desktop interoperability, for example a file
monitoring service or a configuration service.
D-Bus is designed for two specific use cases:
A "system bus" for notifications from the system to user sessions,
and to allow the system to request input from user sessions.
A "session bus" used to implement desktop environments such as
GNOME and KDE.
D-Bus is not intended to be a generic IPC system for any possible
application, and intentionally omits many features found in other
IPC systems for this reason.
At the same time, the bus daemons offer a number of features not found in
other IPC systems, such as single-owner "bus names" (similar to X
selections), on-demand startup of services, and security policies.
In many ways, these features are the primary motivation for developing
D-Bus; other systems would have sufficed if IPC were the only goal.
D-Bus may turn out to be useful in unanticipated applications, but future
versions of this spec and the reference implementation probably will not
incorporate features that interfere with the core use cases.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. However, the
document could use a serious audit to be sure it makes sense to do
so. Also, they are not capitalized.
Protocol and Specification Stability
The D-Bus protocol is frozen (only compatible extensions are allowed) as
of November 8, 2006. However, this specification could still use a fair
bit of work to make interoperable reimplementation possible without
reference to the D-Bus reference implementation. Thus, this
specification is not marked 1.0. To mark it 1.0, we'd like to see
someone invest significant effort in clarifying the specification
language, and growing the specification to cover more aspects of the
reference implementation's behavior.
Until this work is complete, any attempt to reimplement D-Bus will
probably require looking at the reference implementation and/or asking
questions on the D-Bus mailing list about intended behavior.
Questions on the list are very welcome.
Nonetheless, this document should be a useful starting point and is
to our knowledge accurate, though incomplete.
Type System
D-Bus has a type system, in which values of various types can be
serialized into a sequence of bytes referred to as the
wire format in a standard way.
Converting a value from some other representation into the wire
format is called marshaling and converting
it back from the wire format is unmarshaling.
The D-Bus protocol does not include type tags in the marshaled data; a
block of marshaled values must have a known type
signature. The type signature is made up of zero or more
single complete
types, each made up of one or more
type codes.
A type code is an ASCII character representing the
type of a value. Because ASCII characters are used, the type signature
will always form a valid ASCII string. A simple string compare
determines whether two type signatures are equivalent.
A single complete type is a sequence of type codes that fully describes
one type: either a basic type, or a single fully-described container type.
A single complete type is a basic type code, a variant type code,
an array with its element type, or a struct with its fields (all of which
are defined below). So the following signatures are not single complete
types:
"aa"
"(ii"
"ii)"
And the following signatures contain multiple complete types:
"ii"
"aiai"
"(ii)(ii)"
Note however that a single complete type may contain
multiple other single complete types, by containing a struct or dict
entry.
Basic types
The simplest type codes are the basic
types, which are the types whose structure is entirely
defined by their 1-character type code. Basic types consist of
fixed types and string-like types.
The fixed types
are basic types whose values have a fixed length, namely BYTE,
BOOLEAN, DOUBLE, UNIX_FD, and signed or unsigned integers of length
16, 32 or 64 bits.
As a simple example, the type code for 32-bit integer (INT32) is
the ASCII character 'i'. So the signature for a block of values
containing a single INT32 would be:
"i"
A block of values containing two INT32 would have this signature:
"ii"
The characteristics of the fixed types are listed in this table.
Conventional nameASCII type-codeEncodingBYTEy (121)Unsigned 8-bit integerBOOLEANb (98)Boolean value: 0 is false, 1 is true, any other value
allowed by the marshalling format is invalidINT16n (110)Signed (two's complement) 16-bit integerUINT16q (113)Unsigned 16-bit integerINT32i (105)Signed (two's complement) 32-bit integerUINT32u (117)Unsigned 32-bit integerINT64x (120)Signed (two's complement) 64-bit integer
(mnemonic: x and t are the first characters in "sixty" not
already used for something more common)UINT64t (116)Unsigned 64-bit integerDOUBLEd (100)IEEE 754 double-precision floating pointUNIX_FDh (104)Unsigned 32-bit integer representing an index into an
out-of-band array of file descriptors, transferred via some
platform-specific mechanism (mnemonic: h for handle)
The string-like types
are basic types with a variable length. The value of any string-like
type is conceptually 0 or more Unicode codepoints encoded in UTF-8,
none of which may be U+0000. The UTF-8 text must be validated
strictly: in particular, it must not contain overlong sequences
or codepoints above U+10FFFF.
Since D-Bus Specification version 0.21, in accordance with Unicode
Corrigendum #9, the "noncharacters" U+FDD0..U+FDEF, U+nFFFE and
U+nFFFF are allowed in UTF-8 strings (but note that older versions of
D-Bus rejected these noncharacters).
The marshalling formats for the string-like types all end with a
single zero (NUL) byte, but that byte is not considered to be part of
the text.
The characteristics of the string-like types are listed in this table.
Conventional nameASCII type-codeValidity constraintsSTRINGs (115)No extra constraintsOBJECT_PATHo (111)Must be
a
syntactically valid object pathSIGNATUREg (103)Zero or more
single
complete typesValid Object Paths
An object path is a name used to refer to an object instance.
Conceptually, each participant in a D-Bus message exchange may have
any number of object instances (think of C++ or Java objects) and each
such instance will have a path. Like a filesystem, the object
instances in an application form a hierarchical tree.
Object paths are often namespaced by starting with a reversed
domain name and containing an interface version number, in the
same way as
interface
names and
well-known
bus names.
This makes it possible to implement more than one service, or
more than one version of a service, in the same process,
even if the services share a connection but cannot otherwise
co-operate (for instance, if they are implemented by different
plugins).
For instance, if the owner of example.com is
developing a D-Bus API for a music player, they might use the
hierarchy of object paths that start with
/com/example/MusicPlayer1 for its objects.
The following rules define a valid object path. Implementations must
not send or accept messages with invalid object paths.
The path may be of any length.
The path must begin with an ASCII '/' (integer 47) character,
and must consist of elements separated by slash characters.
Each element must only contain the ASCII characters
"[A-Z][a-z][0-9]_"
No element may be the empty string.
Multiple '/' characters cannot occur in sequence.
A trailing '/' character is not allowed unless the
path is the root path (a single '/' character).
Valid Signatures
An implementation must not send or accept invalid signatures.
Valid signatures will conform to the following rules:
The signature is a list of single complete types.
Arrays must have element types, and structs must
have both open and close parentheses.
Only type codes, open and close parentheses, and open and
close curly brackets are allowed in the signature. The
STRUCT type code
is not allowed in signatures, because parentheses
are used instead. Similarly, the
DICT_ENTRY type code is not allowed in
signatures, because curly brackets are used instead.
The maximum depth of container type nesting is 32 array type
codes and 32 open parentheses. This implies that the maximum
total depth of recursion is 64, for an "array of array of array
of ... struct of struct of struct of ..." where there are 32
array and 32 struct.
The maximum length of a signature is 255.
When signatures appear in messages, the marshalling format
guarantees that they will be followed by a nul byte (which can
be interpreted as either C-style string termination or the INVALID
type-code), but this is not conceptually part of the signature.
Container types
In addition to basic types, there are four container
types: STRUCT, ARRAY, VARIANT,
and DICT_ENTRY.
STRUCT has a type code, ASCII character 'r', but this type
code does not appear in signatures. Instead, ASCII characters
'(' and ')' are used to mark the beginning and end of the struct.
So for example, a struct containing two integers would have this
signature:
"(ii)"
Structs can be nested, so for example a struct containing
an integer and another struct:
"(i(ii))"
The value block storing that struct would contain three integers; the
type signature allows you to distinguish "(i(ii))" from "((ii)i)" or
"(iii)" or "iii".
The STRUCT type code 'r' is not currently used in the D-Bus protocol,
but is useful in code that implements the protocol. This type code
is specified to allow such code to interoperate in non-protocol contexts.
Empty structures are not allowed; there must be at least one
type code between the parentheses.
ARRAY has ASCII character 'a' as type code. The array type code must be
followed by a single complete type. The single
complete type following the array is the type of each array element. So
the simple example is:
"ai"
which is an array of 32-bit integers. But an array can be of any type,
such as this array-of-struct-with-two-int32-fields:
"a(ii)"
Or this array of array of integer:
"aai"
VARIANT has ASCII character 'v' as its type code. A marshaled value of
type VARIANT will have the signature of a single complete type as part
of the value. This signature will be followed by a
marshaled value of that type.
Unlike a message signature, the variant signature can
contain only a single complete type. So "i", "ai"
or "(ii)" is OK, but "ii" is not. Use of variants may not
cause a total message depth to be larger than 64, including
other container types such as structures.
A DICT_ENTRY works exactly like a struct, but rather
than parentheses it uses curly braces, and it has more restrictions.
The restrictions are: it occurs only as an array element type; it has
exactly two single complete types inside the curly braces; the first
single complete type (the "key") must be a basic type rather than a
container type. Implementations must not accept dict entries outside of
arrays, must not accept dict entries with zero, one, or more than two
fields, and must not accept dict entries with non-basic-typed keys. A
dict entry is always a key-value pair.
The first field in the DICT_ENTRY is always the key.
A message is considered corrupt if the same key occurs twice in the same
array of DICT_ENTRY. However, for performance reasons
implementations are not required to reject dicts with duplicate keys.
In most languages, an array of dict entry would be represented as a
map, hash table, or dict object.
Summary of types
The following table summarizes the D-Bus types.
CategoryConventional NameCodeDescriptionreservedINVALID0 (ASCII NUL)Not a valid type code, used to terminate signaturesfixed, basicBYTE121 (ASCII 'y')8-bit unsigned integerfixed, basicBOOLEAN98 (ASCII 'b')Boolean value, 0 is FALSE and 1 is TRUE. Everything else is invalid.fixed, basicINT16110 (ASCII 'n')16-bit signed integerfixed, basicUINT16113 (ASCII 'q')16-bit unsigned integerfixed, basicINT32105 (ASCII 'i')32-bit signed integerfixed, basicUINT32117 (ASCII 'u')32-bit unsigned integerfixed, basicINT64120 (ASCII 'x')64-bit signed integerfixed, basicUINT64116 (ASCII 't')64-bit unsigned integerfixed, basicDOUBLE100 (ASCII 'd')IEEE 754 doublestring-like, basicSTRING115 (ASCII 's')UTF-8 string (must be valid UTF-8). Must be nul terminated and contain no other nul bytes.string-like, basicOBJECT_PATH111 (ASCII 'o')Name of an object instancestring-like, basicSIGNATURE103 (ASCII 'g')A type signaturecontainerARRAY97 (ASCII 'a')ArraycontainerSTRUCT114 (ASCII 'r'), 40 (ASCII '('), 41 (ASCII ')')Struct; type code 114 'r' is reserved for use in
bindings and implementations to represent the general
concept of a struct, and must not appear in signatures
used on D-Bus.containerVARIANT118 (ASCII 'v') Variant type (the type of the value is part of the value itself)containerDICT_ENTRY101 (ASCII 'e'), 123 (ASCII '{'), 125 (ASCII '}') Entry in a dict or map (array of key-value pairs).
Type code 101 'e' is reserved for use in bindings and
implementations to represent the general concept of a
dict or dict-entry, and must not appear in signatures
used on D-Bus.fixed, basicUNIX_FD104 (ASCII 'h')Unix file descriptorreserved(reserved)109 (ASCII 'm')Reserved for a
'maybe' type compatible with the one in GVariant,
and must not appear in signatures used on D-Bus until
specified herereserved(reserved)42 (ASCII '*')Reserved for use in bindings/implementations to
represent any single complete type,
and must not appear in signatures used on D-Bus.reserved(reserved)63 (ASCII '?')Reserved for use in bindings/implementations to
represent any basic type, and must
not appear in signatures used on D-Bus.reserved(reserved)64 (ASCII '@'), 38 (ASCII '&'),
94 (ASCII '^')Reserved for internal use by bindings/implementations,
and must not appear in signatures used on D-Bus.
GVariant uses these type-codes to encode calling
conventions.Marshaling (Wire Format)
D-Bus defines a marshalling format for its type system, which is
used in D-Bus messages. This is not the only possible marshalling
format for the type system: for instance, GVariant (part of GLib)
re-uses the D-Bus type system but implements an alternative marshalling
format.
Byte order and alignment
Given a type signature, a block of bytes can be converted into typed
values. This section describes the format of the block of bytes. Byte
order and alignment issues are handled uniformly for all D-Bus types.
A block of bytes has an associated byte order. The byte order
has to be discovered in some way; for D-Bus messages, the
byte order is part of the message header as described in
. For now, assume
that the byte order is known to be either little endian or big
endian.
Each value in a block of bytes is aligned "naturally," for example
4-byte values are aligned to a 4-byte boundary, and 8-byte values to an
8-byte boundary. To properly align a value, alignment
padding may be necessary. The alignment padding must always
be the minimum required padding to properly align the following value;
and it must always be made up of nul bytes. The alignment padding must
not be left uninitialized (it can't contain garbage), and more padding
than required must not be used.
As an exception to natural alignment, STRUCT and
DICT_ENTRY values are always aligned to an 8-byte
boundary, regardless of the alignments of their contents.
Marshalling basic types
To marshal and unmarshal fixed types, you simply read one value
from the data block corresponding to each type code in the signature.
All signed integer values are encoded in two's complement, DOUBLE
values are IEEE 754 double-precision floating-point, and BOOLEAN
values are encoded in 32 bits (of which only the least significant
bit is used).
The string-like types are all marshalled as a
fixed-length unsigned integer n giving the
length of the variable part, followed by n
nonzero bytes of UTF-8 text, followed by a single zero (nul) byte
which is not considered to be part of the text. The alignment
of the string-like type is the same as the alignment of
n.
For the STRING and OBJECT_PATH types, n is
encoded in 4 bytes, leading to 4-byte alignment.
For the SIGNATURE type, n is encoded as a single
byte. As a result, alignment padding is never required before a
SIGNATURE.
Marshalling containers
Arrays are marshalled as a UINT32n giving the length of the array data in bytes,
followed by alignment padding to the alignment boundary of the array
element type, followed by the n bytes of the
array elements marshalled in sequence. n does not
include the padding after the length, or any padding after the
last element.
For instance, if the current position in the message is a multiple
of 8 bytes and the byte-order is big-endian, an array containing only
the 64-bit integer 5 would be marshalled as:
00 00 00 08 8 bytes of data
00 00 00 00 padding to 8-byte boundary
00 00 00 00 00 00 00 05 first element = 5
Arrays have a maximum length defined to be 2 to the 26th power or
67108864 (64 MiB). Implementations must not send or accept arrays
exceeding this length.
Structs and dict entries are marshalled in the same way as their
contents, but their alignment is always to an 8-byte boundary,
even if their contents would normally be less strictly aligned.
Variants are marshalled as the SIGNATURE of
the contents (which must be a single complete type), followed by a
marshalled value with the type given by that signature. The
variant has the same 1-byte alignment as the signature, which means
that alignment padding before a variant is never needed.
Use of variants may not cause a total message depth to be larger
than 64, including other container types such as structures.
Summary of D-Bus marshalling
Given all this, the types are marshaled on the wire as follows:
Conventional NameEncodingAlignmentINVALIDNot applicable; cannot be marshaled.N/ABYTEA single 8-bit byte.1BOOLEANAs for UINT32, but only 0 and 1 are valid values.4INT1616-bit signed integer in the message's byte order.2UINT1616-bit unsigned integer in the message's byte order.2INT3232-bit signed integer in the message's byte order.4UINT3232-bit unsigned integer in the message's byte order.4INT6464-bit signed integer in the message's byte order.8UINT6464-bit unsigned integer in the message's byte order.8DOUBLE64-bit IEEE 754 double in the message's byte order.8STRINGA UINT32 indicating the string's
length in bytes excluding its terminating nul, followed by
non-nul string data of the given length, followed by a terminating nul
byte.
4 (for the length)
OBJECT_PATHExactly the same as STRING except the
content must be a valid object path (see above).
4 (for the length)
SIGNATUREThe same as STRING except the length is a single
byte (thus signatures have a maximum length of 255)
and the content must be a valid signature (see above).
1
ARRAY
A UINT32 giving the length of the array data in bytes, followed by
alignment padding to the alignment boundary of the array element type,
followed by each array element.
4 (for the length)
STRUCT
A struct must start on an 8-byte boundary regardless of the
type of the struct fields. The struct value consists of each
field marshaled in sequence starting from that 8-byte
alignment boundary.
8
VARIANT
The marshaled SIGNATURE of a single
complete type, followed by a marshaled value with the type
given in the signature.
1 (alignment of the signature)
DICT_ENTRY
Identical to STRUCT.
8
UNIX_FD32-bit unsigned integer in the message's byte
order. The actual file descriptors need to be
transferred out-of-band via some platform specific
mechanism. On the wire, values of this type store the index to the
file descriptor in the array of file descriptors that
accompany the message.4Message Protocol
A message consists of a
header and a body. If you
think of a message as a package, the header is the address, and the body
contains the package contents. The message delivery system uses the header
information to figure out where to send the message and how to interpret
it; the recipient interprets the body of the message.
The body of the message is made up of zero or more
arguments, which are typed values, such as an
integer or a byte array.
Both header and body use the D-Bus type
system and format for serializing data.
Message Format
A message consists of a header and a body. The header is a block of
values with a fixed signature and meaning. The body is a separate block
of values, with a signature specified in the header.
The length of the header must be a multiple of 8, allowing the body to
begin on an 8-byte boundary when storing the entire message in a single
buffer. If the header does not naturally end on an 8-byte boundary
up to 7 bytes of nul-initialized alignment padding must be added.
The message body need not end on an 8-byte boundary.
The maximum length of a message, including header, header alignment padding,
and body is 2 to the 27th power or 134217728 (128 MiB).
Implementations must not send or accept messages exceeding this size.
The signature of the header is:
"yyyyuua(yv)"
Written out more readably, this is:
BYTE, BYTE, BYTE, BYTE, UINT32, UINT32, ARRAY of STRUCT of (BYTE,VARIANT)
These values have the following meanings:
ValueDescription1st BYTEEndianness flag; ASCII 'l' for little-endian
or ASCII 'B' for big-endian. Both header and body are
in this endianness.2nd BYTEMessage type. Unknown types must be ignored.
Currently-defined types are described below.
3rd BYTEBitwise OR of flags. Unknown flags
must be ignored. Currently-defined flags are described below.
4th BYTEMajor protocol version of the sending application. If
the major protocol version of the receiving application does not
match, the applications will not be able to communicate and the
D-Bus connection must be disconnected. The major protocol
version for this version of the specification is 1.
1st UINT32Length in bytes of the message body, starting
from the end of the header. The header ends after
its alignment padding to an 8-boundary.
2nd UINT32The serial of this message, used as a cookie
by the sender to identify the reply corresponding
to this request. This must not be zero.
ARRAY of STRUCT of (BYTE,VARIANT)An array of zero or more header
fields where the byte is the field code, and the
variant is the field value. The message type determines
which fields are required.
Message types that can appear in the second byte
of the header are:
Conventional nameDecimal valueDescriptionINVALID0This is an invalid type.METHOD_CALL1Method call. This message type may prompt a
reply.METHOD_RETURN2Method reply with returned data.ERROR3Error reply. If the first argument exists and is a
string, it is an error message.SIGNAL4Signal emission.
Flags that can appear in the third byte of the header:
Conventional nameHex valueDescriptionNO_REPLY_EXPECTED0x1
This message does not expect method return replies or
error replies, even if it is of a type that can
have a reply; the reply can be omitted as an
optimization. It is compliant with this specification
to return the reply despite this flag, although doing
so on a bus with a non-trivial security policy
(such as the well-known system bus) may result in
access denial messages being logged for the reply.
Note that METHOD_CALL is the only message type currently
defined in this specification that can expect a reply,
so the presence or absence of this flag in the other
three message types that are currently
documented is meaningless: replies to those message
types should not be sent, whether this flag is present
or not.
NO_AUTO_START0x2The bus must not launch an owner
for the destination name in response to this message.
ALLOW_INTERACTIVE_AUTHORIZATION0x4
This flag may be set on a method call message to
inform the receiving side that the caller is prepared
to wait for interactive authorization, which might
take a considerable time to complete. For instance,
if this flag is set, it would be appropriate to
query the user for passwords or confirmation via
Polkit or a similar framework.
This flag is only useful when
unprivileged code calls a more privileged method call,
and an authorization framework is deployed that allows
possibly interactive authorization. If no such framework
is deployed it has no effect. This flag should not
be set by default by client implementations. If it is
set, the caller should also set a suitably long timeout
on the method call to make sure the user interaction
may complete. This flag is only valid for method call
messages, and shall be ignored otherwise.
Interaction that takes place as a part of the
effect of the method being called is outside the scope
of this flag, even if it could also be characterized
as authentication or authorization. For instance, in
a method call that directs a network management service
to attempt to connect to a virtual private network,
this flag should control how the network management
service makes the decision "is this user allowed to
change system network configuration?", but it should
not affect how or whether the network management
service interacts with the user to obtain the credentials
that are required for access to the VPN.
If a this flag is not set on a method call, and a
service determines that the requested operation is
not allowed without interactive authorization, but
could be allowed after successful interactive
authorization, it may return the
org.freedesktop.DBus.Error.InteractiveAuthorizationRequired
error.
The absence of this flag does not guarantee that
interactive authorization will not be applied, since
existing services that pre-date this flag might
already use interactive authorization. However,
existing D-Bus APIs that will use interactive
authorization should document that the call may take
longer than usual, and new D-Bus APIs should avoid
interactive authorization in the absence of this flag.
Header Fields
The array at the end of the header contains header
fields, where each field is a 1-byte field code followed
by a field value. A header must contain the required header fields for
its message type, and zero or more of any optional 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.
Again, if an implementation sees a header field code that it does not
expect, it must ignore that field, as it will be part of a new
(but compatible) version of this specification. This also applies
to known header fields appearing in unexpected messages, for
example: if a signal has a reply serial it must be ignored
even though it has no meaning as of this version of the spec.
However, implementations must not send or accept known header fields
with the wrong type stored in the field value. So for example a
message with an INTERFACE field of type
UINT32 would be considered corrupt.
Here are the currently-defined header fields:
Conventional NameDecimal CodeTypeRequired InDescriptionINVALID0N/Anot allowedNot a valid field name (error if it appears in a message)PATH1OBJECT_PATHMETHOD_CALL, SIGNALThe object to send a call to,
or the object a signal is emitted from.
The special path
/org/freedesktop/DBus/Local is reserved;
implementations should not send messages with this path,
and the reference implementation of the bus daemon will
disconnect any application that attempts to do so.
INTERFACE2STRINGSIGNAL
The interface to invoke a method call on, or
that a signal is emitted from. Optional for
method calls, required for signals.
The special interface
org.freedesktop.DBus.Local is reserved;
implementations should not send messages with this
interface, and the reference implementation of the bus
daemon will disconnect any application that attempts to
do so.
MEMBER3STRINGMETHOD_CALL, SIGNALThe member, either the method name or signal name.ERROR_NAME4STRINGERRORThe name of the error that occurred, for errorsREPLY_SERIAL5UINT32ERROR, METHOD_RETURNThe serial number of the message this message is a reply
to. (The serial number is the second UINT32 in the header.)DESTINATION6STRINGoptionalThe name of the connection this message is intended for.
Only used in combination with the message bus, see
.SENDER7STRINGoptionalUnique name of the sending connection.
The message bus fills in this field so it is reliable; the field is
only meaningful in combination with the message bus.SIGNATURE8SIGNATUREoptionalThe signature of the message body.
If omitted, it is assumed to be the
empty signature "" (i.e. the body must be 0-length).UNIX_FDS9UINT32optionalThe number of Unix file descriptors that
accompany the message. If omitted, it is assumed
that no Unix file descriptors accompany the
message. The actual file descriptors need to be
transferred via platform specific mechanism
out-of-band. They must be sent at the same time as
part of the message itself. They may not be sent
before the first byte of the message itself is
transferred or after the last byte of the message
itself.Valid Names
The various names in D-Bus messages have some restrictions.
There is a maximum name length
of 255 which applies to bus names, interfaces, and members.
Interface names
Interfaces have names with type STRING, meaning that
they must be valid UTF-8. However, there are also some
additional restrictions that apply to interface names
specifically:
Interface names are composed of 1 or more elements separated by
a period ('.') character. All elements must contain at least
one character.
Each element must only contain the ASCII characters
"[A-Z][a-z][0-9]_" and must not begin with a digit.
Interface names must contain at least one '.' (period)
character (and thus at least two elements).
Interface names must not begin with a '.' (period) character.Interface names must not exceed the maximum name length.
Interface names should start with the reversed DNS domain name of
the author of the interface (in lower-case), like interface names
in Java. It is conventional for the rest of the interface name
to consist of words run together, with initial capital letters
on all words ("CamelCase"). Several levels of hierarchy can be used.
It is also a good idea to include the major version of the interface
in the name, and increment it if incompatible changes are made;
this way, a single object can implement several versions of an
interface in parallel, if necessary.
For instance, if the owner of example.com is
developing a D-Bus API for a music player, they might define
interfaces called com.example.MusicPlayer1,
com.example.MusicPlayer1.Track and
com.example.MusicPlayer1.Seekable.
D-Bus does not distinguish between the concepts that would be
called classes and interfaces in Java: either can be identified on
D-Bus by an interface name.
Bus names
Connections have one or more bus names associated with them.
A connection has exactly one bus name that is a unique
connection name. The unique connection name remains
with the connection for its entire lifetime.
A bus name is of type STRING,
meaning that it must be valid UTF-8. However, there are also
some additional restrictions that apply to bus names
specifically:
Bus names that start with a colon (':')
character are unique connection names. Other bus names
are called well-known bus names.
Bus names are composed of 1 or more elements separated by
a period ('.') character. All elements must contain at least
one character.
Each element must only contain the ASCII characters
"[A-Z][a-z][0-9]_-". Only elements that are part of a unique
connection name may begin with a digit, elements in
other bus names must not begin with a digit.
Bus names must contain at least one '.' (period)
character (and thus at least two elements).
Bus names must not begin with a '.' (period) character.Bus names must not exceed the maximum name length.
Note that the hyphen ('-') character is allowed in bus names but
not in interface names.
Like interface
names, well-known bus names should start with the
reversed DNS domain name of the author of the interface (in
lower-case), and it is conventional for the rest of the well-known
bus name to consist of words run together, with initial
capital letters. As with interface names, including a version
number in well-known bus names is a good idea; it's possible to
have the well-known bus name for more than one version
simultaneously if backwards compatibility is required.
If a well-known bus name implies the presence of a "main" interface,
that "main" interface is often given the same name as
the well-known bus name, and situated at the corresponding object
path. For instance, if the owner of example.com
is developing a D-Bus API for a music player, they might define
that any application that takes the well-known name
com.example.MusicPlayer1 should have an object
at the object path /com/example/MusicPlayer1
which implements the interface
com.example.MusicPlayer1.
Member names
Member (i.e. method or signal) names:
Must only contain the ASCII characters
"[A-Z][a-z][0-9]_" and may not begin with a
digit.Must not contain the '.' (period) character.Must not exceed the maximum name length.Must be at least 1 byte in length.
It is conventional for member names on D-Bus to consist of
capitalized words with no punctuation ("camel-case").
Method names should usually be verbs, such as
GetItems, and signal names should usually be
a description of an event, such as ItemsChanged.
Error names
Error names have the same restrictions as interface names.
Error names have the same naming conventions as interface
names, and often contain .Error.; for instance,
the owner of example.com might define the
errors com.example.MusicPlayer.Error.FileNotFound
and com.example.MusicPlayer.Error.OutOfMemory.
The errors defined by D-Bus itself, such as
org.freedesktop.DBus.Error.Failed, follow a
similar pattern.
Message Types
Each of the message types (METHOD_CALL, METHOD_RETURN, ERROR, and
SIGNAL) has its own expected usage conventions and header fields.
This section describes these conventions.
Method Calls
Some messages invoke an operation on a remote object. These are
called method call messages and have the type tag METHOD_CALL. Such
messages map naturally to methods on objects in a typical program.
A method call message is required to have a MEMBER header field
indicating the name of the method. Optionally, the message has an
INTERFACE field giving the interface the method is a part of.
Including the INTERFACE in all method call
messages is strongly recommended.
In the absence of an INTERFACE field, if two
or more interfaces on the same object have a method with the same
name, it is undefined which of those methods will be invoked.
Implementations may choose to either return an error, or deliver the
message as though it had an arbitrary one of those interfaces.
In some situations (such as the well-known system bus), messages
are filtered through an access-control list external to the
remote object implementation. If that filter rejects certain
messages by matching their interface, or accepts only messages
to specific interfaces, it must also reject messages that have no
INTERFACE: otherwise, malicious
applications could use this to bypass the filter.
Method call messages also include a PATH field
indicating the object to invoke the method on. If the call is passing
through a message bus, the message will also have a
DESTINATION field giving the name of the connection
to receive the message.
When an application handles a method call message, it is required to
return a reply. The reply is identified by a REPLY_SERIAL header field
indicating the serial number of the METHOD_CALL being replied to. The
reply can have one of two types; either METHOD_RETURN or ERROR.
If the reply has type METHOD_RETURN, the arguments to the reply message
are the return value(s) or "out parameters" of the method call.
If the reply has type ERROR, then an "exception" has been thrown,
and the call fails; no return value will be provided. It makes
no sense to send multiple replies to the same method call.
Even if a method call has no return values, a METHOD_RETURN
reply is required, so the caller will know the method
was successfully processed.
The METHOD_RETURN or ERROR reply message must have the REPLY_SERIAL
header field.
If a METHOD_CALL message has the flag NO_REPLY_EXPECTED,
then as an optimization the application receiving the method
call may choose to omit the reply message (regardless of
whether the reply would have been METHOD_RETURN or ERROR).
However, it is also acceptable to ignore the NO_REPLY_EXPECTED
flag and reply anyway.
Unless a message has the flag NO_AUTO_START, if the
destination name does not exist then a program to own the destination
name will be started before the message is delivered. The message
will be held until the new program is successfully started or has
failed to start; in case of failure, an error will be returned. This
flag is only relevant in the context of a message bus, it is ignored
during one-to-one communication with no intermediate bus.
Mapping method calls to native APIs
APIs for D-Bus may map method calls to a method call in a specific
programming language, such as C++, or may map a method call written
in an IDL to a D-Bus message.
In APIs of this nature, arguments to a method are often termed "in"
(which implies sent in the METHOD_CALL), or "out" (which implies
returned in the METHOD_RETURN). Some APIs such as CORBA also have
"inout" arguments, which are both sent and received, i.e. the caller
passes in a value which is modified. Mapped to D-Bus, an "inout"
argument is equivalent to an "in" argument, followed by an "out"
argument. You can't pass things "by reference" over the wire, so
"inout" is purely an illusion of the in-process API.
Given a method with zero or one return values, followed by zero or more
arguments, where each argument may be "in", "out", or "inout", the
caller constructs a message by appending each "in" or "inout" argument,
in order. "out" arguments are not represented in the caller's message.
The recipient constructs a reply by appending first the return value
if any, then each "out" or "inout" argument, in order.
"in" arguments are not represented in the reply message.
Error replies are normally mapped to exceptions in languages that have
exceptions.
In converting from native APIs to D-Bus, it is perhaps nice to
map D-Bus naming conventions ("FooBar") to native conventions
such as "fooBar" or "foo_bar" automatically. This is OK
as long as you can say that the native API is one that
was specifically written for D-Bus. It makes the most sense
when writing object implementations that will be exported
over the bus. Object proxies used to invoke remote D-Bus
objects probably need the ability to call any D-Bus method,
and thus a magic name mapping like this could be a problem.
This specification doesn't require anything of native API bindings;
the preceding is only a suggested convention for consistency
among bindings.
Signal Emission
Unlike method calls, signal emissions have no replies.
A signal emission is simply a single message of type SIGNAL.
It must have three header fields: PATH giving the object
the signal was emitted from, plus INTERFACE and MEMBER giving
the fully-qualified name of the signal. The INTERFACE header is required
for signals, though it is optional for method calls.
Errors
Messages of type ERROR are most commonly replies
to a METHOD_CALL, but may be returned in reply
to any kind of message. The message bus for example
will return an ERROR in reply to a signal emission if
the bus does not have enough memory to send the signal.
An ERROR may have any arguments, but if the first
argument is a STRING, it must be an error message.
The error message may be logged or shown to the user
in some way.
Notation in this document
This document uses a simple pseudo-IDL to describe particular method
calls and signals. Here is an example of a method call:
org.freedesktop.DBus.StartServiceByName (in STRING name, in UINT32 flags,
out UINT32 resultcode)
This means INTERFACE = org.freedesktop.DBus, MEMBER = StartServiceByName,
METHOD_CALL arguments are STRING and UINT32, METHOD_RETURN argument
is UINT32. Remember that the MEMBER field can't contain any '.' (period)
characters so it's known that the last part of the name in
the "IDL" is the member name.
In C++ that might end up looking like this:
unsigned int org::freedesktop::DBus::StartServiceByName (const char *name,
unsigned int flags);
or equally valid, the return value could be done as an argument:
void org::freedesktop::DBus::StartServiceByName (const char *name,
unsigned int flags,
unsigned int *resultcode);
It's really up to the API designer how they want to make
this look. You could design an API where the namespace wasn't used
in C++, using STL or Qt, using varargs, or whatever you wanted.
Signals are written as follows:
org.freedesktop.DBus.NameLost (STRING name)
Signals don't specify "in" vs. "out" because only
a single direction is possible.
It isn't especially encouraged to use this lame pseudo-IDL in actual
API implementations; you might use the native notation for the
language you're using, or you might use COM or CORBA IDL, for example.
Invalid Protocol and Spec Extensions
For security reasons, the D-Bus protocol should be strictly parsed and
validated, with the exception of defined extension points. Any invalid
protocol or spec violations should result in immediately dropping the
connection without notice to the other end. Exceptions should be
carefully considered, e.g. an exception may be warranted for a
well-understood idiosyncrasy of a widely-deployed implementation. In
cases where the other end of a connection is 100% trusted and known to
be friendly, skipping validation for performance reasons could also make
sense in certain cases.
Generally speaking violations of the "must" requirements in this spec
should be considered possible attempts to exploit security, and violations
of the "should" suggestions should be considered legitimate (though perhaps
they should generate an error in some cases).
The following extension points are built in to D-Bus on purpose and must
not be treated as invalid protocol. The extension points are intended
for use by future versions of this spec, they are not intended for third
parties. At the moment, the only way a third party could extend D-Bus
without breaking interoperability would be to introduce a way to negotiate new
feature support as part of the auth protocol, using EXTENSION_-prefixed
commands. There is not yet a standard way to negotiate features.
In the authentication protocol (see ) unknown
commands result in an ERROR rather than a disconnect. This enables
future extensions to the protocol. Commands starting with EXTENSION_ are
reserved for third parties.
The authentication protocol supports pluggable auth mechanisms.
The address format (see ) supports new
kinds of transport.
Messages with an unknown type (something other than
METHOD_CALL, METHOD_RETURN,
ERROR, SIGNAL) are ignored.
Unknown-type messages must still be well-formed in the same way
as the known messages, however. They still have the normal
header and body.
Header fields with an unknown or unexpected field code must be ignored,
though again they must still be well-formed.
New standard interfaces (with new methods and signals) can of course be added.
Authentication Protocol
Before the flow of messages begins, two applications must
authenticate. A simple plain-text protocol is used for
authentication; this protocol is a SASL profile, and maps fairly
directly from the SASL specification. The message encoding is
NOT used here, only plain text messages.
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
Protocol Overview
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:
AUTH [mechanism] [initial-response]CANCELBEGINDATA <data in hex encoding>ERROR [human-readable error explanation]NEGOTIATE_UNIX_FD
From server to client are as follows:
REJECTED <space-separated list of mechanism names>OK <GUID in hex>DATA <data in hex encoding>ERRORAGREE_UNIX_FD
Unofficial extensions to the command set must begin with the letters
"EXTENSION_", to avoid conflicts with future official commands.
For example, "EXTENSION_COM_MYDOMAIN_DO_STUFF".
Special credentials-passing nul byte
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.
AUTH command
If an AUTH command has no arguments, it is a request to list
available mechanisms. The server must respond with a REJECTED
command listing the mechanisms it understands, or with an error.
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 must send either a REJECTED command listing the mechanisms
it does support, or an error.
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 and [initial-response]
was provided, the server should reject authentication by sending
REJECTED.
If authentication succeeds after exchanging DATA commands,
an OK command must be sent to the client.
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.
If BEGIN is received by the server, 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.
CANCEL Command
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.
DATA Command
The DATA command may come from either client or server, and simply
contains a hex-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.
BEGIN Command
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.
REJECTED Command
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.
OK Command
The OK command indicates that the client has been
authenticated. The client may now proceed with negotiating
Unix file descriptor passing. To do that it shall send
NEGOTIATE_UNIX_FD to the server.
Otherwise, 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 BEGIN command has been
received. Further communication will be a stream of D-Bus
messages (optionally encrypted, as negotiated) rather than
this protocol.
If a client sends BEGIN 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 OK command has one argument, which is the GUID of the server.
See for more on server GUIDs.
ERROR Command
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.
If the D-Bus protocol changes incompatibly at some future time,
applications implementing the new protocol would probably be able to
check for support of the new protocol by sending a new command and
receiving an ERROR from applications that don't understand it. Thus the
ERROR feature of the auth protocol is an escape hatch that lets us
negotiate extensions or changes to the D-Bus protocol in the future.
NEGOTIATE_UNIX_FD Command
The NEGOTIATE_UNIX_FD command indicates that the client
supports Unix file descriptor passing. This command may only
be sent after the connection is authenticated, i.e. after OK
was received by the client. This command may only be sent on
transports that support Unix file descriptor passing.
On receiving NEGOTIATE_UNIX_FD the server must respond with
either AGREE_UNIX_FD or ERROR. It shall respond the former if
the transport chosen supports Unix file descriptor passing and
the server supports this feature. It shall respond the latter
if the transport does not support Unix file descriptor
passing, the server does not support this feature, or the
server decides not to enable file descriptor passing due to
security or other reasons.
AGREE_UNIX_FD Command
The AGREE_UNIX_FD command indicates that the server supports
Unix file descriptor passing. This command may only be sent
after the connection is authenticated, and the client sent
NEGOTIATE_UNIX_FD to enable Unix file descriptor passing. This
command may only be sent on transports that support Unix file
descriptor passing.
On receiving AGREE_UNIX_FD the client must respond with BEGIN,
followed by its stream of messages, or by disconnecting. The
server must not accept additional commands using this protocol
after the BEGIN command has been received. Further
communication will be a stream of D-Bus messages (optionally
encrypted, as negotiated) rather than this protocol.
Future Extensions
Future extensions to the authentication and negotiation
protocol are possible. For that new commands may be
introduced. If a client or server receives an unknown command
it shall respond with ERROR and not consider this fatal. New
commands may be introduced both before, and after
authentication, i.e. both before and after the OK command.
Authentication examplesExample of successful magic cookie authentication
(MAGIC_COOKIE is a made up mechanism)
C: AUTH MAGIC_COOKIE 3138363935333137393635383634
S: OK 1234deadbeef
C: BEGIN
Example of finding out mechanisms then picking one
C: AUTH
S: REJECTED KERBEROS_V4 SKEY
C: AUTH SKEY 7ab83f32ee
S: DATA 8799cabb2ea93e
C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
S: OK 1234deadbeef
C: BEGIN
Example of client sends unknown command then falls back to regular auth
C: FOOBAR
S: ERROR
C: AUTH MAGIC_COOKIE 3736343435313230333039
S: OK 1234deadbeef
C: BEGIN
Example of server doesn't support initial auth mechanism
C: AUTH MAGIC_COOKIE 3736343435313230333039
S: REJECTED KERBEROS_V4 SKEY
C: AUTH SKEY 7ab83f32ee
S: DATA 8799cabb2ea93e
C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
S: OK 1234deadbeef
C: BEGIN
Example of wrong password or the like followed by successful retry
C: AUTH MAGIC_COOKIE 3736343435313230333039
S: REJECTED KERBEROS_V4 SKEY
C: AUTH SKEY 7ab83f32ee
S: DATA 8799cabb2ea93e
C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
S: REJECTED
C: AUTH SKEY 7ab83f32ee
S: DATA 8799cabb2ea93e
C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
S: OK 1234deadbeef
C: BEGIN
Example of skey cancelled and restarted
C: AUTH MAGIC_COOKIE 3736343435313230333039
S: REJECTED KERBEROS_V4 SKEY
C: AUTH SKEY 7ab83f32ee
S: DATA 8799cabb2ea93e
C: CANCEL
S: REJECTED
C: AUTH SKEY 7ab83f32ee
S: DATA 8799cabb2ea93e
C: DATA 8ac876e8f68ee9809bfa876e6f9876g8fa8e76e98f
S: OK 1234deadbeef
C: BEGIN
Example of successful magic cookie authentication with successful negotiation of Unix FD passing
(MAGIC_COOKIE is a made up mechanism)
C: AUTH MAGIC_COOKIE 3138363935333137393635383634
S: OK 1234deadbeef
C: NEGOTIATE_UNIX_FD
S: AGREE_UNIX_FD
C: BEGIN
Example of successful magic cookie authentication with unsuccessful negotiation of Unix FD passing
(MAGIC_COOKIE is a made up mechanism)
C: AUTH MAGIC_COOKIE 3138363935333137393635383634
S: OK 1234deadbeef
C: NEGOTIATE_UNIX_FD
S: ERROR
C: BEGIN
Authentication state diagrams
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.
Client states
To more precisely describe the interaction between the
protocol state machine and the authentication mechanisms the
following notation is used: MECH(CHALL) means that the
server challenge CHALL was fed to the mechanism MECH, which
returns one of
CONTINUE(RESP) means continue the auth conversation
and send RESP as the response to the server;
OK(RESP) means that after sending RESP to the server
the client side of the auth conversation is finished
and the server should return "OK";
ERROR means that CHALL was invalid and could not be
processed.
Both RESP and CHALL may be empty.
The Client starts by getting an initial response from the
default mechanism and sends AUTH MECH RESP, or AUTH MECH if
the mechanism did not provide an initial response. If the
mechanism returns CONTINUE, the client starts in state
WaitingForData, if the mechanism
returns OK the client starts in state
WaitingForOK.
The client should keep track of available mechanisms and
which it mechanisms it has already attempted. This list is
used to decide which AUTH command to send. When the list is
exhausted, the client should give up and close the
connection.
<emphasis>WaitingForData</emphasis>
Receive DATA CHALL
MECH(CHALL) returns CONTINUE(RESP) → send
DATA RESP, goto
WaitingForData
MECH(CHALL) returns OK(RESP) → send DATA
RESP, goto WaitingForOK
MECH(CHALL) returns ERROR → send ERROR
[msg], goto WaitingForData
Receive REJECTED [mechs] →
send AUTH [next mech], goto
WaitingForData or WaitingForOK
Receive ERROR → send
CANCEL, goto
WaitingForReject
Receive OK → send
BEGIN, terminate auth
conversation, authenticated
Receive anything else → send
ERROR, goto
WaitingForData<emphasis>WaitingForOK</emphasis>
Receive OK → send BEGIN, terminate auth
conversation, authenticated
Receive REJECTED [mechs] → send AUTH [next mech],
goto WaitingForData or
WaitingForOK
Receive DATA → send CANCEL, goto
WaitingForReject
Receive ERROR → send CANCEL, goto
WaitingForReject
Receive anything else → send ERROR, goto
WaitingForOK<emphasis>WaitingForReject</emphasis>
Receive REJECTED [mechs] → send AUTH [next mech],
goto WaitingForData or
WaitingForOK
Receive anything else → terminate auth
conversation, disconnect
Server states
For the server MECH(RESP) means that the client response
RESP was fed to the the mechanism MECH, which returns one of
CONTINUE(CHALL) means continue the auth conversation and
send CHALL as the challenge to the client;
OK means that the client has been successfully
authenticated;
REJECTED means that the client failed to authenticate or
there was an error in RESP.
The server starts out in state
WaitingForAuth. If the client is
rejected too many times the server must disconnect the
client.
<emphasis>WaitingForAuth</emphasis>
Receive AUTH → send REJECTED [mechs], goto
WaitingForAuth
Receive AUTH MECH RESP
MECH not valid mechanism → send REJECTED
[mechs], goto
WaitingForAuth
MECH(RESP) returns CONTINUE(CHALL) → send
DATA CHALL, goto
WaitingForData
MECH(RESP) returns OK → send OK, goto
WaitingForBegin
MECH(RESP) returns REJECTED → send REJECTED
[mechs], goto
WaitingForAuth
Receive BEGIN → terminate
auth conversation, disconnect
Receive ERROR → send REJECTED [mechs], goto
WaitingForAuth
Receive anything else → send
ERROR, goto
WaitingForAuth<emphasis>WaitingForData</emphasis>
Receive DATA RESP
MECH(RESP) returns CONTINUE(CHALL) → send
DATA CHALL, goto
WaitingForData
MECH(RESP) returns OK → send OK, goto
WaitingForBegin
MECH(RESP) returns REJECTED → send REJECTED
[mechs], goto
WaitingForAuth
Receive BEGIN → terminate auth conversation,
disconnect
Receive CANCEL → send REJECTED [mechs], goto
WaitingForAuth
Receive ERROR → send REJECTED [mechs], goto
WaitingForAuth
Receive anything else → send ERROR, goto
WaitingForData<emphasis>WaitingForBegin</emphasis>
Receive BEGIN → terminate auth conversation,
client authenticated
Receive CANCEL → send REJECTED [mechs], goto
WaitingForAuth
Receive ERROR → send REJECTED [mechs], goto
WaitingForAuth
Receive anything else → send ERROR, goto
WaitingForBeginAuthentication mechanisms
This section describes some new authentication mechanisms.
D-Bus also allows any standard SASL mechanism of course.
DBUS_COOKIE_SHA1
The DBUS_COOKIE_SHA1 mechanism is designed to establish that a client
has the ability to read a private file owned by the user being
authenticated. If the client can prove that it has access to a secret
cookie stored in this file, then the client is authenticated.
Thus the security of DBUS_COOKIE_SHA1 depends on a secure home
directory.
Throughout this description, "hex encoding" must output the digits
from a to f in lower-case; the digits A to F must not be used
in the DBUS_COOKIE_SHA1 mechanism.
Authentication proceeds as follows:
The client sends the username it would like to authenticate
as, hex-encoded.
The server sends the name of its "cookie context" (see below); a
space character; the integer ID of the secret cookie the client
must demonstrate knowledge of; a space character; then a
randomly-generated challenge string, all of this hex-encoded into
one, single string.
The client locates the cookie and generates its own
randomly-generated challenge string. The client then concatenates
the server's decoded challenge, a ":" character, its own challenge,
another ":" character, and the cookie. It computes the SHA-1 hash
of this composite string as a hex digest. It concatenates the
client's challenge string, a space character, and the SHA-1 hex
digest, hex-encodes the result and sends it back to the server.
The server generates the same concatenated string used by the
client and computes its SHA-1 hash. It compares the hash with
the hash received from the client; if the two hashes match, the
client is authenticated.
Each server has a "cookie context," which is a name that identifies a
set of cookies that apply to that server. A sample context might be
"org_freedesktop_session_bus". Context names must be valid ASCII,
nonzero length, and may not contain the characters slash ("/"),
backslash ("\"), space (" "), newline ("\n"), carriage return ("\r"),
tab ("\t"), or period ("."). There is a default context,
"org_freedesktop_general" that's used by servers that do not specify
otherwise.
Cookies are stored in a user's home directory, in the directory
~/.dbus-keyrings/. This directory must
not be readable or writable by other users. If it is,
clients and servers must ignore it. The directory
contains cookie files named after the cookie context.
A cookie file contains one cookie per line. Each line
has three space-separated fields:
The cookie ID number, which must be a non-negative integer and
may not be used twice in the same file.
The cookie's creation time, in UNIX seconds-since-the-epoch
format.
The cookie itself, a hex-encoded random block of bytes. The cookie
may be of any length, though obviously security increases
as the length increases.
Only server processes modify the cookie file.
They must do so with this procedure:
Create a lockfile name by appending ".lock" to the name of the
cookie file. The server should attempt to create this file
using O_CREAT | O_EXCL. If file creation
fails, the lock fails. Servers should retry for a reasonable
period of time, then they may choose to delete an existing lock
to keep users from having to manually delete a stale
lock. Lockfiles are used instead of real file
locking fcntl() because real locking
implementations are still flaky on network
filesystems.
Once the lockfile has been created, the server loads the cookie
file. It should then delete any cookies that are old (the
timeout can be fairly short), or more than a reasonable
time in the future (so that cookies never accidentally
become permanent, if the clock was set far into the future
at some point). If no recent keys remain, the
server may generate a new key.
The pruned and possibly added-to cookie file
must be resaved atomically (using a temporary
file which is rename()'d).
The lock must be dropped by deleting the lockfile.
Clients need not lock the file in order to load it,
because servers are required to save the file atomically.
Server Addresses
Server addresses consist of a transport name followed by a colon, and
then an optional, comma-separated list of keys and values in the form key=value.
Each value is escaped.
For example:
unix:path=/tmp/dbus-test
Which is the address to a unix socket with the path /tmp/dbus-test.
Value escaping is similar to URI escaping but simpler.
The set of optionally-escaped bytes is:
[0-9A-Za-z_-/.\]. To escape, each
byte (note, not character) which is not in the
set of optionally-escaped bytes must be replaced with an ASCII
percent (%) and the value of the byte in hex.
The hex value must always be two digits, even if the first digit is
zero. The optionally-escaped bytes may be escaped if desired.
To unescape, append each byte in the value; if a byte is an ASCII
percent (%) character then append the following
hex value instead. It is an error if a % byte
does not have two hex digits following. It is an error if a
non-optionally-escaped byte is seen unescaped.
The set of optionally-escaped bytes is intended to preserve address
readability and convenience.
A server may specify a key-value pair with the key guid
and the value a hex-encoded 16-byte sequence.
describes the format of the guid field. If present,
this UUID may be used to distinguish one server address from another. A
server should use a different UUID for each address it listens on. For
example, if a message bus daemon offers both UNIX domain socket and TCP
connections, but treats clients the same regardless of how they connect,
those two connections are equivalent post-connection but should have
distinct UUIDs to distinguish the kinds of connection.
The intent of the address UUID feature is to allow a client to avoid
opening multiple identical connections to the same server, by allowing the
client to check whether an address corresponds to an already-existing
connection. Comparing two addresses is insufficient, because addresses
can be recycled by distinct servers, and equivalent addresses may look
different if simply compared as strings (for example, the host in a TCP
address can be given as an IP address or as a hostname).
Note that the address key is guid even though the
rest of the API and documentation says "UUID," for historical reasons.
[FIXME clarify if attempting to connect to each is a requirement
or just a suggestion]
When connecting to a server, multiple server addresses can be
separated by a semi-colon. The library will then try to connect
to the first address and if that fails, it'll try to connect to
the next one specified, and so forth. For example
unix:path=/tmp/dbus-test;unix:path=/tmp/dbus-test2
Some addresses are connectable. A connectable
address is one containing enough information for a client to connect
to it. For instance, tcp:host=127.0.0.1,port=4242
is a connectable address. It is not necessarily possible to listen
on every connectable address: for instance, it is not possible to
listen on a unixexec: address.
Some addresses are listenable. A listenable
address is one containing enough information for a server to listen on
it, producing a connectable address (which may differ from the
original address). Many listenable addresses are not connectable:
for instance, tcp:host=127.0.0.1
is listenable, but not connectable (because it does not specify
a port number).
Listening on an address that is not connectable will result in a
connectable address that is not the same as the listenable address.
For instance, listening on tcp:host=127.0.0.1
might result in the connectable address
tcp:host=127.0.0.1,port=30958,
listening on unix:tmpdir=/tmp
might result in the connectable address
unix:abstract=/tmp/dbus-U8OSdmf7, or
listening on unix:runtime=yes
might result in the connectable address
unix:path=/run/user/1234/bus.
Transports
[FIXME we need to specify in detail each transport and its possible arguments]
Current transports include: unix domain sockets (including
abstract namespace on linux), launchd, systemd, TCP/IP, an executed subprocess and a debug/testing transport
using in-process pipes. Future possible transports include one that
tunnels over X11 protocol.
Unix Domain Sockets
Unix domain sockets can be either paths in the file system or on Linux
kernels, they can be abstract which are similar to paths but
do not show up in the file system.
When a socket is opened by the D-Bus library it truncates the path
name right before the first trailing Nul byte. This is true for both
normal paths and abstract paths. Note that this is a departure from
previous versions of D-Bus that would create sockets with a fixed
length path name. Names which were shorter than the fixed length
would be padded by Nul bytes.
Unix domain sockets are not available on Windows.
Unix addresses that specify path or
abstract are both listenable and connectable.
Unix addresses that specify tmpdir are only
listenable: the corresponding connectable address will specify
either path or abstract.
Similarly, Unix addresses that specify runtime
are only listenable, and the corresponding connectable address
will specify path.
Server Address Format
Unix domain socket addresses are identified by the "unix:" prefix
and support the following key/value pairs:
NameValuesDescriptionpath(path)path of the unix domain socket. If set, the "tmpdir" and "abstract" key must not be set.tmpdir(path)temporary directory in which a socket file with a random file name starting with 'dbus-' will be created by the server. This key can only be used in server addresses, not in client addresses. If set, the "path" and "abstract" key must not be set.abstract(string)unique string (path) in the abstract namespace. If set, the "path" or "tmpdir" key must not be set. This key is only supported on platforms with "abstract Unix sockets", of which Linux is the only known example.runtimeyesIf given, This key can only be used in server addresses, not in client addresses. If set, its value must be yes. This is typically used in an address string like unix:runtime=yes;unix:tmpdir=/tmp so that there can be a fallback if XDG_RUNTIME_DIR is not set.
Exactly one of the keys path,
abstract, runtime or
tmpdir must be provided.
launchd
launchd is an open-source server management system that replaces init, inetd
and cron on Apple Mac OS X versions 10.4 and above. It provides a common session
bus address for each user and deprecates the X11-enabled D-Bus launcher on OSX.
launchd allocates a socket and provides it with the unix path through the
DBUS_LAUNCHD_SESSION_BUS_SOCKET variable in launchd's environment. Every process
spawned by launchd (or dbus-daemon, if it was started by launchd) can access
it through its environment.
Other processes can query for the launchd socket by executing:
$ launchctl getenv DBUS_LAUNCHD_SESSION_BUS_SOCKET
This is normally done by the D-Bus client library so doesn't have to be done
manually.
launchd is not available on Microsoft Windows.
launchd addresses are listenable and connectable.
Server Address Format
launchd addresses are identified by the "launchd:" prefix
and support the following key/value pairs:
NameValuesDescriptionenv(environment variable)path of the unix domain socket for the launchd created dbus-daemon.
The env key is required.
systemd
systemd is an open-source server management system that
replaces init and inetd on newer Linux systems. It supports
socket activation. The D-Bus systemd transport is used to acquire
socket activation file descriptors from systemd and use them
as D-Bus transport when the current process is spawned by
socket activation from it.
The systemd transport accepts only one or more Unix domain or
TCP streams sockets passed in via socket activation.
The systemd transport is not available on non-Linux operating systems.
The systemd transport defines no parameter keys.
systemd addresses are listenable, but not connectable. The
corresponding connectable address is the unix
or tcp address of the socket.
TCP Sockets
The tcp transport provides TCP/IP based connections between clients
located on the same or different hosts.
Using tcp transport without any additional secure authentification mechanismus
over a network is unsecure.
On Windows and most Unix platforms, the TCP stack is unable to transfer
credentials over a TCP connection, so the EXTERNAL authentication
mechanism does not work for this transport.
All tcp addresses are listenable.
tcp addresses in which both
host and port are
specified, and port is non-zero,
are also connectable.
Server Address Format
TCP/IP socket addresses are identified by the "tcp:" prefix
and support the following key/value pairs:
NameValuesDescriptionhost(string)DNS name or IP addressbind(string)Used in a listenable address to configure the interface
on which the server will listen: either the IP address of one of
the local machine's interfaces (most commonly 127.0.0.1
), or a DNS name that resolves to one of those IP
addresses, or '*' to listen on all interfaces simultaneously.
If not specified, the default is the same value as "host".
port(number)The tcp port the server will open. A zero value let the server
choose a free port provided from the underlaying operating system.
libdbus is able to retrieve the real used port from the server.
family(string)If set, provide the type of socket family either "ipv4" or "ipv6". If unset, the family is unspecified.Nonce-secured TCP Sockets
The nonce-tcp transport provides a secured TCP transport, using a
simple authentication mechanism to ensure that only clients with read
access to a certain location in the filesystem can connect to the server.
The server writes a secret, the nonce, to a file and an incoming client
connection is only accepted if the client sends the nonce right after
the connect. The nonce mechanism requires no setup and is orthogonal to
the higher-level authentication mechanisms described in the
Authentication section.
On start, the server generates a random 16 byte nonce and writes it
to a file in the user's temporary directory. The nonce file location
is published as part of the server's D-Bus address using the
"noncefile" key-value pair.
After an accept, the server reads 16 bytes from the socket. If the
read bytes do not match the nonce stored in the nonce file, the
server MUST immediately drop the connection.
If the nonce match the received byte sequence, the client is accepted
and the transport behaves like an unsecured tcp transport.
After a successful connect to the server socket, the client MUST read
the nonce from the file published by the server via the noncefile=
key-value pair and send it over the socket. After that, the
transport behaves like an unsecured tcp transport.
All nonce-tcp addresses are listenable. nonce-tcp addresses in which
host, port and
noncefile are all specified,
and port is nonzero, are also connectable.
Server Address Format
Nonce TCP/IP socket addresses uses the "nonce-tcp:" prefix
and support the following key/value pairs:
NameValuesDescriptionhost(string)DNS name or IP addressbind(string)The same as for tcp: addresses
port(number)The tcp port the server will open. A zero value let the server
choose a free port provided from the underlaying operating system.
libdbus is able to retrieve the real used port from the server.
family(string)If set, provide the type of socket family either "ipv4" or "ipv6". If unset, the family is unspecified.noncefile(path)File location containing the secret.
This is only meaningful in connectable addresses:
a listening D-Bus server that offers this transport
will always create a new nonce file.Executed Subprocesses on Unix
This transport forks off a process and connects its standard
input and standard output with an anonymous Unix domain
socket. This socket is then used for communication by the
transport. This transport may be used to use out-of-process
forwarder programs as basis for the D-Bus protocol.
The forked process will inherit the standard error output and
process group from the parent process.
Executed subprocesses are not available on Windows.
unixexec addresses are connectable, but are not
listenable.
Server Address Format
Executed subprocess addresses are identified by the "unixexec:" prefix
and support the following key/value pairs:
NameValuesDescriptionpath(path)Path of the binary to execute, either an absolute
path or a binary name that is searched for in the default
search path of the OS. This corresponds to the first
argument of execlp(). This key is mandatory.argv0(string)The program name to use when executing the
binary. If omitted the same value as specified for path=
will be used. This corresponds to the second argument of
execlp().argv1, argv2, ...(string)Arguments to pass to the binary. This corresponds
to the third and later arguments of execlp(). If a
specific argvX is not specified no further argvY for Y > X
are taken into account.Meta Transports
Meta transports are a kind of transport with special enhancements or
behavior. Currently available meta transports include: autolaunch
AutolaunchThe autolaunch transport provides a way for dbus clients to autodetect
a running dbus session bus and to autolaunch a session bus if not present.
On Unix, autolaunch addresses are connectable,
but not listenable.
On Windows, autolaunch addresses are both
connectable and listenable.
Server Address Format
Autolaunch addresses uses the "autolaunch:" prefix and support the
following key/value pairs:
NameValuesDescriptionscope(string)scope of autolaunch (Windows only)
"*install-path" - limit session bus to dbus installation path.
The dbus installation path is determined from the location of
the shared dbus library. If the library is located in a 'bin'
subdirectory the installation root is the directory above,
otherwise the directory where the library lives is taken as
installation root.
<install-root>/bin/[lib]dbus-1.dll
<install-root>/[lib]dbus-1.dll
"*user" - limit session bus to the recent user.
other values - specify dedicated session bus like "release",
"debug" or other
Windows implementation
On start, the server opens a platform specific transport, creates a mutex
and a shared memory section containing the related session bus address.
This mutex will be inspected by the dbus client library to detect a
running dbus session bus. The access to the mutex and the shared memory
section are protected by global locks.
In the recent implementation the autolaunch transport uses a tcp transport
on localhost with a port choosen from the operating system. This detail may
change in the future.
Disclaimer: The recent implementation is in an early state and may not
work in all cirumstances and/or may have security issues. Because of this
the implementation is not documentated yet.
UUIDs
A working D-Bus implementation uses universally-unique IDs in two places.
First, each server address has a UUID identifying the address,
as described in . Second, each operating
system kernel instance running a D-Bus client or server has a UUID
identifying that kernel, retrieved by invoking the method
org.freedesktop.DBus.Peer.GetMachineId() (see ).
The term "UUID" in this document is intended literally, i.e. an
identifier that is universally unique. It is not intended to refer to
RFC4122, and in fact the D-Bus UUID is not compatible with that RFC.
The UUID must contain 128 bits of data and be hex-encoded. The
hex-encoded string may not contain hyphens or other non-hex-digit
characters, and it must be exactly 32 characters long. To generate a
UUID, the current reference implementation concatenates 96 bits of random
data followed by the 32-bit time in seconds since the UNIX epoch (in big
endian byte order).
It would also be acceptable and probably better to simply generate 128
bits of random data, as long as the random number generator is of high
quality. The timestamp could conceivably help if the random bits are not
very random. With a quality random number generator, collisions are
extremely unlikely even with only 96 bits, so it's somewhat academic.
Implementations should, however, stick to random data for the first 96 bits
of the UUID.
Standard Interfaces
See for details on
the notation used in this section. There are some standard interfaces
that may be useful across various D-Bus applications.
<literal>org.freedesktop.DBus.Peer</literal>
The org.freedesktop.DBus.Peer interface
has two methods:
org.freedesktop.DBus.Peer.Ping ()
org.freedesktop.DBus.Peer.GetMachineId (out STRING machine_uuid)
On receipt of the METHOD_CALL message
org.freedesktop.DBus.Peer.Ping, an application should do
nothing other than reply with a METHOD_RETURN as
usual. It does not matter which object path a ping is sent to. The
reference implementation handles this method automatically.
On receipt of the METHOD_CALL message
org.freedesktop.DBus.Peer.GetMachineId, an application should
reply with a METHOD_RETURN containing a hex-encoded
UUID representing the identity of the machine the process is running on.
This UUID must be the same for all processes on a single system at least
until that system next reboots. It should be the same across reboots
if possible, but this is not always possible to implement and is not
guaranteed.
It does not matter which object path a GetMachineId is sent to. The
reference implementation handles this method automatically.
The UUID is intended to be per-instance-of-the-operating-system, so may represent
a virtual machine running on a hypervisor, rather than a physical machine.
Basically if two processes see the same UUID, they should also see the same
shared memory, UNIX domain sockets, process IDs, and other features that require
a running OS kernel in common between the processes.
The UUID is often used where other programs might use a hostname. Hostnames
can change without rebooting, however, or just be "localhost" - so the UUID
is more robust.
explains the format of the UUID.
<literal>org.freedesktop.DBus.Introspectable</literal>
This interface has one method:
org.freedesktop.DBus.Introspectable.Introspect (out STRING xml_data)
Objects instances may implement
Introspect which returns an XML description of
the object, including its interfaces (with signals and methods), objects
below it in the object path tree, and its properties.
describes the format of this XML string.
<literal>org.freedesktop.DBus.Properties</literal>
Many native APIs will have a concept of object properties
or attributes. These can be exposed via the
org.freedesktop.DBus.Properties interface.
org.freedesktop.DBus.Properties.Get (in STRING interface_name,
in STRING property_name,
out VARIANT value);
org.freedesktop.DBus.Properties.Set (in STRING interface_name,
in STRING property_name,
in VARIANT value);
org.freedesktop.DBus.Properties.GetAll (in STRING interface_name,
out DICT<STRING,VARIANT> props);
It is conventional to give D-Bus properties names consisting of
capitalized words without punctuation ("CamelCase"), like
member names.
For instance, the GObject property
connection-status or the Qt property
connectionStatus could be represented on D-Bus
as ConnectionStatus.
Strictly speaking, D-Bus property names are not required to follow
the same naming restrictions as member names, but D-Bus property
names that would not be valid member names (in particular,
GObject-style dash-separated property names) can cause interoperability
problems and should be avoided.
The available properties and whether they are writable can be determined
by calling org.freedesktop.DBus.Introspectable.Introspect,
see .
An empty string may be provided for the interface name; in this case,
if there are multiple properties on an object with the same name,
the results are undefined (picking one by according to an arbitrary
deterministic rule, or returning an error, are the reasonable
possibilities).
If one or more properties change on an object, the
org.freedesktop.DBus.Properties.PropertiesChanged
signal may be emitted (this signal was added in 0.14):
org.freedesktop.DBus.Properties.PropertiesChanged (STRING interface_name,
DICT<STRING,VARIANT> changed_properties,
ARRAY<STRING> invalidated_properties);
where changed_properties is a dictionary
containing the changed properties with the new values and
invalidated_properties is an array of
properties that changed but the value is not conveyed.
Whether the PropertiesChanged signal is
supported can be determined by calling
org.freedesktop.DBus.Introspectable.Introspect. Note
that the signal may be supported for an object but it may
differ how whether and how it is used on a per-property basis
(for e.g. performance or security reasons). Each property (or
the parent interface) must be annotated with the
org.freedesktop.DBus.Property.EmitsChangedSignal
annotation to convey this (usually the default value
true is sufficient meaning that the
annotation does not need to be used). See for details on this
annotation.
<literal>org.freedesktop.DBus.ObjectManager</literal>
An API can optionally make use of this interface for one or
more sub-trees of objects. The root of each sub-tree implements
this interface so other applications can get all objects,
interfaces and properties in a single method call. It is
appropriate to use this interface if users of the tree of
objects are expected to be interested in all interfaces of all
objects in the tree; a more granular API should be used if
users of the objects are expected to be interested in a small
subset of the objects, a small subset of their interfaces, or
both.
The method that applications can use to get all objects and
properties is GetManagedObjects:
org.freedesktop.DBus.ObjectManager.GetManagedObjects (out DICT<OBJPATH,DICT<STRING,DICT<STRING,VARIANT>>> objpath_interfaces_and_properties);
The return value of this method is a dict whose keys are
object paths. All returned object paths are children of the
object path implementing this interface, i.e. their object
paths start with the ObjectManager's object path plus '/'.
Each value is a dict whose keys are interfaces names. Each
value in this inner dict is the same dict that would be
returned by the org.freedesktop.DBus.Properties.GetAll()
method for that combination of object path and interface. If
an interface has no properties, the empty dict is returned.
Changes are emitted using the following two signals:
org.freedesktop.DBus.ObjectManager.InterfacesAdded (OBJPATH object_path,
DICT<STRING,DICT<STRING,VARIANT>> interfaces_and_properties);
org.freedesktop.DBus.ObjectManager.InterfacesRemoved (OBJPATH object_path,
ARRAY<STRING> interfaces);
The InterfacesAdded signal is emitted when
either a new object is added or when an existing object gains
one or more interfaces. The
InterfacesRemoved signal is emitted
whenever an object is removed or it loses one or more
interfaces. The second parameter of the
InterfacesAdded signal contains a dict with
the interfaces and properties (if any) that have been added to
the given object path. Similarly, the second parameter of the
InterfacesRemoved signal contains an array
of the interfaces that were removed. Note that changes on
properties on existing interfaces are not reported using this
interface - an application should also monitor the existing PropertiesChanged
signal on each object.
Applications SHOULD NOT export objects that are children of an
object (directly or otherwise) implementing this interface but
which are not returned in the reply from the
GetManagedObjects() method of this
interface on the given object.
The intent of the ObjectManager interface
is to make it easy to write a robust client
implementation. The trivial client implementation only needs
to make two method calls:
org.freedesktop.DBus.AddMatch (bus_proxy,
"type='signal',name='org.example.App',path_namespace='/org/example/App'");
objects = org.freedesktop.DBus.ObjectManager.GetManagedObjects (app_proxy);
on the message bus and the remote application's
ObjectManager, respectively. Whenever a new
remote object is created (or an existing object gains a new
interface), the InterfacesAdded signal is
emitted, and since this signal contains all properties for the
interfaces, no calls to the
org.freedesktop.Properties interface on the
remote object are needed. Additionally, since the initial
AddMatch() rule already includes signal
messages from the newly created child object, no new
AddMatch() call is needed.
The org.freedesktop.DBus.ObjectManager
interface was added in version 0.17 of the D-Bus
specification.
Introspection Data Format
As described in ,
objects may be introspected at runtime, returning an XML string
that describes the object. The same XML format may be used in
other contexts as well, for example as an "IDL" for generating
static language bindings.
Here is an example of introspection data:
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<node name="/com/example/sample_object">
<interface name="com.example.SampleInterface">
<method name="Frobate">
<arg name="foo" type="i" direction="in"/>
<arg name="bar" type="s" direction="out"/>
<arg name="baz" type="a{us}" direction="out"/>
<annotation name="org.freedesktop.DBus.Deprecated" value="true"/>
</method>
<method name="Bazify">
<arg name="bar" type="(iiu)" direction="in"/>
<arg name="bar" type="v" direction="out"/>
</method>
<method name="Mogrify">
<arg name="bar" type="(iiav)" direction="in"/>
</method>
<signal name="Changed">
<arg name="new_value" type="b"/>
</signal>
<property name="Bar" type="y" access="readwrite"/>
</interface>
<node name="child_of_sample_object"/>
<node name="another_child_of_sample_object"/>
</node>
A more formal DTD and spec needs writing, but here are some quick notes.
Only the root <node> element can omit the node name, as it's
known to be the object that was introspected. If the root
<node> does have a name attribute, it must be an absolute
object path. If child <node> have object paths, they must be
relative.
If a child <node> has any sub-elements, then they
must represent a complete introspection of the child.
If a child <node> is empty, then it may or may
not have sub-elements; the child must be introspected
in order to find out. The intent is that if an object
knows that its children are "fast" to introspect
it can go ahead and return their information, but
otherwise it can omit it.
The direction element on <arg> may be omitted,
in which case it defaults to "in" for method calls
and "out" for signals. Signals only allow "out"
so while direction may be specified, it's pointless.
The possible directions are "in" and "out",
unlike CORBA there is no "inout"
The possible property access flags are
"readwrite", "read", and "write"
Multiple interfaces can of course be listed for
one <node>.
The "name" attribute on arguments is optional.
Method, interface, property, and signal elements may have
"annotations", which are generic key/value pairs of metadata.
They are similar conceptually to Java's annotations and C# attributes.
Well-known annotations:
NameValues (separated by ,)Descriptionorg.freedesktop.DBus.Deprecatedtrue,falseWhether or not the entity is deprecated; defaults to falseorg.freedesktop.DBus.GLib.CSymbol(string)The C symbol; may be used for methods and interfacesorg.freedesktop.DBus.Method.NoReplytrue,falseIf set, don't expect a reply to the method call; defaults to false.org.freedesktop.DBus.Property.EmitsChangedSignaltrue,invalidates,const,false
If set to false, the
org.freedesktop.DBus.Properties.PropertiesChanged
signal, see is not
guaranteed to be emitted if the property changes.
If set to const the property never
changes value during the lifetime of the object it
belongs to, and hence the signal is never emitted for
it.
If set to invalidates the signal
is emitted but the value is not included in the
signal.
If set to true the signal is
emitted with the value included.
The value for the annotation defaults to
true if the enclosing interface
element does not specify the annotation. Otherwise it
defaults to the value specified in the enclosing
interface element.
This annotation is intended to be used by code
generators to implement client-side caching of
property values. For all properties for which the
annotation is set to const,
invalidates or
true the client may
unconditionally cache the values as the properties
don't change or notifications are generated for them
if they do.
Message Bus SpecificationMessage Bus Overview
The message bus accepts connections from one or more applications.
Once connected, applications can exchange messages with other
applications that are also connected to the bus.
In order to route messages among connections, the message bus keeps a
mapping from names to connections. Each connection has one
unique-for-the-lifetime-of-the-bus name automatically assigned.
Applications may request additional names for a connection. Additional
names are usually "well-known names" such as
"com.example.TextEditor". When a name is bound to a connection,
that connection is said to own the name.
The bus itself owns a special name,
org.freedesktop.DBus, with an object
located at /org/freedesktop/DBus that
implements the org.freedesktop.DBus
interface. This service allows applications to make
administrative requests of the bus itself. For example,
applications can ask the bus to assign a name to a connection.
Each name may have queued owners. When an
application requests a name for a connection and the name is already in
use, the bus will optionally add the connection to a queue waiting for
the name. If the current owner of the name disconnects or releases
the name, the next connection in the queue will become the new owner.
This feature causes the right thing to happen if you start two text
editors for example; the first one may request "com.example.TextEditor",
and the second will be queued as a possible owner of that name. When
the first exits, the second will take over.
Applications may send unicast messages to
a specific recipient or to the message bus itself, or
broadcast messages to all interested recipients.
See for details.
Message Bus Names
Each connection has at least one name, assigned at connection time and
returned in response to the
org.freedesktop.DBus.Hello method call. This
automatically-assigned name is called the connection's unique
name. Unique names are never reused for two different
connections to the same bus.
Ownership of a unique name is a prerequisite for interaction with
the message bus. It logically follows that the unique name is always
the first name that an application comes to own, and the last
one that it loses ownership of.
Unique connection names must begin with the character ':' (ASCII colon
character); bus names that are not unique names must not begin
with this character. (The bus must reject any attempt by an application
to manually request a name beginning with ':'.) This restriction
categorically prevents "spoofing"; messages sent to a unique name
will always go to the expected connection.
When a connection is closed, all the names that it owns are deleted (or
transferred to the next connection in the queue if any).
A connection can request additional names to be associated with it using
the org.freedesktop.DBus.RequestName message. describes the format of a valid
name. These names can be released again using the
org.freedesktop.DBus.ReleaseName message.
<literal>org.freedesktop.DBus.RequestName</literal>
As a method:
UINT32 RequestName (in STRING name, in UINT32 flags)
Message arguments:
ArgumentTypeDescription0STRINGName to request1UINT32Flags
Reply arguments:
ArgumentTypeDescription0UINT32Return value
This method call should be sent to
org.freedesktop.DBus and asks the message bus to
assign the given name to the method caller. Each name maintains a
queue of possible owners, where the head of the queue is the primary
or current owner of the name. Each potential owner in the queue
maintains the DBUS_NAME_FLAG_ALLOW_REPLACEMENT and
DBUS_NAME_FLAG_DO_NOT_QUEUE settings from its latest RequestName
call. When RequestName is invoked the following occurs:
If the method caller is currently the primary owner of the name,
the DBUS_NAME_FLAG_ALLOW_REPLACEMENT and DBUS_NAME_FLAG_DO_NOT_QUEUE
values are updated with the values from the new RequestName call,
and nothing further happens.
If the current primary owner (head of the queue) has
DBUS_NAME_FLAG_ALLOW_REPLACEMENT set, and the RequestName
invocation has the DBUS_NAME_FLAG_REPLACE_EXISTING flag, then
the caller of RequestName replaces the current primary owner at
the head of the queue and the current primary owner moves to the
second position in the queue. If the caller of RequestName was
in the queue previously its flags are updated with the values from
the new RequestName in addition to moving it to the head of the queue.
If replacement is not possible, and the method caller is
currently in the queue but not the primary owner, its flags are
updated with the values from the new RequestName call.
If replacement is not possible, and the method caller is
currently not in the queue, the method caller is appended to the
queue.
If any connection in the queue has DBUS_NAME_FLAG_DO_NOT_QUEUE
set and is not the primary owner, it is removed from the
queue. This can apply to the previous primary owner (if it
was replaced) or the method caller (if it updated the
DBUS_NAME_FLAG_DO_NOT_QUEUE flag while still stuck in the
queue, or if it was just added to the queue with that flag set).
Note that DBUS_NAME_FLAG_REPLACE_EXISTING results in "jumping the
queue," even if another application already in the queue had specified
DBUS_NAME_FLAG_REPLACE_EXISTING. This comes up if a primary owner
that does not allow replacement goes away, and the next primary owner
does allow replacement. In this case, queued items that specified
DBUS_NAME_FLAG_REPLACE_EXISTING do not
automatically replace the new primary owner. In other words,
DBUS_NAME_FLAG_REPLACE_EXISTING is not saved, it is only used at the
time RequestName is called. This is deliberate to avoid an infinite loop
anytime two applications are both DBUS_NAME_FLAG_ALLOW_REPLACEMENT
and DBUS_NAME_FLAG_REPLACE_EXISTING.
The flags argument contains any of the following values logically ORed
together:
Conventional NameValueDescriptionDBUS_NAME_FLAG_ALLOW_REPLACEMENT0x1
If an application A specifies this flag and succeeds in
becoming the owner of the name, and another application B
later calls RequestName with the
DBUS_NAME_FLAG_REPLACE_EXISTING flag, then application A
will lose ownership and receive a
org.freedesktop.DBus.NameLost signal, and
application B will become the new owner. If DBUS_NAME_FLAG_ALLOW_REPLACEMENT
is not specified by application A, or DBUS_NAME_FLAG_REPLACE_EXISTING
is not specified by application B, then application B will not replace
application A as the owner.
DBUS_NAME_FLAG_REPLACE_EXISTING0x2
Try to replace the current owner if there is one. If this
flag is not set the application will only become the owner of
the name if there is no current owner. If this flag is set,
the application will replace the current owner if
the current owner specified DBUS_NAME_FLAG_ALLOW_REPLACEMENT.
DBUS_NAME_FLAG_DO_NOT_QUEUE0x4
Without this flag, if an application requests a name that is
already owned, the application will be placed in a queue to
own the name when the current owner gives it up. If this
flag is given, the application will not be placed in the
queue, the request for the name will simply fail. This flag
also affects behavior when an application is replaced as
name owner; by default the application moves back into the
waiting queue, unless this flag was provided when the application
became the name owner.
The return code can be one of the following values:
Conventional NameValueDescriptionDBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER1The caller is now the primary owner of
the name, replacing any previous owner. Either the name had no
owner before, or the caller specified
DBUS_NAME_FLAG_REPLACE_EXISTING and the current owner specified
DBUS_NAME_FLAG_ALLOW_REPLACEMENT.DBUS_REQUEST_NAME_REPLY_IN_QUEUE2The name already had an owner,
DBUS_NAME_FLAG_DO_NOT_QUEUE was not specified, and either
the current owner did not specify
DBUS_NAME_FLAG_ALLOW_REPLACEMENT or the requesting
application did not specify DBUS_NAME_FLAG_REPLACE_EXISTING.
DBUS_REQUEST_NAME_REPLY_EXISTS3The name already has an owner,
DBUS_NAME_FLAG_DO_NOT_QUEUE was specified, and either
DBUS_NAME_FLAG_ALLOW_REPLACEMENT was not specified by the
current owner, or DBUS_NAME_FLAG_REPLACE_EXISTING was not
specified by the requesting application.DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER4The application trying to request ownership of a name is already the owner of it.<literal>org.freedesktop.DBus.ReleaseName</literal>
As a method:
UINT32 ReleaseName (in STRING name)
Message arguments:
ArgumentTypeDescription0STRINGName to release
Reply arguments:
ArgumentTypeDescription0UINT32Return value
This method call should be sent to
org.freedesktop.DBus and asks the message bus to
release the method caller's claim to the given name. If the caller is
the primary owner, a new primary owner will be selected from the
queue if any other owners are waiting. If the caller is waiting in
the queue for the name, the caller will removed from the queue and
will not be made an owner of the name if it later becomes available.
If there are no other owners in the queue for the name, it will be
removed from the bus entirely.
The return code can be one of the following values:
Conventional NameValueDescriptionDBUS_RELEASE_NAME_REPLY_RELEASED1The caller has released his claim on
the given name. Either the caller was the primary owner of
the name, and the name is now unused or taken by somebody
waiting in the queue for the name, or the caller was waiting
in the queue for the name and has now been removed from the
queue.DBUS_RELEASE_NAME_REPLY_NON_EXISTENT2The given name does not exist on this bus.DBUS_RELEASE_NAME_REPLY_NOT_OWNER3The caller was not the primary owner of this name,
and was also not waiting in the queue to own this name.<literal>org.freedesktop.DBus.ListQueuedOwners</literal>
As a method:
ARRAY of STRING ListQueuedOwners (in STRING name)
Message arguments:
ArgumentTypeDescription0STRINGThe well-known bus name to query, such as
com.example.cappuccino
Reply arguments:
ArgumentTypeDescription0ARRAY of STRINGThe unique bus names of connections currently queued
for the name
This method call should be sent to
org.freedesktop.DBus and lists the connections
currently queued for a bus name (see
).
Message Bus Message Routing
Messages may have a DESTINATION field (see ), resulting in a
unicast message. If the
DESTINATION field is present, it specifies a message
recipient by name. Method calls and replies normally specify this field.
The message bus must send messages (of any type) with the
DESTINATION field set to the specified recipient,
regardless of whether the recipient has set up a match rule matching
the message.
When the message bus receives a signal, if the
DESTINATION field is absent, it is considered to
be a broadcast signal, and is sent to all
applications with message matching rules that
match the message. Most signal messages are broadcasts, and
no other message types currently defined in this specification
may be broadcast.
Unicast signal messages (those with a DESTINATION
field) are not commonly used, but they are treated like any unicast
message: they are delivered to the specified receipient,
regardless of its match rules. One use for unicast signals is to
avoid a race condition in which a signal is emitted before the intended
recipient can call to
receive that signal: if the signal is sent directly to that recipient
using a unicast message, it does not need to add a match rule at all,
and there is no race condition. Another use for unicast signals,
on message buses whose security policy prevents eavesdropping, is to
send sensitive information which should only be visible to one
recipient.
When the message bus receives a method call, if the
DESTINATION field is absent, the call is taken to be
a standard one-to-one message and interpreted by the message bus
itself. For example, sending an
org.freedesktop.DBus.Peer.Ping message with no
DESTINATION will cause the message bus itself to
reply to the ping immediately; the message bus will not make this
message visible to other applications.
Continuing the org.freedesktop.DBus.Peer.Ping example, if
the ping message were sent with a DESTINATION 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.
Message bus implementations may impose a security policy which
prevents certain messages from being sent or received.
When a method call message cannot be sent or received due to a security
policy, the message bus should send an error reply, unless the
original message had the NO_REPLY flag.
Eavesdropping
Receiving a unicast message whose DESTINATION
indicates a different recipient is called
eavesdropping. On a message bus which acts as
a security boundary (like the standard system bus), the security
policy should usually prevent eavesdropping, since unicast messages
are normally kept private and may contain security-sensitive
information.
Eavesdropping is mainly useful for debugging tools, such as
the dbus-monitor tool in the reference
implementation of D-Bus. Tools which eavesdrop on the message bus
should be careful to avoid sending a reply or error in response to
messages intended for a different client.
Clients may attempt to eavesdrop by adding match rules
(see ) containing
the eavesdrop='true' match. If the message bus'
security policy does not allow eavesdropping, the match rule can
still be added, but will not have any practical effect. For
compatibility with older message bus implementations, if adding such
a match rule results in an error reply, the client may fall back to
adding the same rule with the eavesdrop match
omitted.
Eavesdropping interacts poorly with buses with non-trivial
access control restrictions. The
method provides
an alternative way to monitor buses.
Match Rules
An important part of the message bus routing protocol is match
rules. Match rules describe the messages that should be sent to a
client, based on the contents of the message. Broadcast signals
are only sent to clients which have a suitable match rule: this
avoids waking up client processes to deal with signals that are
not relevant to that client.
Messages that list a client as their DESTINATION
do not need to match the client's match rules, and are sent to that
client regardless. As a result, match rules are mainly used to
receive a subset of broadcast signals.
Match rules can also be used for eavesdropping
(see ),
if the security policy of the message bus allows it.
Match rules are added using the AddMatch bus method
(see ). Rules are
specified as a string of comma separated key/value pairs.
Excluding a key from the rule indicates a wildcard match.
For instance excluding the the member from a match rule but
adding a sender would let all messages from that sender through.
An example of a complete rule would be
"type='signal',sender='org.freedesktop.DBus',interface='org.freedesktop.DBus',member='Foo',path='/bar/foo',destination=':452345.34',arg2='bar'"
Within single quotes (ASCII apostrophe, U+0027), a backslash
(U+005C) represents itself, and an apostrophe ends the quoted
section. Outside single quotes, \' (backslash, apostrophe)
represents an apostrophe, and any backslash not followed by
an apostrophe represents itself. For instance, the match rules
arg0=''\''',arg1='\',arg2=',',arg3='\\' and
arg0=\',arg1=\,arg2=',',arg3=\\
both match messages where the arguments are a 1-character string
containing an apostrophe, a 1-character string containing a
backslash, a 1-character string containing a comma, and a
2-character string containing two backslashes
This idiosyncratic quoting style is based on the rules for
escaping items to appear inside single-quoted strings
in POSIX /bin/sh, but please
note that backslashes that are not inside single quotes have
different behaviour. This syntax does not offer any way to
represent an apostrophe inside single quotes (it is necessary
to leave the single-quoted section, backslash-escape the
apostrophe and re-enter single quotes), or to represent a
comma outside single quotes (it is necessary to wrap it in
a single-quoted section).
.
The following table describes the keys that can be used to create
a match rule.
KeyPossible ValuesDescriptiontype'signal', 'method_call', 'method_return', 'error'Match on the message type. An example of a type match is type='signal'senderA bus or unique name (see
and respectively)
Match messages sent by a particular sender. An example of a sender match
is sender='org.freedesktop.Hal'interfaceAn interface name (see )Match messages sent over or to a particular interface. An example of an
interface match is interface='org.freedesktop.Hal.Manager'.
If a message omits the interface header, it must not match any rule
that specifies this key.memberAny valid method or signal nameMatches messages which have the give method or signal name. An example of
a member match is member='NameOwnerChanged'pathAn object path (see )Matches messages which are sent from or to the given object. An example of a
path match is path='/org/freedesktop/Hal/Manager'path_namespaceAn object path
Matches messages which are sent from or to an
object for which the object path is either the
given value, or that value followed by one or
more path components.
For example,
path_namespace='/com/example/foo'
would match signals sent by
/com/example/foo
or by
/com/example/foo/bar,
but not by
/com/example/foobar.
Using both path and
path_namespace in the same match
rule is not allowed.
This match key was added in version 0.16 of the
D-Bus specification and implemented by the bus
daemon in dbus 1.5.0 and later.
destinationA unique name (see )Matches messages which are being sent to the given unique name. An
example of a destination match is destination=':1.0'arg[0, 1, 2, 3, ...]Any stringArg matches are special and are used for further restricting the
match based on the arguments in the body of a message. Only arguments of type
STRING can be matched in this way. An example of an argument match
would be arg3='Foo'. Only argument indexes from 0 to 63 should be
accepted.arg[0, 1, 2, 3, ...]pathAny stringArgument path matches provide a specialised form of wildcard matching for
path-like namespaces. They can match arguments whose type is either STRING or
OBJECT_PATH. As with normal argument matches,
if the argument is exactly equal to the string given in the match
rule then the rule is satisfied. Additionally, there is also a
match when either the string given in the match rule or the
appropriate message argument ends with '/' and is a prefix of the
other. An example argument path match is arg0path='/aa/bb/'. This
would match messages with first arguments of '/', '/aa/',
'/aa/bb/', '/aa/bb/cc/' and '/aa/bb/cc'. It would not match
messages with first arguments of '/aa/b', '/aa' or even '/aa/bb'.This is intended for monitoring “directories” in file system-like
hierarchies, as used in the dconf configuration
system. An application interested in all nodes in a particular hierarchy would
monitor arg0path='/ca/example/foo/'. Then the service could
emit a signal with zeroth argument "/ca/example/foo/bar" to
represent a modification to the “bar” property, or a signal with zeroth
argument "/ca/example/" to represent atomic modification of
many properties within that directory, and the interested application would be
notified in both cases.
This match key was added in version 0.12 of the
D-Bus specification, implemented for STRING
arguments by the bus daemon in dbus 1.2.0 and later,
and implemented for OBJECT_PATH arguments in dbus 1.5.0
and later.
arg0namespaceLike a bus name, except that the string is not
required to contain a '.' (period)Match messages whose first argument is of type STRING, and is a bus name
or interface name within the specified namespace. This is primarily intended
for watching name owner changes for a group of related bus names, rather than
for a single name or all name changes.Because every valid interface name is also a valid
bus name, this can also be used for messages whose
first argument is an interface name.For example, the match rule
member='NameOwnerChanged',arg0namespace='com.example.backend'
matches name owner changes for bus names such as
com.example.backend.foo,
com.example.backend.foo.bar, and
com.example.backend itself.See also .
This match key was added in version 0.16 of the
D-Bus specification and implemented by the bus
daemon in dbus 1.5.0 and later.
eavesdrop'true', 'false'Since D-Bus 1.5.6, match rules do not
match messages which have a DESTINATION
field unless the match rule specifically
requests this
(see )
by specifying eavesdrop='true'
in the match rule. eavesdrop='false'
restores the default behaviour. Messages are
delivered to their DESTINATION
regardless of match rules, so this match does not
affect normal delivery of unicast messages.
If the message bus has a security policy which forbids
eavesdropping, this match may still be used without error,
but will not have any practical effect.
In older versions of D-Bus, this match was not allowed
in match rules, and all match rules behaved as if
eavesdrop='true' had been used.
Message Bus Starting Services
The message bus can start applications on behalf of other applications.
In CORBA terms, this would be called activation.
An application that can be started in this way is called a
service.
With D-Bus, starting a service is normally done by name. That is,
applications ask the message bus to start some program that will own a
well-known name, such as com.example.TextEditor.
This implies a contract documented along with the name
com.example.TextEditor for which object
the owner of that name will provide, and what interfaces those
objects will have.
To find an executable corresponding to a particular name, the bus daemon
looks for service description files. Service
description files define a mapping from names to executables. Different
kinds of message bus will look for these files in different places, see
.
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.
On the well-known system bus, the name of a service description file
must be its well-known name plus .service,
for instance
com.example.ConfigurationDatabase.service.
On the well-known session bus, services should follow the same
service description file naming convention as on the system bus,
but for backwards compatibility they are not required to do so.
[FIXME the file format should be much better specified than "similar to
.desktop entries" esp. since desktop entries are already
badly-specified. ;-)]
These sections from the specification apply to service files as well:
General syntaxComment format
Service description files must contain a
D-BUS Service group with at least the keys
Name (the well-known name of the service)
and Exec (the command to be executed).
Example service description file
# Sample service description file
[D-BUS Service]
Name=com.example.ConfigurationDatabase
Exec=/usr/bin/sample-configd
Additionally, service description files for the well-known system
bus on Unix must contain a User key, whose value
is the name of a user account (e.g. root).
The system service will be run as that user.
When an application asks to start a service by name, the bus daemon tries to
find a service that will own that name. It then tries to spawn the
executable associated with it. If this fails, it will report an
error.
On the well-known system bus, it is not possible for two .service files
in the same directory to offer the same service, because they are
constrained to have names that match the service name.
On the well-known session bus, if two .service files in the same
directory offer the same service name, the result is undefined.
Distributors should avoid this situation, for instance by naming
session services' .service files according to their service name.
If two .service files in different directories offer the same
service name, the one in the higher-priority directory is used:
for instance, on the system bus, .service files in
/usr/local/share/dbus-1/system-services take precedence over those
in /usr/share/dbus-1/system-services.
The executable launched will have the environment variable
DBUS_STARTER_ADDRESS set to the address of the
message bus so it can connect and request the appropriate names.
The executable being launched may want to know whether the message bus
starting it is one of the well-known message buses (see ). To facilitate this, the bus must also set
the DBUS_STARTER_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 new executable must still connect to the address given
in DBUS_STARTER_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.]
Message Bus Service Scope
The "scope" of a service is its "per-", such as per-session,
per-machine, per-home-directory, or per-display. The reference
implementation doesn't yet support starting services in a different
scope from the message bus itself. So e.g. if you start a service
on the session bus its scope is per-session.
We could add an optional scope to a bus name. For example, for
per-(display,session pair), we could have a unique ID for each display
generated automatically at login and set on screen 0 by executing a
special "set display ID" binary. The ID would be stored in a
_DBUS_DISPLAY_ID property and would be a string of
random bytes. This ID would then be used to scope names.
Starting/locating a service could be done by ID-name pair rather than
only by name.
Contrast this with a per-display scope. To achieve that, we would
want a single bus spanning all sessions using a given display.
So we might set a _DBUS_DISPLAY_BUS_ADDRESS
property on screen 0 of the display, pointing to this bus.
Well-known Message Bus Instances
Two standard message bus instances are defined here, along with how
to locate them and where their service files live.
Login session message bus
Each time a user logs in, a login session message
bus may be started. All applications in the user's login
session may interact with one another using this message bus.
The address of the login session message bus is given
in the DBUS_SESSION_BUS_ADDRESS environment
variable. If that variable is not set, applications may
also try to read the address from the X Window System root
window property _DBUS_SESSION_BUS_ADDRESS.
The root window property must have type STRING.
The environment variable should have precedence over the
root window property.
The address of the login session message bus is given in the
DBUS_SESSION_BUS_ADDRESS environment variable. If
DBUS_SESSION_BUS_ADDRESS is not set, or if it's set to the string
"autolaunch:", the system should use platform-specific methods of
locating a running D-Bus session server, or starting one if a running
instance cannot be found. Note that this mechanism is not recommended
for attempting to determine if a daemon is running. It is inherently
racy to attempt to make this determination, since the bus daemon may
be started just before or just after the determination is made.
Therefore, it is recommended that applications do not try to make this
determination for their functionality purposes, and instead they
should attempt to start the server.X Windowing System
For the X Windowing System, the application must locate the
window owner of the selection represented by the atom formed by
concatenating:
the literal string "_DBUS_SESSION_BUS_SELECTION_"the current user's usernamethe literal character '_' (underscore)the machine's ID
The following properties are defined for the window that owns
this X selection:
Atommeaning_DBUS_SESSION_BUS_ADDRESSthe actual address of the server socket_DBUS_SESSION_BUS_PIDthe PID of the server process
At least the _DBUS_SESSION_BUS_ADDRESS property MUST be
present in this window.
If the X selection cannot be located or if reading the
properties from the window fails, the implementation MUST conclude
that there is no D-Bus server running and proceed to start a new
server. (See below on concurrency issues)
Failure to connect to the D-Bus server address thus obtained
MUST be treated as a fatal connection error and should be reported
to the application.
As an alternative, an implementation MAY find the information
in the following file located in the current user's home directory,
in subdirectory .dbus/session-bus/:
the machine's IDthe literal character '-' (dash)the X display without the screen number, with the
following prefixes removed, if present: ":", "localhost:"
."localhost.localdomain:". That is, a display of
"localhost:10.0" produces just the number "10"
The contents of this file NAME=value assignment pairs and
lines starting with # are comments (no comments are allowed
otherwise). The following variable names are defined:
VariablemeaningDBUS_SESSION_BUS_ADDRESSthe actual address of the server socketDBUS_SESSION_BUS_PIDthe PID of the server processDBUS_SESSION_BUS_WINDOWIDthe window ID
At least the DBUS_SESSION_BUS_ADDRESS variable MUST be present
in this file.
Failure to open this file MUST be interpreted as absence of a
running server. Therefore, the implementation MUST proceed to
attempting to launch a new bus server if the file cannot be
opened.
However, success in opening this file MUST NOT lead to the
conclusion that the server is running. Thus, a failure to connect to
the bus address obtained by the alternative method MUST NOT be
considered a fatal error. If the connection cannot be established,
the implementation MUST proceed to check the X selection settings or
to start the server on its own.
If the implementation concludes that the D-Bus server is not
running it MUST attempt to start a new server and it MUST also
ensure that the daemon started as an effect of the "autolaunch"
mechanism provides the lookup mechanisms described above, so
subsequent calls can locate the newly started server. The
implementation MUST also ensure that if two or more concurrent
initiations happen, only one server remains running and all other
initiations are able to obtain the address of this server and
connect to it. In other words, the implementation MUST ensure that
the X selection is not present when it attempts to set it, without
allowing another process to set the selection between the
verification and the setting (e.g., by using XGrabServer /
XungrabServer).
On Unix systems, the session bus should search for .service files
in $XDG_DATA_DIRS/dbus-1/services as defined
by the
XDG Base Directory Specification.
Implementations may also search additional locations, which
should be searched with lower priority than anything in
XDG_DATA_HOME, XDG_DATA_DIRS or their respective defaults;
for example, the reference implementation also
looks in ${datadir}/dbus-1/services as
set at compile time.
As described in the XDG Base Directory Specification, software
packages should install their session .service files to their
configured ${datadir}/dbus-1/services,
where ${datadir} is as defined by the GNU
coding standards. System administrators or users can arrange
for these service files to be read by setting XDG_DATA_DIRS or by
symlinking them into the default locations.
System message bus
A computer may have a system message bus,
accessible to all applications on the system. This message bus may be
used to broadcast system events, such as adding new hardware devices,
changes in the printer queue, and so forth.
The address of the system message bus is given
in the DBUS_SYSTEM_BUS_ADDRESS environment
variable. If that variable is not set, applications should try
to connect to the well-known address
unix:path=/var/run/dbus/system_bus_socket.
The D-Bus reference implementation actually honors the
$(localstatedir) configure option
for this address, on both client and server side.
On Unix systems, the system bus should default to searching
for .service files in
/usr/local/share/dbus-1/system-services,
/usr/share/dbus-1/system-services and
/lib/dbus-1/system-services, with that order
of precedence. It may also search other implementation-specific
locations, but should not vary these locations based on environment
variables.
The system bus is security-sensitive and is typically executed
by an init system with a clean environment. Its launch helper
process is particularly security-sensitive, and specifically
clears its own environment.
Software packages should install their system .service
files to their configured
${datadir}/dbus-1/system-services,
where ${datadir} is as defined by the GNU
coding standards. System administrators can arrange
for these service files to be read by editing the system bus'
configuration file or by symlinking them into the default
locations.
Message Bus Messages
The special message bus name org.freedesktop.DBus
responds to a number of additional messages.
<literal>org.freedesktop.DBus.Hello</literal>
As a method:
STRING Hello ()
Reply arguments:
ArgumentTypeDescription0STRINGUnique name assigned to the connection
Before an application is able to send messages to other applications
it must send the org.freedesktop.DBus.Hello message
to the message bus to obtain a unique name. If an application without
a unique name tries to send a message to another application, or a
message to the message bus itself that isn't the
org.freedesktop.DBus.Hello message, it will be
disconnected from the bus.
There is no corresponding "disconnect" request; if a client wishes to
disconnect from the bus, it simply closes the socket (or other
communication channel).
<literal>org.freedesktop.DBus.ListNames</literal>
As a method:
ARRAY of STRING ListNames ()
Reply arguments:
ArgumentTypeDescription0ARRAY of STRINGArray of strings where each string is a bus name
Returns a list of all currently-owned names on the bus.
<literal>org.freedesktop.DBus.ListActivatableNames</literal>
As a method:
ARRAY of STRING ListActivatableNames ()
Reply arguments:
ArgumentTypeDescription0ARRAY of STRINGArray of strings where each string is a bus name
Returns a list of all names that can be activated on the bus.
<literal>org.freedesktop.DBus.NameHasOwner</literal>
As a method:
BOOLEAN NameHasOwner (in STRING name)
Message arguments:
ArgumentTypeDescription0STRINGName to check
Reply arguments:
ArgumentTypeDescription0BOOLEANReturn value, true if the name exists
Checks if the specified name exists (currently has an owner).
<literal>org.freedesktop.DBus.NameOwnerChanged</literal>
This is a signal:
NameOwnerChanged (STRING name, STRING old_owner, STRING new_owner)
Message arguments:
ArgumentTypeDescription0STRINGName with a new owner1STRINGOld owner or empty string if none2STRINGNew owner or empty string if none
This signal indicates that the owner of a name has changed.
It's also the signal to use to detect the appearance of
new names on the bus.
<literal>org.freedesktop.DBus.NameLost</literal>
This is a signal:
NameLost (STRING name)
Message arguments:
ArgumentTypeDescription0STRINGName which was lost
This signal is sent to a specific application when it loses
ownership of a name.
<literal>org.freedesktop.DBus.NameAcquired</literal>
This is a signal:
NameAcquired (STRING name)
Message arguments:
ArgumentTypeDescription0STRINGName which was acquired
This signal is sent to a specific application when it gains
ownership of a name.
<literal>org.freedesktop.DBus.StartServiceByName</literal>
As a method:
UINT32 StartServiceByName (in STRING name, in UINT32 flags)
Message arguments:
ArgumentTypeDescription0STRINGName of the service to start1UINT32Flags (currently not used)
Reply arguments:
ArgumentTypeDescription0UINT32Return value
Tries to launch the executable associated with a name. For more information, see .
The return value can be one of the following values:
IdentifierValueDescriptionDBUS_START_REPLY_SUCCESS1The service was successfully started.DBUS_START_REPLY_ALREADY_RUNNING2A connection already owns the given name.<literal>org.freedesktop.DBus.UpdateActivationEnvironment</literal>
As a method:
UpdateActivationEnvironment (in ARRAY of DICT<STRING,STRING> environment)
Message arguments:
ArgumentTypeDescription0ARRAY of DICT<STRING,STRING>Environment to add or update
Normally, session bus activated services inherit the environment of the bus daemon. This method adds to or modifies that environment when activating services.
Some bus instances, such as the standard system bus, may disable access to this method for some or all callers.
Note, both the environment variable names and values must be valid UTF-8. There's no way to update the activation environment with data that is invalid UTF-8.
<literal>org.freedesktop.DBus.GetNameOwner</literal>
As a method:
STRING GetNameOwner (in STRING name)
Message arguments:
ArgumentTypeDescription0STRINGName to get the owner of
Reply arguments:
ArgumentTypeDescription0STRINGReturn value, a unique connection name
Returns the unique connection name of the primary owner of the name
given. If the requested name doesn't have an owner, returns a
org.freedesktop.DBus.Error.NameHasNoOwner error.
<literal>org.freedesktop.DBus.GetConnectionUnixUser</literal>
As a method:
UINT32 GetConnectionUnixUser (in STRING bus_name)
Message arguments:
ArgumentTypeDescription0STRINGUnique or well-known bus name of the connection to
query, such as :12.34 or
com.example.tea
Reply arguments:
ArgumentTypeDescription0UINT32Unix user ID
Returns the Unix user ID of the process connected to the server. If
unable to determine it (for instance, because the process is not on the
same machine as the bus daemon), an error is returned.
<literal>org.freedesktop.DBus.GetConnectionUnixProcessID</literal>
As a method:
UINT32 GetConnectionUnixProcessID (in STRING bus_name)
Message arguments:
ArgumentTypeDescription0STRINGUnique or well-known bus name of the connection to
query, such as :12.34 or
com.example.tea
Reply arguments:
ArgumentTypeDescription0UINT32Unix process id
Returns the Unix process ID of the process connected to the server. If
unable to determine it (for instance, because the process is not on the
same machine as the bus daemon), an error is returned.
<literal>org.freedesktop.DBus.GetConnectionCredentials</literal>
As a method:
DICT<STRING,VARIANT> GetConnectionCredentials (in STRING bus_name)
Message arguments:
ArgumentTypeDescription0STRINGUnique or well-known bus name of the connection to
query, such as :12.34 or
com.example.tea
Reply arguments:
ArgumentTypeDescription0DICT<STRING,VARIANT>Credentials
Returns as many credentials as possible for the process connected to
the server. If unable to determine certain credentials (for instance,
because the process is not on the same machine as the bus daemon,
or because this version of the bus daemon does not support a
particular security framework), or if the values of those credentials
cannot be represented as documented here, then those credentials
are omitted.
Keys in the returned dictionary not containing "." are defined
by this specification. Bus daemon implementors supporting
credentials frameworks not mentioned in this document should either
contribute patches to this specification, or use keys containing
"." and starting with a reversed domain name.
KeyValue typeValueUnixUserIDUINT32The numeric Unix user ID, as defined by POSIXProcessIDUINT32The numeric process ID, on platforms that have
this concept. On Unix, this is the process ID defined by
POSIX.WindowsSIDSTRINGThe Windows security identifier in its string form,
e.g. "S-1-5-21-3623811015-3361044348-30300820-1013" for
a domain or local computer user or "S-1-5-18" for the
LOCAL_SYSTEM userLinuxSecurityLabelARRAY of BYTEOn Linux systems, the security label that would result
from the SO_PEERSEC getsockopt call. The array contains
the non-zero bytes of the security label in an unspecified
ASCII-compatible encodingIt could be ASCII or UTF-8, but could also be
ISO Latin-1 or any other encoding., followed by a single zero byte.
For example, the SELinux context
system_u:system_r:init_t:s0
(a string of length 27) would be encoded as 28 bytes
ending with ':', 's', '0', '\x00'.Note that this is not the same as the older
GetConnectionSELinuxContext method, which does
not append the zero byte. Always appending the
zero byte allows callers to read the string
from the message payload without copying.
On SELinux systems this is the SELinux context, as output
by ps -Z or ls -Z.
Typical values might include
system_u:system_r:init_t:s0,
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023,
or
unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023.
On Smack systems, this is the Smack label.
Typical values might include
_, *,
User, System
or System::Shared.
On AppArmor systems, this is the AppArmor context,
a composite string encoding the AppArmor label (one or more
profiles) and the enforcement mode.
Typical values might include unconfined,
/usr/bin/firefox (enforce) or
user1 (complain).
This method was added in D-Bus 1.7 to reduce the round-trips
required to list a process's credentials. In older versions, calling
this method will fail: applications should recover by using the
separate methods such as
instead.
<literal>org.freedesktop.DBus.GetAdtAuditSessionData</literal>
As a method:
ARRAY of BYTE GetAdtAuditSessionData (in STRING bus_name)
Message arguments:
ArgumentTypeDescription0STRINGUnique or well-known bus name of the connection to
query, such as :12.34 or
com.example.tea
Reply arguments:
ArgumentTypeDescription0ARRAY of BYTEauditing data as returned by
adt_export_session_data()
Returns auditing data used by Solaris ADT, in an unspecified
binary format. If you know what this means, please contribute
documentation via the D-Bus bug tracking system.
This method is on the core DBus interface for historical reasons;
the same information should be made available via
in future.
<literal>org.freedesktop.DBus.GetConnectionSELinuxSecurityContext</literal>
As a method:
ARRAY of BYTE GetConnectionSELinuxSecurityContext (in STRING bus_name)
Message arguments:
ArgumentTypeDescription0STRINGUnique or well-known bus name of the connection to
query, such as :12.34 or
com.example.tea
Reply arguments:
ArgumentTypeDescription0ARRAY of BYTEsome sort of string of bytes, not necessarily UTF-8,
not including '\0'
Returns the security context used by SELinux, in an unspecified
format. If you know what this means, please contribute
documentation via the D-Bus bug tracking system.
This method is on the core DBus interface for historical reasons;
the same information should be made available via
in future.
<literal>org.freedesktop.DBus.AddMatch</literal>
As a method:
AddMatch (in STRING rule)
Message arguments:
ArgumentTypeDescription0STRINGMatch rule to add to the connection
Adds a match rule to match messages going through the message bus (see ).
If the bus does not have enough resources the org.freedesktop.DBus.Error.OOM
error is returned.
<literal>org.freedesktop.DBus.RemoveMatch</literal>
As a method:
RemoveMatch (in STRING rule)
Message arguments:
ArgumentTypeDescription0STRINGMatch rule to remove from the connection
Removes the first rule that matches (see ).
If the rule is not found the org.freedesktop.DBus.Error.MatchRuleNotFound
error is returned.
<literal>org.freedesktop.DBus.GetId</literal>
As a method:
GetId (out STRING id)
Reply arguments:
ArgumentTypeDescription0STRINGUnique ID identifying the bus daemon
Gets the unique ID of the bus. The unique ID here is shared among all addresses the
bus daemon is listening on (TCP, UNIX domain socket, etc.) and its format is described in
. Each address the bus is listening on also has its own unique
ID, as described in . The per-bus and per-address IDs are not related.
There is also a per-machine ID, described in and returned
by org.freedesktop.DBus.Peer.GetMachineId().
For a desktop session bus, the bus ID can be used as a way to uniquely identify a user's session.
<literal>org.freedesktop.DBus.Monitoring.BecomeMonitor</literal>
As a method:
BecomeMonitor (in ARRAY of STRING rule, in UINT32 flags)
Message arguments:
ArgumentTypeDescription0ARRAY of STRINGMatch rules to add to the connection1UINT32Not used, must be 0
Converts the connection into a monitor
connection which can be used as a debugging/monitoring
tool. Only a user who is privileged on this
bus (by some implementation-specific definition) may create
monitor connections
In the reference implementation,
the default configuration is that each user (identified by
numeric user ID) may monitor their own session bus,
and the root user (user ID zero) may monitor the
system bus.
.
Monitor connections lose all their bus names, including the unique
connection name, and all their match rules. Sending messages on a
monitor connection is not allowed: applications should use a private
connection for monitoring.
Monitor connections may receive all messages, even messages that
should only have gone to some other connection ("eavesdropping").
The first argument is a list of match rules, which replace any
match rules that were previously active for this connection.
These match rules are always treated as if they contained the
special eavesdrop='true' member.
As a special case, an empty list of match rules (which would
otherwise match nothing, making the monitor useless) is treated
as a shorthand for matching all messages.
The second argument might be used for flags to influence the
behaviour of the monitor connection in future D-Bus versions.
Message bus implementations should attempt to minimize the
side-effects of monitoring — in particular, unlike ordinary
eavesdropping, monitoring the system bus does not require the
access control rules to be relaxed, which would change the set
of messages that can be delivered to their (non-monitor)
destinations. However, it is unavoidable that monitoring
will increase the message bus's resource consumption. In
edge cases where there was barely enough time or memory without
monitoring, this might result in message deliveries failing
when they would otherwise have succeeded.
Glossary
This glossary defines some of the terms used in this specification.
Bus Name
The message bus maintains an association between names and
connections. (Normally, there's one connection per application.) A
bus name is simply an identifier used to locate connections. For
example, the hypothetical com.yoyodyne.Screensaver
name might be used to send a message to a screensaver from Yoyodyne
Corporation. An application is said to own a
name if the message bus has associated the application's connection
with the name. Names may also have queued
owners (see ).
The bus assigns a unique name to each connection,
see . Other names
can be thought of as "well-known names" and are
used to find applications that offer specific functionality.
See for details of
the syntax and naming conventions for bus names.
Message
A message is the atomic unit of communication via the D-Bus
protocol. It consists of a header and a
body; the body is made up of
arguments.
Message Bus
The message bus is a special application that forwards
or routes messages between a group of applications
connected to the message bus. It also manages
names used for routing
messages.
Name
See . "Name" may
also be used to refer to some of the other names
in D-Bus, such as interface names.
Namespace
Used to prevent collisions when defining new interfaces, bus names
etc. The convention used is the same one Java uses for defining
classes: a reversed domain name.
See ,
,
,
.
Object
Each application contains objects, which have
interfaces and
methods. Objects are referred to by a name,
called a path.
One-to-One
An application talking directly to another application, without going
through a message bus. One-to-one connections may be "peer to peer" or
"client to server." The D-Bus protocol has no concept of client
vs. server after a connection has authenticated; the flow of messages
is symmetrical (full duplex).
Path
Object references (object names) in D-Bus are organized into a
filesystem-style hierarchy, so each object is named by a path. As in
LDAP, there's no difference between "files" and "directories"; a path
can refer to an object, while still having child objects below it.
Queued Name Owner
Each bus name has a primary owner; messages sent to the name go to the
primary owner. However, certain names also maintain a queue of
secondary owners "waiting in the wings." If the primary owner releases
the name, then the first secondary owner in the queue automatically
becomes the new owner of the name.
Service
A service is an executable that can be launched by the bus daemon.
Services normally guarantee some particular features, for example they
may guarantee that they will request a specific name such as
"com.example.Screensaver", have a singleton object
"/com/example/Application", and that object will implement the
interface "com.example.Screensaver.Control".
Service Description Files
".service files" tell the bus about service applications that can be
launched (see ). Most importantly they
provide a mapping from bus names to services that will request those
names when they start up.
Unique Connection Name
The special name automatically assigned to each connection by the
message bus. This name will never change owner, and will be unique
(never reused during the lifetime of the message bus).
It will begin with a ':' character.
dbus-1.10.6/doc/dbus-faq.xml 0000644 0001750 0001750 00000065770 12602773110 015545 0 ustar 00smcv smcv 0000000 0000000
D-Bus FAQVersion 0.317 November 2006HavocPenningtonRed Hat, Inc.hp@pobox.comDavidAWheeler
What is D-Bus?
This is probably best answered by reading the D-Bus tutorial or
the introduction to the specification. In
short, it is a system consisting of 1) a wire protocol for exposing a
typical object-oriented language/framework to other applications; and
2) a bus daemon that allows applications to find and monitor one another.
Phrased differently, D-Bus is 1) an interprocess communication (IPC) system and 2) some higher-level
structure (lifecycle tracking, service activation, security policy) provided by two bus daemons,
one systemwide and one per-user-session.
Is D-Bus stable/finished?
The low-level library "libdbus" and the protocol specification are considered
ABI stable. The README
file has a discussion of the API/ABI stability guarantees.
Higher-level bindings (such as those for Qt, GLib, Python, Java, C#) each
have their own release schedules and degree of maturity, not linked to
the low-level library and bus daemon release. Check the project page for
the binding you're considering to understand that project's policies.
How is the reference implementation licensed? Can I use it in
proprietary applications?
The short answer is yes, you can use it in proprietary applications.
You should read the COPYING file, which
offers you the choice of two licenses. These are the GPL and the
AFL. The GPL requires that your application be licensed under the GPL
as well. The AFL is an "X-style" or "BSD-style" license compatible
with proprietary licensing, but it does have some requirements; in
particular it prohibits you from filing a lawsuit alleging that the
D-Bus software infringes your patents while you continue to
use D-Bus. If you're going to sue, you have to stop using
the software. Read the licenses to determine their meaning, this FAQ
entry is not intended to change the meaning or terms of the licenses.
What is the difference between a bus name, and object path,
and an interface?
If you imagine a C++ program that implements a network service, then
the bus name is the hostname of the computer running this C++ program,
the object path is a C++ object instance pointer, and an interface is
a C++ class (a pure virtual or abstract class, to be exact).
In Java terms, the object path is an object reference,
and an interface is a Java interface.
People get confused because if they write an application
with a single object instance and a single interface,
then the bus name, object path, and interface look
redundant. For example, you might have a text editor
that uses the bus name org.freedesktop.TextEditor,
has a global singleton object called
/org/freedesktop/TextEditor, and
that singleton object could implement the interface
org.freedesktop.TextEditor.
However, a text editor application could as easily own multiple bus
names (for example, org.kde.KWrite in addition to
generic TextEditor), have multiple objects (maybe
/org/kde/documents/4352 where the number changes
according to the document), and each object could implement multiple
interfaces, such as org.freedesktop.DBus.Introspectable,
org.freedesktop.BasicTextField,
org.kde.RichTextDocument.
What is a "service"?
A service is a program that can be launched by the bus daemon
to provide some functionality to other programs. Services
are normally launched according to the bus name they will
have.
People often misuse the word "service" for any
bus name, but this tends to be ambiguous and confusing so is discouraged.
In the D-Bus docs we try to use "service" only when talking about
programs the bus knows how to launch, i.e. a service always has a
.service file.
Is D-Bus a "component system"?
It helps to keep these concepts separate in your mind:
Object/component system
GUI control/widget embedding interfaces
Interprocess communication system or wire protocol
D-Bus is not a component system. "Component system" was originally
defined by COM, and was essentially a workaround for the limitations
of the C++ object system (adding introspection, runtime location of
objects, ABI guarantees, and so forth). With the C# language and CLR,
Microsoft added these features to the primary object system, leaving
COM obsolete. Similarly, Java has much less need for something like
COM than C++ did. Even QObject (from Qt) and GObject (from GLib) offer
some of the same features found in COM.
Component systems are not about GUI control embedding. Embedding
a spreadsheet in a word processor document is a matter of defining
some specific interfaces that objects
can implement. These interfaces provide methods related to
GUI controls. So an object implementing those interfaces
can be embedded.
The word "component" just means "object with some fancy features" and
in modern languages all objects are effectively "components."
So components are fancy objects, and some objects are GUI controls.
A third, unrelated feature is interprocess communication or IPC.
D-Bus is an IPC system. Given an object (or "component" if you must),
you can expose the functionality of that object over an IPC system.
Examples of IPC systems are DCOM, CORBA, SOAP, XML-RPC, and D-Bus.
You can use any of these IPC systems with any object/component system,
though some of them are "tuned" for specific object systems.
You can think of an IPC system primarily as a wire protocol.
If you combine an IPC system with a set of GUI control interfaces,
then you can have an out-of-process or dynamically-loaded GUI control.
Another related concept is the plugin or
extension. Generic plugin systems such as the
Eclipse system are not so different
from component/object systems, though perhaps a "plugin" tends to be a
bundle of objects with a user-visible name and can be
downloaded/packaged as a unit.
How fast is the D-Bus reference implementation?
Of course it depends a bit on what you're doing.
This mail contains some benchmarking. At the time of that
benchmark, D-Bus one-to-one communication was about 2.5x slower than
simply pushing the data raw over a socket. After the recent rewrite of
the marshaling code, D-Bus is slower than that because a lot of
optimization work was lost. But it can probably be sped up again.
D-Bus communication with the intermediate bus daemon should be
(and as last profiled, was) about twice as slow as one-to-one
mode, because a round trip involves four socket reads/writes rather
than two socket reads/writes.
The overhead comes from a couple of places; part of it is simply
"abstraction penalty" (there are layers of code to support
multiple main loops, multiple transport types, security, etc.).
Probably the largest part comes from data validation
(because the reference implementation does not trust incoming data).
It would be simple to add a "no validation" mode, but probably
not a good idea all things considered.
Raw bandwidth isn't the only concern; D-Bus is designed to
enable asynchronous communication and avoid round trips.
This is frequently a more important performance issue
than throughput.
How large is the D-Bus reference implementation?
A production build (with assertions, unit tests, and verbose logging
disabled) is on the order of a 150K shared library.
A much, much smaller implementation would be possible by omitting out
of memory handling, hardcoding a main loop (or always using blocking
I/O), skipping validation, and otherwise simplifying things.
How does D-Bus differ from other interprocess communication
or networking protocols?
Keep in mind, it is not only an IPC system; it also includes
lifecycle tracking, service activation, security policy, and other
higher-level structure and assumptions.
The best place to start is to read the D-Bus tutorial, so
you have a concrete idea what D-Bus actually is. If you
understand other protocols on a wire format level, you
may also want to read the D-Bus specification to see what
D-Bus looks like on a low level.
As the tutorial and specification both explain, D-Bus is tuned
for some specific use cases. Thus, it probably isn't tuned
for what you want to do, unless you are doing the things
D-Bus was designed for. Don't make the mistake of thinking
that any system involving "IPC" is the same thing.
The D-Bus authors would not recommend using D-Bus
for applications where it doesn't make sense.
The following questions compare D-Bus to some other
protocols primarily to help you understand D-Bus
and decide whether it's appropriate; D-Bus is neither intended
nor claimed to be the right choice for every application.
It should be possible to bridge D-Bus to other IPC systems,
just as D-Bus can be bridged to object systems.
Note: the D-Bus mailing list subscribers are very much not
interested in debating which IPC system is the One True
System. So if you want to discuss that, please use another forum.
How does D-Bus differ from CORBA?
Start by reading .
CORBA is designed to support
object-oriented IPC between objects, automatically marshalling
parameters as necessary. CORBA is strongly supported by the Open Management Group (OMG), which
produces various standards and supporting documents for CORBA and has
the backing of many large organizations. There are many CORBA ORBs
available, both proprietary ORBs and free / open source software ORBs
(the latter include ORBit, MICO, and The ACE Orb (TAO)). Many
organizations continue to use CORBA ORBs for various kinds of IPC.
Both GNOME and KDE have used CORBA and then moved away from it. KDE
had more success with a system called DCOP, and GNOME layered a system
called Bonobo on top of CORBA. Without custom extensions, CORBA does
not support many of the things one wants to do in a desktop
environment with the GNOME/KDE architecture.
CORBA on the other hand has a number of features of interest for
enterprise and web application development, though XML systems such as
SOAP are the latest fad.
Like D-Bus, CORBA uses a fast binary protocol (IIOP). Both systems
work in terms of objects and methods, and have concepts such as
"oneway" calls. Only D-Bus has direct support for "signals" as in
GLib/Qt (or Java listeners, or C# delegates).
D-Bus hardcodes and specifies a lot of things that CORBA leaves open-ended,
because CORBA is more generic and D-Bus has two specific use-cases in mind.
This makes D-Bus a bit simpler.
However, unlike CORBA D-Bus does not specify the
API for the language bindings. Instead, "native" bindings adapted
specifically to the conventions of a framework such as QObject,
GObject, C#, Java, Python, etc. are encouraged. The libdbus reference
implementation is designed to be a backend for bindings of this
nature, rather than to be used directly. The rationale is that an IPC
system API should not "leak" all over a program; it should come into
play only just before data goes over the wire. As an aside, OMG is
apparently working on a simpler C++ binding for CORBA.
Many CORBA implementations such as ORBit are faster than the libdbus
reference implementation. One reason is that D-Bus considers data
from the other end of the connection to be untrusted and extensively
validates it. But generally speaking other priorities were placed
ahead of raw speed in the libdbus implementation. A fast D-Bus
implementation along the lines of ORBit should be possible, of course.
On a more trivial note, D-Bus involves substantially fewer acronyms
than CORBA.
How does D-Bus differ from XML-RPC and SOAP?
Start by reading .
In SOAP and XML-RPC, RPC calls are transformed
into an XML-based format, then sent over the wire (typically using the
HTTP protocol), where they are processed and returned. XML-RPC is the
simple protocol (its spec is only a page or two), and SOAP is the
full-featured protocol.
XML-RPC and SOAP impose XML parsing overhead that is normally
irrelevant in the context of the Internet, but significant for
constant fine-grained IPC among applications in a desktop session.
D-Bus offers persistent connections and with the bus daemon
supports lifecycle tracking of other applications connected
to the bus. With XML-RPC and SOAP, typically each method call
exists in isolation and has its own HTTP connection.
How does D-Bus differ from DCE?
Start by reading .
Distributed Computing
Environment (DCE) is an industry-standard vendor-neutral
standard that includes an IPC mechanism. The Open Group
has released an implementation as open source software. DCE
is quite capable, and includes a vast amount of functionality such as
a distributed time service. As the name implies, DCE is intended for
use in a large, multi-computer distributed application. D-Bus would
not be well-suited for this.
How does D-Bus differ from DCOM and COM?
Start by reading .
Comparing D-Bus to COM is apples and oranges;
see .
DCOM (distributed COM) is a Windows IPC system designed for use with
the COM object system. It's similar in some ways to DCE and CORBA.
How does D-Bus differ from ZeroC's Internet Communications Engine (Ice)
Start by reading .
The Internet
Communications Engine (Ice) is a powerful IPC mechanism more
on the level of SOAP or CORBA than D-Bus. Ice has a "dual-license"
business around it; i.e. you can use it under the GPL, or pay for a
proprietary license.
How does D-Bus differ from Inter-Client Exchange (ICE)?
ICE
was developed for the X Session Management protocol (XSMP), as part of
the X Window System (X11R6.1). The idea was to allow desktop sessions
to contain nongraphical clients in addition to X clients.
ICE is a binary protocol designed for desktop use, and KDE's DCOP
builds on ICE. ICE is substantially simpler than D-Bus (in contrast
to most of the other IPC systems mentioned here, which are more
complex). ICE doesn't really define a mapping to objects and methods
(DCOP adds that layer). The reference implementation of ICE (libICE)
is often considered to be horrible (and horribly insecure).
DCOP and XSMP are the only two widely-used applications of ICE,
and both could in principle be replaced by D-Bus. (Though whether
GNOME and KDE will bother is an open question.)
How does D-Bus differ from DCOP?
Start by reading .
D-Bus is intentionally pretty similar to DCOP,
and can be thought of as a "DCOP the next generation" suitable for
sharing between the various open source desktop projects.
D-Bus is a bit more complex than DCOP, though the Qt binding for D-Bus
should not be more complex for programmers. The additional complexity
of D-Bus arises from its separation of object references vs. bus names
vs. interfaces as distinct concepts, and its support for one-to-one
connections in addition to connections over the bus. The libdbus
reference implementation has a lot of API to support multiple bindings
and main loops, and performs data validation and out-of-memory handling
in order to support secure applications such as the systemwide bus.
D-Bus is probably somewhat slower than DCOP due to data validation
and more "layers" in the reference implementation. A comparison
hasn't been posted to the list though.
At this time, KDE has not committed to using D-Bus, but there have
been discussions of KDE bridging D-Bus and DCOP, or even changing
DCOP's implementation to use D-Bus internally (so that GNOME and KDE
would end up using exactly the same bus). See the KDE mailing list
archives for some of these discussions.
How does D-Bus differ from [yet more IPC mechanisms]?
Start by reading .
There are countless uses of network sockets in the world. MBUS, Sun ONC/RPC, Jabber/XMPP,
SIP, are some we can think of quickly.
Which IPC mechanism should I use?
Start by reading .
If you're writing an Internet or Intranet application, XML-RPC or SOAP
work for many people. These are standard, available for most
languages, simple to debug and easy to use.
If you're writing a desktop application for UNIX,
then D-Bus is of course our recommendation for
talking to other parts of the desktop session.
D-Bus is also designed for communications between system daemons and
communications between the desktop and system daemons.
If you're doing something complicated such as clustering,
distributed swarms, peer-to-peer, or whatever then
the authors of this FAQ don't have expertise in these
areas and you should ask someone else or try a search engine.
D-Bus is most likely a poor choice but could be appropriate
for some things.
Note: the D-Bus mailing list is probably not the place to
discuss which system is appropriate for your application,
though you are welcome to ask specific questions about
D-Bus after reading this FAQ, the tutorial, and
searching the list archives. The best way
to search the list archives is probably to use
an Internet engine such as Google. On Google,
include "site:freedesktop.org" in your search.
How can I submit a bug or patch?
The D-Bus web site
has a link to the bug tracker, which is the best place to store
patches. You can also post them to the list, especially if you want
to discuss the patch or get feedback.
dbus-1.10.6/doc/doxygen_to_devhelp.xsl 0000644 0001750 0001750 00000003010 12602773110 017712 0 ustar 00smcv smcv 0000000 0000000 .html#
dbus-1.10.6/doc/file-boilerplate.c 0000644 0001750 0001750 00000001747 12602773110 016676 0 ustar 00smcv smcv 0000000 0000000 /* -*- mode: C; c-file-style: "gnu"; indent-tabs-mode: nil; -*- */
/* FILENAME BRIEF FILE DESCRIPTION
*
* Copyright (C) YEAR COPYRIGHT HOLDER
*
* Licensed under the Academic Free License version 2.1
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
#ifndef DBUS_FOO_H
#define DBUS_FOO_H
#endif /* DBUS_FOO_H */
dbus-1.10.6/doc/TODO 0000644 0001750 0001750 00000013414 12602773110 013775 0 ustar 00smcv smcv 0000000 0000000 Important for 1.2
===
- System bus activation
- Windows port
Important for 1.0 GLib Bindings
===
- Test point-to-point mode
- Add support for getting sender
- format_version in the object info doesn't look like it's handled correctly. The creator
of the object info should specify some fixed number per struct version; the library
should handle only specific numbers it knows about. There's no assumption that all
numbers >= the given one are compatible. The idea is that new versions of the lib
can offer totally different object info structs, but old versions
keep working.
Important for 1.0 Python bindings
===
- Hammer down API
- Fix removing of signals from the match tree
- Fix refcounting and userdata lifecycles
- Write a generic mainloop
Might as Well for 1.0
===
- protocol version in each message is pretty silly
Can Be Post 1.0
===
- revamp dbus-launch a bit,
see http://lists.freedesktop.org/archives/dbus/2006-October/005906.html
for some thoughts.
- clean up the creds issue on *BSD's in dbus/dbus-sysdeps-unix.c.
They should work as is but we need to rearange it to make it
clearer which method is being used. configure.in should
be fixed up to make that decition.
- _dbus_connection_unref_unlocked() is essentially always broken because
the connection finalizer calls non-unlocked functions. One fix is to make
the finalizer run with the lock held, but since it calls out to the app that may
be pretty broken. More likely all the uses of unref_unlocked are just wrong.
- if the GUID is obtained only during authentication, not in the address,
we could still share the connection
- Allow a dbus_g_proxy_to_string()/g_object_to_string() that
would convert the proxy to an "IOR" and dbus_g_proxy_from_string()
that would decode; using these, dbus-glib users could avoid
DBusConnection entirely. Of course the same applies to other kinds
of binding. This would use dbus_connection_open()'s connection-sharing
feature to avoid massive proliferation of connections.
- DBusWatchList/TimeoutList duplicate a lot of code, as do
protected_change_watch/protected_change_timeout in dbus-connection.c
and dbus-server.c. This could all be mopped up, cut-and-paste
fixed, code size reduced.
- change .service files to allow Names=list in addition to Name=string
- The message bus internal code still says "service" for
"name", "base service" for "unique name", "activate" for
"start"; would be nice to clean up.
- Property list feature on message bus (list of properties associated
with a connection). May also include message matching rules
that involve the properties of the source or destination
connection.
- Disconnecting the remote end on invalid UTF-8 is probably not a good
idea. The definition of "valid" is slightly fuzzy. I think it might
be better to just silently "fix" the UTF-8, or perhaps return an error.
- build and install the Doxygen manual in Makefile when --enable-docs
- if you send the same message to multiple connections, the serial number
will only be right for one of them. Probably need to just write() the serial
number, rather than putting it in the DBusMessage, or something.
- perhaps the bus driver should have properties that reflect attributes
of the session, such as hostname, architecture, operating system,
etc. Could be useful for code that wants to special-case behavior
for a particular host or class of hosts, for example.
- currently the security policy stuff for messages to/from
the bus driver is kind of strange; basically it's hardcoded that
you can always talk to the driver, but the default config file
has rules for it anyway, or something. it's conceptually
screwy at the moment.
- when making a method call, if the call serial were globally unique,
we could forward the call serial along with any method calls made
as a result of the first method call, and allow reentrancy that was
strictly part of the call stack of said method call. But I don't
really see how to do this without making the user pass around the
call serial to all method calls all the time, or disallowing
async calls.
If done post 1.0 will probably be an optional/ugly-API type
of thing.
- I don't want to introduce DBusObject, but refcounting and object
data could still be factored out into an internal "base class"
perhaps.
- Keep convenience wrappers in sync with bus methods
- document the auth protocol as a set of states and transitions, and
then reimplement it in those terms
- recursive dispatch, see dbus_connection_dispatch()
- do we need per-display activation; if so I'd like to do this by setting a
"display ID" property on screen 0, with a GUID, and keying activation by
said GUID. Otherwise you get all kinds of unrobust
string/hostname-based mess. per-screen is then done by appending screen number
to the display. If displays have a deterministic ID like this, you can
do per-display by simply including GUID in the service name.
- optimization and profiling!
- Match rules aren't in the spec (probably a lot of methods on the bus
are not)
- the "break loader" and valid/invalid message tests are all disabled;
they need to be fixed and re-enabled with the new message args stuff.
I think I want to drop the .message files thing and just have code
that generates messages, more like the tests for
dbus-marshal-recursive.c (this is mostly done now, just needs some
cleanup)
- just before 1.0, try a HAVE_INT64=0 build and be sure it runs
- Windows port needs recursive mutexes
Should Be Post 1.0
===
- look into supporting the concept of a "connection" generically
(what does this TODO item mean?)
- test/name-test should be named test/with-bus or something like that
dbus-1.10.6/doc/dbus-uuidgen.1.xml.in 0000644 0001750 0001750 00000011056 12602773110 017166 0 ustar 00smcv smcv 0000000 0000000
dbus-uuidgen1User CommandsD-Bus@DBUS_VERSION@dbus-uuidgenUtility to generate UUIDsdbus-uuidgen--version --ensure =FILENAME--get =FILENAMEDESCRIPTIONThe dbus-uuidgen command generates or reads a universally unique ID.Note that the D-Bus UUID has no relationship to RFC 4122 and does not generate
UUIDs compatible with that spec. Many systems have a separate command
for that (often called "uuidgen").See http://www.freedesktop.org/software/dbus/ for more information
about D-Bus.The primary usage of dbus-uuidgen is to run in the post-install
script of a D-Bus package like this:
dbus-uuidgen --ensure
This will ensure that /var/lib/dbus/machine-id exists and has the uuid in it.
It won't overwrite an existing uuid, since this id should remain fixed
for a single machine until the next reboot at least.The important properties of the machine UUID are that 1) it remains
unchanged until the next reboot and 2) it is different for any two
running instances of the OS kernel. That is, if two processes see the
same UUID, they should also see the same shared memory, UNIX domain
sockets, local X displays, localhost.localdomain resolution, process
IDs, and so forth.If you run dbus-uuidgen with no options it just prints a new uuid made
up out of thin air.If you run it with --get, it prints the machine UUID by default, or
the UUID in the specified file if you specify a file.If you try to change an existing machine-id on a running system, it will
probably result in bad things happening. Don't try to change this file. Also,
don't make it the same on two different systems; it needs to be different
anytime there are two different kernels running.The UUID should be different on two different virtual machines,
because there are two different kernels.OPTIONSThe following options are supported:If a filename is not given, defaults to localstatedir/lib/dbus/machine-id
(localstatedir is usually /var). If this file exists and is valid, the
uuid in the file is printed on stdout. Otherwise, the command exits
with a nonzero status.If a filename is not given, defaults to localstatedir/lib/dbus/machine-id
(localstatedir is usually /var). If this file exists then it will be
validated, and a failure code returned if it contains the wrong thing.
If the file does not exist, it will be created with a new uuid in it.
On success, prints no output.Print the version of dbus-uuidgenAUTHORSee http://www.freedesktop.org/software/dbus/doc/AUTHORSBUGSPlease send bug reports to the D-Bus mailing list or bug tracker,
see http://www.freedesktop.org/software/dbus/
dbus-1.10.6/doc/dbus-update-activation-environment.1.xml.in 0000644 0001750 0001750 00000020470 12602773110 023511 0 ustar 00smcv smcv 0000000 0000000
2015Collabora Ltd.This man page is distributed under the same terms as
dbus-update-activation-environment (MIT/X11). There is NO WARRANTY,
to the extent permitted by law.dbus-update-activation-environment1User CommandsD-Bus@DBUS_VERSION@dbus-update-activation-environmentupdate environment used for D-Bus session servicesdbus-update-activation-environment--systemd--verbose--allVARVAR=VALDESCRIPTIONdbus-update-activation-environment
updates the list of environment variables used by
dbus-daemon --session
when it activates session services without using
systemd.With the option,
if an instance of systemd --user is
available on D-Bus, it also updates the list of environment variables
used by systemd --user
when it activates user services, including D-Bus session services
for which dbus-daemon has been configured to
delegate activation to systemd.
This is very similar to the
command provided by
systemctl1).Variables that are special to dbus-daemon
or systemd may be set, but their values will
be overridden when a service is started. For instance, it is
not useful to add DBUS_SESSION_BUS_ADDRESS to
dbus-daemon's activation environment,
although it might still be useful to add it to
systemd's activation environment.OPTIONSSet all environment variables present in
the environment used by
dbus-update-activation-environment.
Set environment variables for systemd user services as well as
for traditional D-Bus session services.Output messages to standard error explaining what
dbus-update-activation-environment is doing.VARIf VAR is present in the
environment of dbus-update-activation-environment,
set it to the same value for D-Bus services. Its value must be
UTF-8 (if not, it is skipped with a warning). If
VAR is not present
in the environment, this argument is silently ignored.
VAR=VALSet VAR to VAL,
which must be UTF-8.EXAMPLESdbus-update-activation-environment is
primarily designed to be used in Linux distributions' X11 session
startup scripts, in conjunction with the "user bus" design.
To propagate DISPLAY and XAUTHORITY
to dbus-daemon
and, if present, systemd,
and propagate DBUS_SESSION_BUS_ADDRESS to
systemd:
dbus-update-activation-environment --systemd \
DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY
To propagate all environment variables except
XDG_SEAT, XDG_SESSION_ID
and XDG_VTNR to dbus-daemon
(and, if present, systemd) for compatibility
with legacy X11 session startup scripts:
# in a subshell so the variables remain set in the
# parent script
(
unset XDG_SEAT
unset XDG_SESSION_ID
unset XDG_VTNR
dbus-update-activation-environment --systemd --all
)
EXIT STATUSdbus-update-activation-environment
exits with status 0 on success, EX_USAGE (64) on invalid
command-line options, EX_OSERR (71) if unable to connect
to the session bus, or EX_UNAVAILABLE (69) if unable to
set the environment variables. Other nonzero exit codes might be
added in future versions.ENVIRONMENTDBUS_SESSION_BUS_ADDRESS,
XDG_RUNTIME_DIR and/or DISPLAY
are used to find the address of the session bus.LIMITATIONSdbus-daemon does not provide a way to unset
environment variables after they have been set (although
systemd does), so
dbus-update-activation-environment does not
offer this functionality either.
POSIX does not specify the encoding of non-ASCII environment variable
names or values and allows them to contain any non-zero byte, but
neither dbus-daemon nor systemd
supports environment variables with non-UTF-8 names or values.
Accordingly, dbus-update-activation-environment
assumes that any name or value that appears to be valid UTF-8 is
intended to be UTF-8, and ignores other names or values with a warning.
BUGSPlease send bug reports to the D-Bus bug tracker or mailing list.
See http://www.freedesktop.org/software/dbus/.SEE ALSOdbus-daemon1,
systemd1,
the command of
systemctl1
dbus-1.10.6/doc/dbus-test-tool.1.xml.in 0000644 0001750 0001750 00000027204 12602773110 017462 0 ustar 00smcv smcv 0000000 0000000
2015Collabora Ltd.This man page is distributed under the same terms as
dbus-test-tool (GPL-2+). There is NO WARRANTY, to the extent
permitted by law.dbus-test-tool1User CommandsD-Bus@DBUS_VERSION@dbus-test-toolD-Bus traffic generator and test tooldbus-test-toolblack-hole--session--system--name=NAME--no-readdbus-test-toolecho--session--system--name=NAME--sleep=MSdbus-test-toolspam--session--system--dest=NAME--count=N--flood--ignore-errors--messages-per-conn=N--no-reply--queue=N--seed=SEED--string--bytes--empty--payload=S--stdin--message-stdin--random-sizeDESCRIPTIONdbus-test-tool is a multi-purpose tool
for debugging and profiling D-Bus.dbus-test-tool black-hole
connects to D-Bus, optionally requests a name, then does not
reply to messages. It normally reads and discards messages from
its D-Bus socket, but can be configured to sleep forever without
reading.dbus-test-tool echo
connects to D-Bus, optionally requests a name, then sends back an
empty reply to every method call, after an optional delay.dbus-test-tool spam
connects to D-Bus and makes repeated method calls,
normally named com.example.Spam.OPTIONSCommon optionsConnect to the session bus. This is the default.Connect to the system bus.black-hole modeNAMEBefore proceeding, request ownership of the well-known
bus name NAME, for example
com.example.NoReply. By default,
no name is requested, and the tool can only be addressed by
a unique bus name such as :1.23.Do not read from the D-Bus socket.echo modeNAMEBefore proceeding, request ownership of the well-known
bus name NAME, for example
com.example.Echo. By default,
no name is requested, and the tool can only be addressed by
a unique bus name such as :1.23.MSBlock for MS milliseconds
before replying to a method call.spam modeNAMESend method calls to the well-known or unique
bus name NAME.
The default is the dbus-daemon,
org.freedesktop.DBus.NSend N method calls in total.
The default is 1.NSend N method calls before
waiting for any replies, then send one new call per reply
received, keeping N method calls
"in flight" at all times until the number of messages specified
with the option have been sent.
The default is 1, unless
is used.Send all messages without waiting for a reply,
equivalent to with an arbitrarily
large N.Set the "no reply desired" flag on the messages.
This implies , since it disables
the replies that would be used for a finite
length.NIf given, send N method calls
on the same connection, then disconnect and reconnect.
The default is to use the same connection for all method
calls.The payload of each message is a UTF-8 string. This is the
default. The actual string used is given by the
or
option, defaulting to "hello, world!".The payload of each message is a byte-array.
The actual bytes used are given by the
or
option, defaulting to the ASCII encoding of
"hello, world!".The messages have no payload.SUse S as the
or
in the messages. The default is "hello, world!".Read from standard input until end-of-file is reached,
and use that as the or
in the messages.Read a complete binary D-Bus method call message from
standard input, and use that for each method call.Read whitespace-separated ASCII decimal numbers from
standard input, choose one at random for each message,
and send a message whose payload is a string of that
length.SEEDUse SEED as the seed
for the pseudorandom number generator, to have somewhat
repeatable sequences of random messages.BUGSPlease send bug reports to the D-Bus bug tracker or mailing list.
See http://www.freedesktop.org/software/dbus/.SEE ALSOdbus-send1
dbus-1.10.6/doc/dbus-send.1.xml.in 0000644 0001750 0001750 00000015516 12602773110 016464 0 ustar 00smcv smcv 0000000 0000000
dbus-send1User CommandsD-Bus@DBUS_VERSION@dbus-sendSend a message to a message busdbus-send--system --session --address=ADDRESS--dest=NAME--print-reply =literal--reply-timeout=MSEC--type=TYPEOBJECT_PATHINTERFACE.MEMBERCONTENTSDESCRIPTIONThe dbus-send command is used to send a message to a D-Bus message
bus. See http://www.freedesktop.org/software/dbus/ for more
information about the big picture.There are two well-known message buses: the systemwide message bus
(installed on many systems as the "messagebus" service) and the
per-user-login-session message bus (started each time a user logs in).
The and options direct
dbus-send to send messages to the system or session buses respectively.
If neither is specified, dbus-send sends to the session bus.Nearly all uses of dbus-send must provide the argument
which is the name of a connection on the bus to send the message to. If
is omitted, no destination is set.The object path and the name of the message to send must always be
specified. Following arguments, if any, are the message contents
(message arguments). These are given as type-specified values and
may include containers (arrays, dicts, and variants) as described below.
<contents> ::= <item> | <container> [ <item> | <container>...]
<item> ::= <type>:<value>
<container> ::= <array> | <dict> | <variant>
<array> ::= array:<type>:<value>[,<value>...]
<dict> ::= dict:<type>:<type>:<key>,<value>[,<key>,<value>...]
<variant> ::= variant:<type>:<value>
<type> ::= string | int16 | uint 16 | int32 | uint32 | int64 | uint64 | double | byte | boolean | objpath
D-Bus supports more types than these, but dbus-send currently
does not. Also, dbus-send does not permit empty containers
or nested containers (e.g. arrays of variants).Here is an example invocation:
dbus-send --dest=org.freedesktop.ExampleName \
/org/freedesktop/sample/object/name \
org.freedesktop.ExampleInterface.ExampleMethod \
int32:47 string:'hello world' double:65.32 \
array:string:"1st item","next item","last item" \
dict:string:int32:"one",1,"two",2,"three",3 \
variant:int32:-8 \
objpath:/org/freedesktop/sample/object/name
Note that the interface is separated from a method or signal
name by a dot, though in the actual protocol the interface
and the interface member are separate fields.OPTIONSThe following options are supported:NAMESpecify the name of the connection to receive the message.Block for a reply to the message sent, and print any reply received
in a human-readable form. It also means the message type () is method_call.Block for a reply to the message sent, and print the body of the
reply. If the reply is an object path or a string, it is printed
literally, with no punctuation, escape characters etc.MSECWait for a reply for up to MSEC milliseconds.
The default is implementation‐defined, typically 25 seconds.Send to the system message bus.Send to the session message bus. (This is the default.)ADDRESSSend to ADDRESS.TYPESpecify method_call or signal (defaults to "signal").AUTHORdbus-send was written by Philip Blundell.BUGSPlease send bug reports to the D-Bus mailing list or bug tracker,
see http://www.freedesktop.org/software/dbus/
dbus-1.10.6/doc/dbus-run-session.1.xml.in 0000644 0001750 0001750 00000013622 12602773110 020014 0 ustar 00smcv smcv 0000000 0000000
dbus-run-session1User CommandsD-Bus@DBUS_VERSION@dbus-run-sessionstart a process as a new D-Bus sessiondbus-run-session--config-file FILENAME--dbus-daemon BINARY-- PROGRAMARGUMENTSdbus-run-session--help dbus-run-session--version DESCRIPTIONdbus-run-session
is used to start a session bus instance of
dbus-daemon
from a shell script, and start a specified program in that session. The
dbus-daemon
will run for as long as the program does, after which it will terminate.One use is to run a shell with its own
dbus-daemon
in a text‐mode or SSH session, and have the
dbus-daemon
terminate automatically on leaving the sub‐shell, like this: dbus-run-session -- bashor to replace the login shell altogether, by combining dbus-run-session
with the exec builtin: exec dbus-run-session -- bashAnother use is to run regression tests and similar things in an isolated
D-Bus session, to avoid either interfering with the "real" D-Bus session
or relying on there already being a D-Bus session active, for instance: dbus-run-session -- make checkor (in
automake1):
AM_TESTS_ENVIRONMENT = export MY_DEBUG=all;
LOG_COMPILER = dbus-run-session
AM_LOG_FLAGS = --
OPTIONSFILENAME, FILENAMEPass
FILENAME
to the bus daemon, instead of passing it the
argument. See
dbus-daemon1.BINARY, BINARYRun BINARY as dbus-daemon1, instead of searching the PATH
in the usual way for an executable called dbus-daemon.Print usage information and exit.Print the version of dbus-run-session and exit.EXIT STATUSdbus-run-session
exits with the exit status of
PROGRAM,
0 if the
or
options were used, 127 on an error within
dbus-run-session
itself, or
128+n
if the
PROGRAM
was killed by signal
n.ENVIRONMENTPATH
is searched to find
PROGRAM,
and (if the --dbus-daemon option is not used or its argument does not
contain a
/ character) to find dbus-daemon.The session bus' address is made available to
PROGRAM
in the environment variable
DBUS_SESSION_BUS_ADDRESS.The variables
DBUS_SESSION_BUS_PID,
DBUS_SESSION_BUS_WINDOWID,
DBUS_STARTER_BUS_TYPE and
DBUS_STARTER_ADDRESS
are removed from the environment, if present.BUGSPlease send bug reports to the D-Bus mailing list or bug tracker,
see http://www.freedesktop.org/software/dbus/SEE ALSOdbus-daemon1,
dbus-launch1
dbus-1.10.6/doc/dbus-monitor.1.xml.in 0000644 0001750 0001750 00000011775 12602773110 017225 0 ustar 00smcv smcv 0000000 0000000
dbus-monitor1User CommandsD-Bus@DBUS_VERSION@dbus-monitordebug probe to print message bus messagesdbus-monitor--system --session --address ADDRESS--profile --monitor --pcap --binary watchexpressionsDESCRIPTIONThe dbus-monitor command is used to monitor messages going
through a D-Bus message bus. See
http://www.freedesktop.org/software/dbus/ for more information about
the big picture.There are two well-known message buses: the systemwide message bus
(installed on many systems as the "messagebus" service) and the
per-user-login-session message bus (started each time a user logs in).
The --system and --session options direct dbus-monitor to
monitor the system or session buses respectively. If neither is
specified, dbus-monitor monitors the session bus.dbus-monitor has two different text output
modes: the 'classic'-style
monitoring mode, and profiling mode. The profiling format is a compact
format with a single line per message and microsecond-resolution timing
information. The --profile and --monitor options select the profiling
and monitoring output format respectively.dbus-monitor also has two binary output modes.
The binary mode, selected by --binary, outputs the
entire binary message stream (without the initial authentication handshake).
The PCAP mode, selected by --pcap, adds a
PCAP file header to the beginning of the output, and prepends a PCAP
message header to each message; this produces a binary file that can
be read by, for instance, Wireshark.If no mode is specified,
dbus-monitor uses the monitoring output format.In order to get dbus-monitor to see the messages you are interested
in, you should specify a set of watch expressions as you would expect to
be passed to the dbus_bus_add_match function.The message bus configuration may keep dbus-monitor from seeing
all messages, especially if you run the monitor as a non-root user.OPTIONSMonitor the system message bus.Monitor the session message bus. (This is the default.)Monitor an arbitrary message bus given at ADDRESS.Use the profiling output format.Use the monitoring output format. (This is the default.)EXAMPLEHere is an example of using dbus-monitor to watch for the gnome typing
monitor to say things
dbus-monitor "type='signal',sender='org.gnome.TypingMonitor',interface='org.gnome.TypingMonitor'"
AUTHORdbus-monitor was written by Philip Blundell.
The profiling output mode was added by Olli Salli.BUGSPlease send bug reports to the D-Bus mailing list or bug tracker,
see http://www.freedesktop.org/software/dbus/
dbus-1.10.6/doc/dbus-launch.1.xml.in 0000644 0001750 0001750 00000026071 12602773110 017003 0 ustar 00smcv smcv 0000000 0000000
dbus-launch1User CommandsD-Bus@DBUS_VERSION@dbus-launchUtility to start a message bus from a shell scriptdbus-launch--version --help --sh-syntax --csh-syntax --auto-syntax --binary-syntax --close-stderr --exit-with-session --autolaunch=MACHINEID--config-file=FILENAMEPROGRAMARGSDESCRIPTIONThe dbus-launch command is used to start a session bus
instance of dbus-daemon from a shell script.
It would normally be called from a user's login
scripts. Unlike the daemon itself, dbus-launch exits, so
backticks or the $() construct can be used to read information from
dbus-launch.With no arguments, dbus-launch will launch a session bus
instance and print the address and PID of that instance to standard
output.You may specify a program to be run; in this case, dbus-launch
will launch a session bus instance, set the appropriate environment
variables so the specified program can find the bus, and then execute the
specified program, with the specified arguments. See below for
examples.If you launch a program, dbus-launch will not print the
information about the new bus to standard output.When dbus-launch prints bus information to standard output, by
default it is in a simple key-value pairs format. However, you may
request several alternate syntaxes using the --sh-syntax, --csh-syntax,
--binary-syntax, or
--auto-syntax options. Several of these cause dbus-launch to emit shell code
to set up the environment.With the --auto-syntax option, dbus-launch looks at the value
of the SHELL environment variable to determine which shell syntax
should be used. If SHELL ends in "csh", then csh-compatible code is
emitted; otherwise Bourne shell code is emitted. Instead of passing
--auto-syntax, you may explicitly specify a particular one by using
--sh-syntax for Bourne syntax, or --csh-syntax for csh syntax.
In scripts, it's more robust to avoid --auto-syntax and you hopefully
know which shell your script is written in.See http://www.freedesktop.org/software/dbus/ for more information
about D-Bus. See also the man page for dbus-daemon.EXAMPLESDistributions running
dbus-launch
as part of a standard X session should run
dbus-launch --exit-with-session
after the X server has started and become available, as a wrapper around
the "main" X client (typically a session manager or window manager), as in
these examples: