Re: Compatibility between D-Bus and kdbus
Philip Van Hoof <[email protected]>
| Newsgroups | gmane.comp.sysutils.systemd.devel,gmane.comp.freedesktop.dbus |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/10/2014 15:33, Simon McVittie wrote: [cut] > Resource limits =============== > > Some resource limits are lower in kdbus than in dbus-daemon. > > In kdbus, the number of unread messages per recipient is limited to > 256, with up to 16 per uid; subsequent broadcasts are silently > dropped, and subsequent unicast messages cause the sender to > block. > > The message header (fixed-length header and header fields) is > limited to 2 MiB in kdbus, whereas on dbus-daemon it may be up to a > configurable limit, by default 32 MiB for the system bus or 128 MiB > for the session bus. Broadcast messages (header + body) have the > same 2 MiB limit, but unicast message bodies may be any size: kdbus > itself does not impose any limit. I don't know whether anything > sends broadcasts as large as 2 MiB (Tracker perhaps?): if you do, > please share. Tracker's GraphUpdated will 'compress' its payload by sending numerical ID's that represent the graph, resource, property and sometimes value to signal inserts and deletes on a graph. It has two triggers to invoke it (which also flushes it) When the amount of events is larger than a certain number: https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n25 https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n312 And timer based as configured as graphupdated_delay (dconf config): https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n297 Some more explanation here: http://pvanhoof.be/blog/index.php/2010/08/24/trackers-new-class-signal-system-being-developed Of greater concern is an API which I always considered to be for debugging purposes only. That's the Query API on Resources1 of Tracker: libtracker-sparql will not ever use it, the library will either use a direct connection with sqlite's meta.db using WAL journaling for read queries, or fall back to using FD passing with as you mentioned in your mail pipe() and vmsplice(). That's the Steroids1 D-Bus interface of Tracker's SPARQL endpoint. Although I consider the Query API on Resources1 to be a private or debug D-Bus API, it can indeed cause a very large DBusMessage. This was once put in place to guard ourselves against it: https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n50 https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n111 Some explanation here: https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n27 [cut] > Comments, corrections? (To the dbus list, please.) Kind regards, Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJUSCi9AAoJEEP2NSGEz4aDDKEH/RDRuIHtmUljzdYX7XQqGA6N I/0DAaCHRCg0D2az9MbzgEnrFrvVmhACtGrFcWA15hfasNadcCmPnIBRJk84WOld rELimMayQ8wyCsKlCBszoAjQKVe4Qr5KVw3zVNBTPvfs6xsqdeGFSaNbFDrrCZtC 5SmwnlI9ezenJ3+EjAbTqPUDi7rMciA4BvDWI0HSa4TQD/ggtnHnVyikff6POPX7 BQcHp65vBSCvz+mwVPUawTI04l3MC8UXzMOYw/I+UduESnptbD7ZyJ0GzUY7rxxI Se/Et+ijSBCdvb3cuBnDk14kZ+slJFEBrYLsukZVdQ8hqzm1NmU0/XBsMK3eN+c= =GA7y -----END PGP SIGNATURE-----