Some comments on the D-Bus specification
hp at pobox.com
Wed Apr 22 07:15:41 PDT 2015
George Spelvin sent me these nice suggested edits and clarifications
for the spec, I'm passing them along with his permission (see quoted
On Tue, Apr 21, 2015 at 9:50 PM, George Spelvin <linux at horizon.com> wrote:
> As part of the lkml debate on kdbus, I'm reading and trying to understand
> the D-bus specification.
> Here are a few questions that reading it has raised.
> 1. Is there a "void" type? A dictionary from key to void
> seems like a natural way of representing a set of keys.
> 2. Is alignment padding only before objects, or also after?
> In particular, if I have y(yy)y, is it encoded as:
> 01 00 00 00 00 00 00 00 02 03 04
> 01 00 00 00 00 00 00 00 02 03 00 00 00 00 00 00 04
> | | | | |
> 0 4 8 12 16
> 3. Why is the request serial number passed in the reply's REPLY_SERIAL
> header extension field, and not simply in the reply header serial
> Can METHOD_RETURN or ERROR messages themselves generate errors?
> 4. May interface names end with a period?
> It seems that a simple way to specify an interface name is
> with the regexp:
> That, and the maximum total length of 255 characters, seems to make
> a complete specification.
> 5. May bus names contain a colon? The specification simultaneously
> requires a leading colon and forbids any colons in bus names.
> This is confusing.
> The specification apears to say that a valid well-known bus name
> matches the regexp
> and a unique connection name matches the regexp
> Which is, I note, a strict superset of the well-known bus names.
> 6. It might also be worth describing such names as "ASCII strings"
> (a term that's already used when describing type signatures) and
> noting that ASCII strings are a strict subset of UTF-8 strings.
> 7. What if ownership of a DNS name changes? Does that also transfer the
> right to define the interface? Or only the right to revise it?
> E.g. suppose that I own the domain love.ly. But some strange
> quirk of international politics prevents us doing business together,
> so they revoke the registration and someone else snaps it up.
> 8. In the DBUS_COOKIE_SHA1 mechanism, are the various strings
> hex-decoded before computing the SHA-1?
> I.e. suppose we have:
> C: AUTH DBUS_COOKIE_SHA1 666f6f # "foo"
> S: DATA 62617220302062617a # "bar 0 baz"
> And the client generates the challenge string "quux".
> Further, suppose the cookie file contains
> 0 0 676172706c79
> Does the client hash "62617a:71757578:676172706c79"
> and respond with
> C: DATA 71757578202af2495a8ef8250e39cb9cbf50d9fd3a1eab954c
> or does it hash "baz:quux:garply" and respond with
> C: DATA 71757578204a6aaebfe03c70cc29ccfb1733897fc2e548ad0e
> If the latter, are there any restrictions on colon characters in
> challenge strings?
> 9. In the cookie file format, are the cookie ID and creation time
> written in decimal, octal, C-style integers, or what?
> 10. Is it worth documenting that the creation timestamp will exceed
> 32 bits in the year 2100?
> 11. In the cookie file format, why is any non-zero time in the future
> permissible? Creation times should be strictly in the past, no?
> 12. The syntax of systemd transport addresses is completely unspecified.
> Presumably they begin with "systemd:", but even that is unclear.
> 13. The section "message bus names" is confusing on the subject of
> unique names.
> In particular, when a connection is closed with a next connection
> in the queue, is the unique name transferred to the next connection?
> May a unique name be passed to org.freedesktop.DBus.ReleaseName?
> 14. Allegedly, there are strong guarantees on what a client can receive
> over a dbus connection. I can't find that stated anywhere.
> For example:
> - Are there *any* possible messages I may receive before calling
> - Are there any possible messages I may receive between the METHOD_CALL
> and METHOD_RETURN for Hello? In particular, is the
> org.freedesktop.DBus.NameAcquired SIGNAL for the unique name
> delivered before or after the METHOD_RETURN?
> - Likewise, for org.freedesktop.DBus.Monitoring.BecomeMonitor, do the
> various NameLost signals arrive before or after the METHOD_RETURN?
> - May another client send me a spurious or duplicate METHOD_RETURN?
> - How about both an ERROR and METHOD_RETURN?
> - How does a server terminate cleanly, that is with an appropriate
> METHOD_RETURN for every METHOD_CALL it has received? First I
> assumed it could halt further calls with ReleaseName, but
> then I rememebed your e-mail saying that many clients
> use GetNameOwner and cache the unique name. May a server
> ReleaseName its unique name before flusing its queue
> of pending METHOD_RETURNs?
> - What if a server exits without sending a METHOD_RETURN?
> - What if I use a message serial of 0, or a message serial of
> 1 for all my METHOD_CALLs?
> - Is there any limit on the number of outstanding METHOD_CALLs?
More information about the dbus