D-Bus Versus Varlink

[Lennart Poettering]

On Di, 02.04.24 18:13, Thiago Macieira (thiago at kde.org) wrote:

> > If I use "strace" or some other debugging tool on a complex systemd
> > session i can suddenly understand immediately what is going on,
> > because I can directly make sense of every method call and every
> > method reply becaus JSON is readable as tetx.
>
> That depends on who's doing the debugging. I don't deny that it's harder to
> read. If I strace the systemd-resolved transmission, I can immediately tell
> what it is:
>
> recvfrom(3, "{\"parameters\":{\"addresses\":[{\"ifindex\":4,\"family\":10,
> \"address\":[32,1,72,96,72,96,0,0,0,0,0,0,0,0,136,68]},{\"ifindex\":4,
> \"family\":10,\"address\":[32,1,72,96,72,96,0,0,0,0,0,0,0,0,136,136]}],
> \"name\":\"dns.google\",\"flags\":1048577}}\0", 135152, MSG_DONTWAIT, NULL,
> NULL) = 224
>
> If it were binary, I might not know what it is.
>
> But for anyone who's deeply involved with the project in question, they can
> decode CBOR or D-Bus binary in their heads (I know I can).

I wrote sd-bus. I still cannot. I recognize the strings in D-Bus
strace dumps, but even then I am always confused if I am looking at a
D-Bus service name or a D-Bus interface name.

Given that I am bad at it, and I know D-Bus better than most I guess I
am pretty sure there a many people who are equally shit a reading
D-Bus dumps as I am.

> > Sure, CBOR would make things a bit faster, but only a a couple of 10%
> > or so (see zeeshan's numbers). That's not something I am too much
> > concerned with. The debuggability is *a* *lot* *more* *important*.
>
> I've posted why I am not completely convinced by those numbers. That's also
> ignoring some other advantages, like the ability to use small integers for map
> keys instead of (repeated) strings. Of the 224 bytes of the payload above, 64
> are the string keys. The 16 bytes of the IPv6 were transmitted in 39
> bytes.

For local transport the size really doesn't matter much. Copying
memory on modern CPUs is blazingly fast, you don't need to optimize a
100 bytes off really.

A context switch kills you. A mmap() kills you. Copying 100 bytes more
or less OTOH is hard to even measure at all.

> > (Also, JSON is what the web community generally uses, and Varlink is
> > supposed to be easy, and natural to use via an HTTP proxy, i.e. it's
> > request/response based, so if you glue a GET in fron of each method
> > call and an HTTP 200 OK after each method reply you are basically
> > already there.)
>
> These days, one expects to start an SSL/TLS session, even for same-network
> services, so if you're using a proxy, you'll use CONNECT.

I didn't mean "proxy" in the sense of a classic HTTP proxy. I meant
the word as a gateway between the Varlink and HTTP worlds.

> On the other hand, if you're expecting to talk performance and minimal
> resources, it would be the IoT community, not the web one, to talk to. The
> IETF CoRE WG created CoAP, which is very similar to HTTP in semantics, but
> simpler (think of it as an evolution of Google's QUIC, the same as CBOR being
> an evolution of MsgPack). And there you'd have UDP and DTLS.

Sorry, but that's really outside of my interest. The goal with Varlink
is to have a good, debuggable, traceable local IPC you can build an OS
from – but where the gateway to the HTTP world is naturally existent.

Lennart

--
Lennart Poettering, Berlin