DBus Specification questions

[Robert Middleton]

On Tue, Mar 31, 2020 at 6:33 AM Simon McVittie <smcv at collabora.com> wrote:
>
> On Mon, 30 Mar 2020 at 23:07:02 -0400, Robert Middleton wrote:
> > I'm working on updating some DBus bindings, and part of that effort
> > involves reimplementing libdbus.
>
> The terminology that we normally use is that if you wrap libdbus (or maybe
> some other implementation like GDBus or sd-bus), you're writing a binding;
> but if you're reimplementing all the bits of libdbus you previously used,
> your library has moved from being a binding to being an implementation.
>
> So, for example, dbus-python and dbus-glib are bindings (they use
> libdbus to do the real work), but GDBus and sd-bus are implementations
> (they implement the whole D-Bus message framing protocol over a Unix or
> TCP socket themselves).
>
> Changing your approach is fine - I think dbus-java 1.x was a binding and
> 2.x is an implementation? - but if you use the same terms as everyone
> else it'll reduce confusion.

Good to note - I'm updating a current binding to be an implementation.
Part of this is so that I can fully support all types, part of this is
to (hopefully) have a better multi-threaded implementation than
libdbus.

Related question: I know that there have been issues with libdbus and
multithreading, any thoughts on how to best handle this?  The most
relevant thread on the mailing list was [1].

> > 3. Who processes METHOD_CALL timeouts?  From my use of dbus-java I
> > believe that this is always handled by the sender, but the
> > specification does not mention anything about it.
>
> I don't think the specification mentions timeouts at all - which means
> that if you want a timeout (you do), it more or less *has to be* handled
> by the sender. If it was handled by anyone else, they would have no way
> to know what timeout the sender considered to be appropriate, because
> there's no encoding for "the timeout is..." in a message header.
>
> The reference dbus-daemon can theoretically impose a second layer of
> timeouts (orthogonal to the client-side timeouts!) on all messages that
> go through it, but in practice that timeout has been set to "infinite"
> since 2009.
>

That's what I thought; I wasn't completely sure as there is an error
org.freedesktop.DBus.Error.NoReply, which at least implies(to me) that
this can come from other places.  Now that I think about it though,
can the daemon ever respond back with an error?  Is there a list of
well-known errors and who is responsible for generating the error?

> > 5. If a call has the NO_REPLY_EXPECTED flag set, does sending a
> > response or an error back constitute an invalid action?
>
> In RFC 2119 terms, I'd say it's a SHOULD NOT. Peers are expected to not
> crash or misbehave or anything like that if you do send an "unsolicited
> reply", but you'll get warnings logged: for example, on the well-known
> system bus, replying to a NO_REPLY_EXPECTED message causes security policy
> warnings to be logged, because the dbus-daemon keeps a record of "exactly
> one reply to this is allowed" for ordinary method calls, and does not do
> that for NO_REPLY_EXPECTED method calls. So the unsolicited reply is
> rejected, with a warning.
>
> Note that non-method-calls (signals, successful replies, error replies)
> always behave as though they are NO_REPLY_EXPECTED, even if the flag
> isn't set.

That makes sense to me; the specification uses the word "should", so
the clarification is good.

-Robert Middleton

[1]: https://lists.freedesktop.org/archives/dbus/2018-March/017425.html