D-Bus Versus Varlink

[Lennart Poettering]

On Do, 21.03.24 16:23, Lawrence D'Oliveiro (ldo at geek-central.gen.nz) wrote:

> I recently discovered the existence of Varlink <https://varlink.org/>.
> Turns out it’s been around for a few years--here
> <https://lwn.net/Articles/742675/> is some discussion of a rationale for
> its creation. Note this bit:
>
>     ... it aims to provide IPC from early boot onward, though it does
>     not really address the longtime D-Bus performance complaints that
>     also served as motivation for kdbus and bus1.
>
> Commonalities with D-Bus:
> * the concept of an “interface”, uniquely named according to the common
>   reverse-domain format; which (among other things) defines named
>   “methods”, each of which takes zero or more arguments
>   (“in-parameters”) of specified types, and returns zero or more
>   results (“out-parameters”) of specified types.
> * A standardized introspection interface, that can be used to query a
>   connection peer as to what interfaces it supports, and how they are
>   defined.
>
> Differences from D-Bus:
> * No concept of an object path as the target of a method call. Hence no
>   standardized interfaces for managing such objects, no get/set
>   properties etc.
> * No “signals” as such; however, method calls can return no reply, or
>   even multiple replies. They can also return an “error” message
>   indicating something went wrong with the method call.
> * Point-to-point protocol, no intermediary daemon. So a client has to
>   know the address (Unix socket, TCP etc) to connect to.
> * Messages are JSON structs with standardized top-level fields;
>   messages are terminated by a null byte.
> * Struct field/argument types may be marked as “optional”, which means
>   that the value is allowed to be null.
> * Allows user-defined enumeration types, with specified strings as
>   values.
> * Allows user-defined names for enumeration and struct types.
> * Defines its own introspection language, not based on XML (or JSON,
>   or anything else immediately recognizable.)
>
> (Anything else I missed?)

Some advantages off the top of my head:

* No multiplexing of multiple calls onto a single connection

* Built around notion of "cheap" connections, i.e. no handshake or
  anything, just AF_UNIX and write(). i.e. if you want parallel
  operations being queued, you allocate multiple connections, instead
  of multiplexing them into one.

* Thus only local ordering, no global ordering

* Suitable to streaming large amount of data (i.e. useful for listing
  larger directories of things, where the dbus broker would normally
  kick you off the bus)

* A connection is an implicit *pin* of the remote object accessed

* No policy of its own. Only UNIX access controls (access
  mode/ownership ACLs) on entry-point socket + whatever people build
  on top of SO_PEERCREDS/SO_PEERGROUPS/SO_PEERSEC/SO_PEERPIDFD

* Available in early boot

* Authenticated method call costs a single round trip, not five as on
  D-Bus.

* Defined behaviour for protocol upgrades (i.e. start with Varlink,
  then clearly switch over to downloading blobs without varlink, on
  the same connection)

* Compatibility with HTTP (i.e. clear response request logic, JSON is
  web tech).

* Simplicity to explain ("just a JSON blob, suffixed with a NUL byte
  written to an AF_UNIX stream socket as method call, and zero, one or
  more method replies as JSON blobs suffixed with a NUL byte back")

It has some disadvantages too:

* Much less adopted, fewer exsting bindings

* JSON sucks for large integers. Generally, 52bit integers are safe
  (because they fit into 64bit floats without loss), everything else
  is icky because implementations handle this differently.

Lennart

--
Lennart Poettering, Berlin