Missing the AF_BUS [LWN.net]

Missing the AF_BUS

Posted Jul 5, 2012 19:26 UTC (Thu) by iabervon (subscriber, #722)
In reply to: Missing the AF_BUS by smurf
Parent article: Missing the AF_BUS

It seems to me like the right solution for a lot of the low-latency or high-throughput applications is actually to send a socketpair endpoint over DBus, rather than using DBus for the actual data. Provided, of course, that that works. If nothing else, it would be very much worthwhile to save the packet framing when you have a logical data stream, and it's hard to beat a scheme where your Chinese user input can be turned into stdin with nothing more than dup2 and inherited by child processes.

(Log in to post comments)

Missing the AF_BUS

Posted Jul 5, 2012 19:53 UTC (Thu) by hp (subscriber, #5220) [Link]

Yep. You can even use the dbus protocol over that socketpair. libdbus could probably provide some nice convenience API to facilitate this where you'd basically get a DBusConnection back from a method call to the remote service.

The downside is mostly that it's a fair bit more work for apps to do stuff like this. Services don't necessarily need to track "registered clients" right now but with this kind of setup they have to, in addition to dealing with the raw sockets and other extra work.

A lot of the discussion of speeding up dbus is motivated by trying to make the easy thing work well for apps, instead of requiring app authors to sort out these tradeoffs.

Especially with the higher-level API in say glib's dbus support, though, it might be possible to near-automatically put certain objects on dedicated sockets. Just a matter of programming...

Missing the AF_BUS

Posted Jul 6, 2012 6:24 UTC (Fri) by smurf (subscriber, #17840) [Link]

socketpair-ing the sender and recipient would probably work, but it has a few downsides.

* you lose the easy debugging and monitoring you now get with DBus (presumably, with AF_BUS you could use something like wireshark),

* the client now has to juggle multiple file descriptors, that requires an API change

* multiple file descriptors and reliable message ordering don't mix

Too many downsides if you ask me.

Missing the AF_BUS

Posted Jul 6, 2012 6:58 UTC (Fri) by Fowl (subscriber, #65667) [Link]

Surely libdbus could handle this all automatically?

Missing the AF_BUS

Posted Jul 6, 2012 16:18 UTC (Fri) by smurf (subscriber, #17840) [Link]

The multiple-file-descriptors problem is the killer,

dbus_connection_get_unix_fd() returns exactly one file descriptor. If you open a direct connection to some application, you have more than one file descriptor. How do you make your application select()/poll() on both (or more) of these?
Admittedly, on second thought, you could do it with epoll(). But it's still a change in semantics (you can't read from that file descriptor; worse, you can't write to it).

How would you propose to handle the monitoring problem? Let the daemon send a "somebody's listening for messages X, so if you exchange any of those privately, kindly send me a copy" commands to each and every client? Owch.

I'm not saying this cannot be done. I'm saying it's heaps more work, and more fragile, than simply moving the main chunk of this into the kernel, especially since there's already code which does that. And code is more authoritative than English.

Missing the AF_BUS

Posted Jul 6, 2012 17:32 UTC (Fri) by iabervon (subscriber, #722) [Link]

I think I was unclear: I'm not suggesting that DBus do some sort of socketpair thing to provide high-speed dbus links; I'm suggesting that use cases that don't really care about DBus, but need to negotiate with another program for their input, could get back to their normal operation (input from a fd) by having the other side send a fd back when it's all set up. That is, user input doesn't normally go over DBus, so applications are already designed around a non-DBus input path; even if you need IPC to set up your input device appropriately, it doesn't make too much sense to get user input over DBus, particularly if you can't get corresponding user input over DBus if the system doesn't have Chinese input or multi-touch.

Of course, it's certainly possible that people will want high-speed IPC with DBus properties also, and it makes sense for DBus to be efficient regardless of whether it's running into performance constraints. But it doesn't make sense to use DBus for all communication, even if its performance could be made good enough.