<article id="index">
<articleinfo>
<title>D-Bus Specification</title>
- <releaseinfo>Version 0.17</releaseinfo>
- <date>(not final)</date>
+ <releaseinfo>Version 0.20</releaseinfo>
+ <date>unreleased</date>
<authorgroup>
<author>
<firstname>Havoc</firstname>
</address>
</affiliation>
</author>
+ <author>
+ <firstname>Simon</firstname>
+ <surname>McVittie</surname>
+ <affiliation>
+ <orgname>Collabora Ltd.</orgname>
+ <address>
+ <email>simon.mcvittie@collabora.co.uk</email>
+ </address>
+ </affiliation>
+ </author>
+ <author>
+ <firstname>David</firstname>
+ <surname>Zeuthen</surname>
+ <affiliation>
+ <orgname>Red Hat, Inc.</orgname>
+ <address>
+ <email>davidz@redhat.com</email>
+ </address>
+ </affiliation>
+ </author>
</authorgroup>
<revhistory>
<revision>
<revnumber>current</revnumber>
<date><ulink url='http://cgit.freedesktop.org/dbus/dbus/log/doc/dbus-specification.xml'>commit log</ulink></date>
- <authorinitials></authorinitials>
- <revremark></revremark>
+ <authorinitials>smcv, walters</authorinitials>
+ <revremark>reorganise for clarity, remove false claims about
+ basic types, mention /o/fd/DBus</revremark>
+ </revision>
+ <revision>
+ <revnumber>0.19</revnumber>
+ <date>20 February 2012</date>
+ <authorinitials>smcv/lp</authorinitials>
+ <revremark>formally 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 transport</revremark>
+ </revision>
+ <revision>
+ <revnumber>0.18</revnumber>
+ <date>29 July 2011</date>
+ <authorinitials>smcv</authorinitials>
+ <revremark>define eavesdropping, unicast, broadcast; add eavesdrop
+ match keyword; promote type system to a top-level section</revremark>
+ </revision>
+ <revision>
+ <revnumber>0.17</revnumber>
+ <date>1 June 2011</date>
+ <authorinitials>smcv/davidz</authorinitials>
+ <revremark>define ObjectManager; reserve extra pseudo-type-codes used
+ by GVariant</revremark>
</revision>
<revision>
<revnumber>0.16</revnumber>
</sect1>
- <sect1 id="message-protocol">
- <title>Message Protocol</title>
+ <sect1 id="type-system">
+ <title>Type System</title>
<para>
- A <firstterm>message</firstterm> consists of a
- <firstterm>header</firstterm> and a <firstterm>body</firstterm>. 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.
+ D-Bus has a type system, in which values of various types can be
+ serialized into a sequence of bytes referred to as the
+ <firstterm>wire format</firstterm> in a standard way.
+ Converting a value from some other representation into the wire
+ format is called <firstterm>marshaling</firstterm> and converting
+ it back from the wire format is <firstterm>unmarshaling</firstterm>.
</para>
-
+
<para>
- The body of the message is made up of zero or more
- <firstterm>arguments</firstterm>, which are typed values, such as an
- integer or a byte array.
+ The D-Bus protocol does not include type tags in the marshaled data; a
+ block of marshaled values must have a known <firstterm>type
+ signature</firstterm>. The type signature is made up of zero or more
+ <firstterm id="term-single-complete-type">single complete
+ types</firstterm>, each made up of one or more
+ <firstterm>type codes</firstterm>.
</para>
<para>
- Both header and body use the same type system and format for
- serializing data. Each type of value has a wire format.
- Converting a value from some other representation into the wire
- format is called <firstterm>marshaling</firstterm> and converting
- it back from the wire format is <firstterm>unmarshaling</firstterm>.
+ 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.
</para>
- <sect2 id="message-protocol-signatures">
- <title>Type Signatures</title>
+ <para>
+ 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:
+ <programlisting>
+ "aa"
+ </programlisting>
+ <programlisting>
+ "(ii"
+ </programlisting>
+ <programlisting>
+ "ii)"
+ </programlisting>
+ And the following signatures contain multiple complete types:
+ <programlisting>
+ "ii"
+ </programlisting>
+ <programlisting>
+ "aiai"
+ </programlisting>
+ <programlisting>
+ "(ii)(ii)"
+ </programlisting>
+ Note however that a single complete type may <emphasis>contain</emphasis>
+ multiple other single complete types, by containing a struct or dict
+ entry.
+ </para>
+
+ <sect2 id="basic-types">
+ <title>Basic types</title>
<para>
- The D-Bus protocol does not include type tags in the marshaled data; a
- block of marshaled values must have a known <firstterm>type
- signature</firstterm>. The type signature is made up of <firstterm>type
- codes</firstterm>. 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.
+ The simplest type codes are the <firstterm id="term-basic-type">basic
+ types</firstterm>, 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.
+ </para>
+
+ <para>
+ The <firstterm id="term-fixed-type">fixed types</firstterm>
+ 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.
</para>
<para>
</para>
<para>
- All <firstterm>basic</firstterm> types work like
- <literal>INT32</literal> in this example. To marshal and unmarshal
- basic types, you simply read one value from the data
- block corresponding to each type code in the signature.
+ The characteristics of the fixed types are listed in this table.
+
+ <informaltable>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Conventional name</entry>
+ <entry>ASCII type-code</entry>
+ <entry>Encoding</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>BYTE</literal></entry>
+ <entry><literal>y</literal> (121)</entry>
+ <entry>Unsigned 8-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>BOOLEAN</literal></entry>
+ <entry><literal>b</literal> (98)</entry>
+ <entry>Boolean value: 0 is false, 1 is true, any other value
+ allowed by the marshalling format is invalid</entry>
+ </row>
+ <row>
+ <entry><literal>INT16</literal></entry>
+ <entry><literal>n</literal> (110)</entry>
+ <entry>Signed (two's complement) 16-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>UINT16</literal></entry>
+ <entry><literal>q</literal> (113)</entry>
+ <entry>Unsigned 16-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>INT32</literal></entry>
+ <entry><literal>i</literal> (105)</entry>
+ <entry>Signed (two's complement) 32-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>UINT32</literal></entry>
+ <entry><literal>u</literal> (117)</entry>
+ <entry>Unsigned 32-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>INT64</literal></entry>
+ <entry><literal>x</literal> (120)</entry>
+ <entry>Signed (two's complement) 64-bit integer
+ (mnemonic: x and t are the first characters in "sixty" not
+ already used for something more common)</entry>
+ </row>
+ <row>
+ <entry><literal>UINT64</literal></entry>
+ <entry><literal>t</literal> (116)</entry>
+ <entry>Unsigned 64-bit integer</entry>
+ </row>
+ <row>
+ <entry><literal>DOUBLE</literal></entry>
+ <entry><literal>d</literal> (100)</entry>
+ <entry>IEEE 754 double-precision floating point</entry>
+ </row>
+ <row>
+ <entry><literal>UNIX_FD</literal></entry>
+ <entry><literal>h</literal> (104)</entry>
+ <entry>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)</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
+
+ <para>
+ The <firstterm id="term-string-like-type">string-like types</firstterm>
+ 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,
+ noncharacters such as U+FFFE, or codepoints above U+10FFFF.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ The characteristics of the string-like types are listed in this table.
+
+ <informaltable>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Conventional name</entry>
+ <entry>ASCII type-code</entry>
+ <entry>Validity constraints</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry><literal>STRING</literal></entry>
+ <entry><literal>s</literal> (115)</entry>
+ <entry>No extra constraints</entry>
+ </row>
+ <row>
+ <entry><literal>OBJECT_PATH</literal></entry>
+ <entry><literal>o</literal> (111)</entry>
+ <entry>Must be
+ <link linkend="message-protocol-marshaling-object-path">a
+ syntactically valid object path</link></entry>
+ </row>
+ <row>
+ <entry><literal>SIGNATURE</literal></entry>
+ <entry><literal>g</literal> (103)</entry>
+ <entry>Zero or more
+ <firstterm linkend="term-single-complete-type">single
+ complete types</firstterm></entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
+
+ <sect3 id="message-protocol-marshaling-object-path">
+ <title>Valid Object Paths</title>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ Object paths are often namespaced by starting with a reversed
+ domain name and containing an interface version number, in the
+ same way as
+ <link linkend="message-protocol-names-interface">interface
+ names</link> and
+ <link linkend="message-protocol-names-bus">well-known
+ bus names</link>.
+ 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).
+ </para>
+
+ <para>
+ For instance, if the owner of <literal>example.com</literal> is
+ developing a D-Bus API for a music player, they might use the
+ hierarchy of object paths that start with
+ <literal>/com/example/MusicPlayer1</literal> for its objects.
+ </para>
+
+ <para>
+ The following rules define a valid object path. Implementations must
+ not send or accept messages with invalid object paths.
+ <itemizedlist>
+ <listitem>
+ <para>
+ The path may be of any length.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The path must begin with an ASCII '/' (integer 47) character,
+ and must consist of elements separated by slash characters.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Each element must only contain the ASCII characters
+ "[A-Z][a-z][0-9]_"
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ No element may be the empty string.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Multiple '/' characters cannot occur in sequence.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A trailing '/' character is not allowed unless the
+ path is the root path (a single '/' character).
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ </sect3>
+
+ <sect3 id="message-protocol-marshaling-signature">
+ <title>Valid Signatures</title>
+ <para>
+ An implementation must not send or accept invalid signatures.
+ Valid signatures will conform to the following rules:
+ <itemizedlist>
+ <listitem>
+ <para>
+ The signature is a list of single complete types.
+ Arrays must have element types, and structs must
+ have both open and close parentheses.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Only type codes, open and close parentheses, and open and
+ close curly brackets are allowed in the signature. The
+ <literal>STRUCT</literal> type code
+ is not allowed in signatures, because parentheses
+ are used instead. Similarly, the
+ <literal>DICT_ENTRY</literal> type code is not allowed in
+ signatures, because curly brackets are used instead.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The maximum length of a signature is 255.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ 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.
+ </para>
+ </sect3>
+
+ </sect2>
+
+ <sect2 id="container-types">
+ <title>Container types</title>
+
+ <para>
In addition to basic types, there are four <firstterm>container</firstterm>
types: <literal>STRUCT</literal>, <literal>ARRAY</literal>, <literal>VARIANT</literal>,
and <literal>DICT_ENTRY</literal>.
</para>
<para>
- The phrase <firstterm>single complete type</firstterm> deserves some
- definition. 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.
- So the following signatures are not single complete types:
- <programlisting>
- "aa"
- </programlisting>
- <programlisting>
- "(ii"
- </programlisting>
- <programlisting>
- "ii)"
- </programlisting>
- And the following signatures contain multiple complete types:
- <programlisting>
- "ii"
- </programlisting>
- <programlisting>
- "aiai"
- </programlisting>
- <programlisting>
- "(ii)(ii)"
- </programlisting>
- Note however that a single complete type may <emphasis>contain</emphasis>
- multiple other single complete types.
- </para>
-
- <para>
<literal>VARIANT</literal> has ASCII character 'v' as its type code. A marshaled value of
type <literal>VARIANT</literal> will have the signature of a single complete type as part
of the <emphasis>value</emphasis>. This signature will be followed by a
</para>
<para>
+ 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.
+ </para>
+
+ <para>
A <literal>DICT_ENTRY</literal> 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
In most languages, an array of dict entry would be represented as a
map, hash table, or dict object.
</para>
+ </sect2>
+
+ <sect2>
+ <title>Summary of types</title>
<para>
The following table summarizes the D-Bus types.
</para>
</sect2>
+ </sect1>
- <sect2 id="message-protocol-marshaling">
- <title>Marshaling (Wire Format)</title>
+ <sect1 id="message-protocol-marshaling">
+ <title>Marshaling (Wire Format)</title>
+
+ <para>
+ 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.
+ </para>
+
+ <sect2>
+ <title>Byte order and alignment</title>
<para>
Given a type signature, a block of bytes can be converted into typed
</para>
<para>
- 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
- <xref linkend="message-protocol-messages"/>. For now, assume
- that the byte order is known to be either little endian or big
+ 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
+ <xref linkend="message-protocol-messages"/>. For now, assume
+ that the byte order is known to be either little endian or big
endian.
</para>
</para>
<para>
+ As an exception to natural alignment, <literal>STRUCT</literal> and
+ <literal>DICT_ENTRY</literal> values are always aligned to an 8-byte
+ boundary, regardless of the alignments of their contents.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Marshalling basic types</title>
+
+ <para>
+ 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).
+ </para>
+
+ <para>
+ The string-like types are all marshalled as a
+ fixed-length unsigned integer <varname>n</varname> giving the
+ length of the variable part, followed by <varname>n</varname>
+ 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
+ <varname>n</varname>.
+ </para>
+
+ <para>
+ For the STRING and OBJECT_PATH types, <varname>n</varname> is
+ encoded in 4 bytes, leading to 4-byte alignment.
+ For the SIGNATURE type, <varname>n</varname> is encoded as a single
+ byte. As a result, alignment padding is never required before a
+ SIGNATURE.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Marshalling containers</title>
+
+ <para>
+ Arrays are marshalled as a <literal>UINT32</literal>
+ <varname>n</varname> 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 <varname>n</varname> bytes of the
+ array elements marshalled in sequence. <varname>n</varname> does not
+ include the padding after the length, or any padding after the
+ last element.
+ </para>
+
+ <para>
+ 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:
+
+ <screen>
+00 00 00 08 <lineannotation>8 bytes of data</lineannotation>
+00 00 00 00 <lineannotation>padding to 8-byte boundary</lineannotation>
+00 00 00 00 00 00 00 05 <lineannotation>first element = 5</lineannotation>
+ </screen>
+ </para>
+
+ <para>
+ Arrays have a maximum length defined to be 2 to the 26th power or
+ 67108864. Implementations must not send or accept arrays exceeding this
+ length.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ Variants are marshalled as the <literal>SIGNATURE</literal> 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.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Summary of D-Bus marshalling</title>
+
+ <para>
Given all this, the types are marshaled on the wire as follows:
<informaltable>
<tgroup cols="3">
</row><row>
<entry><literal>OBJECT_PATH</literal></entry>
<entry>Exactly the same as <literal>STRING</literal> except the
- content must be a valid object path (see below).
+ content must be a valid object path (see above).
</entry>
<entry>
4 (for the length)
<entry><literal>SIGNATURE</literal></entry>
<entry>The same as <literal>STRING</literal> except the length is a single
byte (thus signatures have a maximum length of 255)
- and the content must be a valid signature (see below).
+ and the content must be a valid signature (see above).
</entry>
<entry>
1
<entry><literal>ARRAY</literal></entry>
<entry>
A <literal>UINT32</literal> 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. The array length is from the
- end of the alignment padding to the end of the last element,
- i.e. it does not include the padding after the length,
- or any padding after the last element.
- Arrays have a maximum length defined to be 2 to the 26th power or
- 67108864. Implementations must not send or accept arrays exceeding this
- length.
+ alignment padding to the alignment boundary of the array element type,
+ followed by each array element.
</entry>
<entry>
4 (for the length)
</row><row>
<entry><literal>VARIANT</literal></entry>
<entry>
- A variant type has a marshaled
- <literal>SIGNATURE</literal> followed by a marshaled
- value with the type given in the signature. 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.
+ The marshaled <literal>SIGNATURE</literal> of a single
+ complete type, followed by a marshaled value with the type
+ given in the signature.
</entry>
<entry>
1 (alignment of the signature)
</entry>
<entry>
8
- </entry>
- </row><row>
- <entry><literal>UNIX_FD</literal></entry>
- <entry>32-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.</entry>
- <entry>4</entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </para>
-
- <sect3 id="message-protocol-marshaling-object-path">
- <title>Valid Object Paths</title>
-
- <para>
- 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.
- </para>
-
- <para>
- The following rules define a valid object path. Implementations must
- not send or accept messages with invalid object paths.
- <itemizedlist>
- <listitem>
- <para>
- The path may be of any length.
- </para>
- </listitem>
- <listitem>
- <para>
- The path must begin with an ASCII '/' (integer 47) character,
- and must consist of elements separated by slash characters.
- </para>
- </listitem>
- <listitem>
- <para>
- Each element must only contain the ASCII characters
- "[A-Z][a-z][0-9]_"
- </para>
- </listitem>
- <listitem>
- <para>
- No element may be the empty string.
- </para>
- </listitem>
- <listitem>
- <para>
- Multiple '/' characters cannot occur in sequence.
- </para>
- </listitem>
- <listitem>
- <para>
- A trailing '/' character is not allowed unless the
- path is the root path (a single '/' character).
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- </sect3>
+ </entry>
+ </row><row>
+ <entry><literal>UNIX_FD</literal></entry>
+ <entry>32-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.</entry>
+ <entry>4</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </para>
-
- <sect3 id="message-protocol-marshaling-signature">
- <title>Valid Signatures</title>
- <para>
- An implementation must not send or accept invalid signatures.
- Valid signatures will conform to the following rules:
- <itemizedlist>
- <listitem>
- <para>
- The signature ends with a nul byte.
- </para>
- </listitem>
- <listitem>
- <para>
- The signature is a list of single complete types.
- Arrays must have element types, and structs must
- have both open and close parentheses.
- </para>
- </listitem>
- <listitem>
- <para>
- Only type codes and open and close parentheses are
- allowed in the signature. The <literal>STRUCT</literal> type code
- is not allowed in signatures, because parentheses
- are used instead.
- </para>
- </listitem>
- <listitem>
- <para>
- 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.
- </para>
- </listitem>
- <listitem>
- <para>
- The maximum length of a signature is 255.
- </para>
- </listitem>
- <listitem>
- <para>
- Signatures must be nul-terminated.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </sect3>
-
</sect2>
+ </sect1>
+
+ <sect1 id="message-protocol">
+ <title>Message Protocol</title>
+
+ <para>
+ A <firstterm>message</firstterm> consists of a
+ <firstterm>header</firstterm> and a <firstterm>body</firstterm>. 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.
+ </para>
+
+ <para>
+ The body of the message is made up of zero or more
+ <firstterm>arguments</firstterm>, which are typed values, such as an
+ integer or a byte array.
+ </para>
+
+ <para>
+ Both header and body use the D-Bus <link linkend="type-system">type
+ system</link> and format for serializing data.
+ </para>
+
<sect2 id="message-protocol-messages">
<title>Message Format</title>
<listitem><para>Interface names must not exceed the maximum name length.</para></listitem>
</itemizedlist>
</para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ For instance, if the owner of <literal>example.com</literal> is
+ developing a D-Bus API for a music player, they might define
+ interfaces called <literal>com.example.MusicPlayer1</literal>,
+ <literal>com.example.MusicPlayer1.Track</literal> and
+ <literal>com.example.MusicPlayer1.Seekable</literal>.
+ </para>
+
+ <para>
+ 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.
+ </para>
</sect3>
<sect3 id="message-protocol-names-bus">
<title>Bus names</title>
<para>
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 connection has exactly one bus name that is a <firstterm>unique
+ connection name</firstterm>. The unique connection name remains
+ with the connection for its entire lifetime.
A bus name is of type <literal>STRING</literal>,
meaning that it must be valid UTF-8. However, there are also
some additional restrictions that apply to bus names
specifically:
<itemizedlist>
<listitem><para>Bus names that start with a colon (':')
- character are unique connection names.
+ character are unique connection names. Other bus names
+ are called <firstterm>well-known bus names</firstterm>.
</para>
</listitem>
<listitem><para>Bus names are composed of 1 or more elements separated by
Note that the hyphen ('-') character is allowed in bus names but
not in interface names.
</para>
+
+ <para>
+ Like <link linkend="message-protocol-names-interface">interface
+ names</link>, 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.
+ </para>
+
+ <para>
+ 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 <literal>example.com</literal>
+ is developing a D-Bus API for a music player, they might define
+ that any application that takes the well-known name
+ <literal>com.example.MusicPlayer1</literal> should have an object
+ at the object path <literal>/com/example/MusicPlayer1</literal>
+ which implements the interface
+ <literal>com.example.MusicPlayer1</literal>.
+ </para>
</sect3>
<sect3 id="message-protocol-names-member">
<title>Member names</title>
<listitem><para>Must be at least 1 byte in length.</para></listitem>
</itemizedlist>
</para>
+
+ <para>
+ 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
+ <literal>GetItems</literal>, and signal names should usually be
+ a description of an event, such as <literal>ItemsChanged</literal>.
+ </para>
</sect3>
<sect3 id="message-protocol-names-error">
<title>Error names</title>
<para>
Error names have the same restrictions as interface names.
</para>
+
+ <para>
+ Error names have the same naming conventions as interface
+ names, and often contain <literal>.Error.</literal>; for instance,
+ the owner of <literal>example.com</literal> might define the
+ errors <literal>com.example.MusicPlayer.Error.FileNotFound</literal>
+ and <literal>com.example.MusicPlayer.Error.OutOfMemory</literal>.
+ The errors defined by D-Bus itself, such as
+ <literal>org.freedesktop.DBus.Error.Failed</literal>, follow a
+ similar pattern.
+ </para>
</sect3>
</sect2>
[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, TCP/IP, and a debug/testing transport
+ 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.
</para>
would be padded by Nul bytes.
</para>
<para>
- Unix domain sockets are not available on windows.
+ Unix domain sockets are not available on Windows.
</para>
<sect3 id="transports-unix-domain-sockets-addresses">
<title>Server Address Format</title>
<sect2 id="transports-launchd">
<title>launchd</title>
<para>
- launchd is a open-source server management system that replaces init, inetd
+ 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.
</para>
</informaltable>
</sect3>
</sect2>
+ <sect2 id="transports-systemd">
+ <title>systemd</title>
+ <para>
+ 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.
+ </para>
+ <para>
+ The systemd transport accepts only one or more Unix domain or
+ TCP streams sockets passed in via socket activation.
+ </para>
+ <para>
+ The systemd transport is not available on non-Linux operating systems.
+ </para>
+ <para>
+ The systemd transport defines no parameter keys.
+ </para>
+ </sect2>
<sect2 id="transports-tcp-sockets">
<title>TCP Sockets</title>
<para>
over a network is unsecure.
</para>
<para>
- Windows notes: Because of the tcp stack on windows does not provide sending
+ Windows notes: Because of the tcp stack on Windows does not provide sending
credentials over a tcp connection, the EXTERNAL authentification
mechanismus does not work.
</para>
</informaltable>
</sect3>
</sect2>
+ <sect2 id="transports-exec">
+ <title>Executed Subprocesses on Unix</title>
+ <para>
+ 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.
+ </para>
+ <para>
+ The forked process will inherit the standard error output and
+ process group from the parent process.
+ </para>
+ <para>
+ Executed subprocesses are not available on Windows.
+ </para>
+ <sect3 id="transports-exec-addresses">
+ <title>Server Address Format</title>
+ <para>
+ Executed subprocess addresses are identified by the "unixexec:" prefix
+ and support the following key/value pairs:
+ </para>
+ <informaltable>
+ <tgroup cols="3">
+ <thead>
+ <row>
+ <entry>Name</entry>
+ <entry>Values</entry>
+ <entry>Description</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>path</entry>
+ <entry>(path)</entry>
+ <entry>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.</entry>
+ </row>
+ <row>
+ <entry>argv0</entry>
+ <entry>(string)</entry>
+ <entry>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().</entry>
+ </row>
+ <row>
+ <entry>argv1, argv2, ...</entry>
+ <entry>(string)</entry>
+ <entry>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.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </informaltable>
+ </sect3>
+ </sect2>
</sect1>
<sect1 id="meta-transports">
<title>Meta Transports</title>
</sect3>
</sect2>
</sect1>
- <sect1 id="naming-conventions">
- <title>Naming Conventions</title>
-
- <para>
- D-Bus namespaces are all lowercase and correspond to reversed domain
- names, as with Java. e.g. "org.freedesktop"
- </para>
- <para>
- Interface, signal, method, and property names are "WindowsStyleCaps", note
- that the first letter is capitalized, unlike Java.
- </para>
- <para>
- Object paths are normally all lowercase with underscores used rather than
- hyphens.
- </para>
- </sect1>
<sect1 id="uuids">
<title>UUIDs</title>
</programlisting>
</para>
<para>
+ It is conventional to give D-Bus properties names consisting of
+ capitalized words without punctuation ("CamelCase"), like
+ <link linkend="message-protocol-names-member">member names</link>.
+ For instance, the GObject property
+ <literal>connection-status</literal> or the Qt property
+ <literal>connectionStatus</literal> could be represented on D-Bus
+ as <literal>ConnectionStatus</literal>.
+ </para>
+ <para>
+ 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.
+ </para>
+ <para>
The available properties and whether they are writable can be determined
by calling <literal>org.freedesktop.DBus.Introspectable.Introspect</literal>,
see <xref linkend="standard-interfaces-introspectable"/>.
<title><literal>org.freedesktop.DBus.ObjectManager</literal></title>
<para>
An API can optionally make use of this interface for one or
- more sub-trees of objects. The root of each sub-tree implement
+ 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
interfaces, no calls to the
<literal>org.freedesktop.Properties</literal> interface on the
remote object are needed. Additionally, since the initial
- <literal>AddMatch()</literal> rule already include signal
+ <literal>AddMatch()</literal> rule already includes signal
messages from the newly created child object, no new
<literal>AddMatch()</literal> call is needed.
</para>
that connection is said to <firstterm>own</firstterm> the name.
</para>
<para>
- The bus itself owns a special name, <literal>org.freedesktop.DBus</literal>.
- This name routes messages to the bus, allowing applications to make
- administrative requests. For example, applications can ask the bus
- to assign a name to a connection.
+ The bus itself owns a special name,
+ <literal>org.freedesktop.DBus</literal>, with an object
+ located at <literal>/org/freedesktop/DBus</literal> that
+ implements the <literal>org.freedesktop.DBus</literal>
+ 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.
</para>
<para>
Each name may have <firstterm>queued owners</firstterm>. When an
</para>
<para>
- Messages may have a <literal>DESTINATION</literal> field (see <xref
- linkend="message-protocol-header-fields"/>). If the
- <literal>DESTINATION</literal> 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
- <literal>DESTINATION</literal> field set to the specified recipient,
- regardless of whether the recipient has set up a match rule matching
- the message.
- </para>
-
- <para>
- Signals normally do not specify a destination; they are sent to all
- applications with <firstterm>message matching rules</firstterm> that
- match the message.
- </para>
-
- <para>
- When the message bus receives a method call, if the
- <literal>DESTINATION</literal> 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
- <literal>org.freedesktop.DBus.Peer.Ping</literal> message with no
- <literal>DESTINATION</literal> will cause the message bus itself to
- reply to the ping immediately; the message bus will not make this
- message visible to other applications.
- </para>
-
- <para>
- Continuing the <literal>org.freedesktop.DBus.Peer.Ping</literal> example, if
- the ping message were sent with a <literal>DESTINATION</literal> name of
- <literal>com.yoyodyne.Screensaver</literal>, then the ping would be
- forwarded, and the Yoyodyne Corporation screensaver application would be
- expected to reply to the ping.
+ Applications may send <firstterm>unicast messages</firstterm> to
+ a specific recipient or to the message bus itself, or
+ <firstterm>broadcast messages</firstterm> to all interested recipients.
+ See <xref linkend="message-bus-routing"/> for details.
</para>
</sect2>
<sect2 id="message-bus-routing">
<title>Message Bus Message Routing</title>
+
+ <para>
+ Messages may have a <literal>DESTINATION</literal> field (see <xref
+ linkend="message-protocol-header-fields"/>), resulting in a
+ <firstterm>unicast message</firstterm>. If the
+ <literal>DESTINATION</literal> 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
+ <literal>DESTINATION</literal> field set to the specified recipient,
+ regardless of whether the recipient has set up a match rule matching
+ the message.
+ </para>
+
+ <para>
+ When the message bus receives a signal, if the
+ <literal>DESTINATION</literal> field is absent, it is considered to
+ be a <firstterm>broadcast signal</firstterm>, and is sent to all
+ applications with <firstterm>message matching rules</firstterm> that
+ match the message. Most signal messages are broadcasts.
+ </para>
+
+ <para>
+ Unicast signal messages (those with a <literal>DESTINATION</literal>
+ 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 <xref linkend="bus-messages-add-match"/> 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.
+ </para>
+
+ <para>
+ When the message bus receives a method call, if the
+ <literal>DESTINATION</literal> 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
+ <literal>org.freedesktop.DBus.Peer.Ping</literal> message with no
+ <literal>DESTINATION</literal> will cause the message bus itself to
+ reply to the ping immediately; the message bus will not make this
+ message visible to other applications.
+ </para>
+
+ <para>
+ Continuing the <literal>org.freedesktop.DBus.Peer.Ping</literal> example, if
+ the ping message were sent with a <literal>DESTINATION</literal> name of
+ <literal>com.yoyodyne.Screensaver</literal>, then the ping would be
+ forwarded, and the Yoyodyne Corporation screensaver application would be
+ expected to reply to the ping.
+ </para>
+
<para>
- FIXME
+ Message bus implementations may impose a security policy which
+ prevents certain messages from being sent or received.
+ When a 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 <literal>NO_REPLY</literal> flag.
</para>
+
+ <sect3 id="message-bus-routing-eavesdropping">
+ <title>Eavesdropping</title>
+ <para>
+ Receiving a unicast message whose <literal>DESTINATION</literal>
+ indicates a different recipient is called
+ <firstterm>eavesdropping</firstterm>. 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.
+ </para>
+
+ <para>
+ Eavesdropping is mainly useful for debugging tools, such as
+ the <literal>dbus-monitor</literal> 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.
+ </para>
+
+ <para>
+ Clients may attempt to eavesdrop by adding match rules
+ (see <xref linkend="message-bus-routing-match-rules"/>) containing
+ the <literal>eavesdrop='true'</literal> 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 <literal>eavesdrop</literal> match
+ omitted.
+ </para>
+ </sect3>
+
<sect3 id="message-bus-routing-match-rules">
<title>Match Rules</title>
<para>
- An important part of the message bus routing protocol is match
- rules. Match rules describe what messages can be sent to a client
- based on the contents of the message. When a message is routed
- through the bus it is compared to clients' match rules. If any
- of the rules match, the message is dispatched to the client.
- If none of the rules match the message never leaves the bus. This
- is an effective way to control traffic over the bus and to make sure
- only relevant message need to be processed by the client.
+ 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.
+ </para>
+ <para>
+ Messages that list a client as their <literal>DESTINATION</literal>
+ 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.
+ </para>
+ <para>
+ Match rules can also be used for eavesdropping
+ (see <xref linkend="message-bus-routing-eavesdropping"/>),
+ if the security policy of the message bus allows it.
</para>
<para>
Match rules are added using the AddMatch bus method
</para>
</entry>
</row>
+ <row>
+ <entry><literal>eavesdrop</literal></entry>
+ <entry><literal>'true'</literal>, <literal>'false'</literal></entry>
+ <entry>Since D-Bus 1.5.6, match rules do not
+ match messages which have a <literal>DESTINATION</literal>
+ field unless the match rule specifically
+ requests this
+ (see <xref linkend="message-bus-routing-eavesdropping"/>)
+ by specifying <literal>eavesdrop='true'</literal>
+ in the match rule. <literal>eavesdrop='false'</literal>
+ restores the default behaviour. Messages are
+ delivered to their <literal>DESTINATION</literal>
+ 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
+ <literal>eavesdrop='true'</literal> had been used.
+ </entry>
+ </row>
</tbody>
</tgroup>
</informaltable>
<sect4>
<title></title>
<para>
- [FIXME specify location of .service files, probably using
- DESKTOP_DIRS etc. from basedir specification, though login session
- bus is not really desktop-specific]
+ On Unix systems, the session bus should search for .service files
+ in <literal>$XDG_DATA_DIRS/dbus-1/services</literal> as defined
+ by the
+ <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG Base Directory Specification</ulink>.
+ 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 <literal>${datadir}/dbus-1/services</literal> as
+ set at compile time.
+ </para>
+ <para>
+ As described in the XDG Base Directory Specification, software
+ packages should install their session .service files to their
+ configured <literal>${datadir}/dbus-1/services</literal>,
+ where <literal>${datadir}</literal> 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.
</para>
</sect4>
</sect3>
</footnote>
</para>
<para>
- [FIXME specify location of system bus .service files]
+ On Unix systems, the system bus should default to searching
+ for .service files in
+ <literal>/usr/local/share/dbus-1/system-services</literal>,
+ <literal>/usr/share/dbus-1/system-services</literal> and
+ <literal>/lib/dbus-1/system-services</literal>, with that order
+ of precedence. It may also search other implementation-specific
+ locations, but should not vary these locations based on environment
+ variables.
+ <footnote>
+ <para>
+ 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.
+ </para>
+ </footnote>
+ </para>
+ <para>
+ Software packages should install their system .service
+ files to their configured
+ <literal>${datadir}/dbus-1/system-services</literal>,
+ where <literal>${datadir}</literal> 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.
</para>
</sect3>
</sect2>
can be thought of as "well-known names" and are
used to find applications that offer specific functionality.
</para>
+
+ <para>
+ See <xref linkend="message-protocol-names-bus"/> for details of
+ the syntax and naming conventions for bus names.
+ </para>
</glossdef>
</glossentry>
<glossentry id="namespace"><glossterm>Namespace</glossterm>
<glossdef>
- <para>
- Used to prevent collisions when defining new interfaces or bus
- names. The convention used is the same one Java uses for defining
- classes: a reversed domain name.
+ <para>
+ 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 <xref linkend="message-protocol-names-bus"/>,
+ <xref linkend="message-protocol-names-interface"/>,
+ <xref linkend="message-protocol-names-error"/>,
+ <xref linkend="message-protocol-marshaling-object-path"/>.
</para>
</glossdef>
</glossentry>