Systemd Looking At A Future With More Varlink & Less D-Bus For IPC

[phoronix]

Phoronix: Systemd Looking At A Future With More Varlink & Less D-Bus For IPC

Taking place this week in Berlin was systemd's annual "All Systems Go" developer conference. Among the interesting talks was Lennart Poettering talking about the ongoing challenges of D-Bus for inter-process communication (IPC) with systemd and how they are looking at Varlink for IPC needs moving forward...

https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future

[HEL88]

The open source world often likes to turn things upside down.

[oleid]

Why would one use json for a message bus payload and not something binary like - I don't know - messagepack? Serialising and deserialising json is not really efficient.
The following benchmark is using a very efficient json library. Note that the X axis is logarithmic:

https://github.com/getml/reflect-cpp/tree/main/benchmarks

[Quackdoc]

and now we turn out heads to the right and see binder, hello binder, he is our special little goober.

[flower]

Why would one use json for a message bus payload and not something binary like - I don't know - messagepack? Serialising and deserialising json is not really efficient.
The following benchmark is using a very efficient json library. Note that the X axis is logarithmic:

https://github.com/getml/reflect-cpp...ain/benchmarks

my guess is web compatibility. at least it was mentioned in the slide.
but well.... i guess web is the reason why we can't have nice things anymore

[Vermilion]

I find it ironic that systemd is looking for dbus alternatives. Still, it's commendable that they went with Varlink and not a new systemd-ipcd component.

[hkupty]

Why would one use json for a message bus payload and not something binary like - I don't know - messagepack?

I can see from where they're coming from. JSON is definitely a de-facto standard in web development for the ease of crafting messages and sending directly or for debugging purposes as opposed to parsing binary messages. Having that said, I don't think I agree with that decision since this is intended for local IPC, not over-the-network where oftentimes client and server diverge. One could easily instead invest time in writing a simple cat-like tool that also serializes json into binary and vice-versa, so piping local messages to IPC could still be done in a human-readable format while still preserving processing power on both ends. I guess we'll have to wait and see how this unfolds..

[jonkoops]

I can see from where they're coming from. JSON is definitely a de-facto standard in web development for the ease of crafting messages and sending directly or for debugging purposes as opposed to parsing binary messages. Having that said, I don't think I agree with that decision since this is intended for local IPC, not over-the-network where oftentimes client and server diverge. One could easily instead invest time in writing a simple cat-like tool that also serializes json into binary and vice-versa, so piping local messages to IPC could still be done in a human-readable format while still preserving processing power on both ends. I guess we'll have to wait and see how this unfolds..

Exactly, thjat was what I was thinking as well, why not make it fast and optimized by default and for debugging have some simple utils? Perhaps I am overestimating the cost here, but this seems a pretty performance sensitive component.

[tsuru]

What is the governance model of the Varlink project? Who owns it -- Redhat? Microsoft? an Individual? I can't find these details easily on varlink.org or the various github projects...

[discordian]

Exactly, thjat was what I was thinking as well, why not make it fast and optimized by default and for debugging have some simple utils? Perhaps I am overestimating the cost here, but this seems a pretty performance sensitive component.

IPC generally needs several context switches, dont think writing/parsing json creates a new problem there.
varlink has the option to turn the existing connection in a normal stream at which point you can do whatever you like.
similarly you could exchange fds for shared memory.

its generally not uses in perf critical stuff (AFAIK), and for perf critical stuff you are better off with specialized solutions.

i am more concerned with needing to search for nul bytes to find the end of the message. unix SOCK_SEQPACKET would be a perfect fit, so you send and receive just complete messages.