I was looking at the D-Bus traffic and I noticed that in AuroraOS (which uses xdg-dbus-proxy via firejail) when an application starts up there is a call to ListNames followed by several calls to GetNameOwner and AddMatch -- and this pattern is repeated twice.
After some investigation, I think I know why this happens: whenever a client connects to the xdg-dbus-proxy socket, the proxy makes a ListNames call right after the client has authenticated, and then starts monitoring the services that the client is interested in (according to the filters).
It seems to me, though, that this is not optimal when there are more clients connected to the same proxy (actually in our case the client process is probably just the same one, but it opens different connections -- probably because it's using both Qt and glib implementations of D-Bus, but I haven't investigated this yet), because the filter rules are the same for all clients, so the tracking of the service names should be common, and it could be setup just once.
Please let me know if my current understanding is correct, and what are the options to address this issue; my first thought would be to move this logic to the FlatpakProxy class (including the get_owner_reply and the unique_id_owned_names tables) but I wonder if you are aware of any hidden dragons there.
Hi there :-)
I was looking at the D-Bus traffic and I noticed that in AuroraOS (which uses xdg-dbus-proxy via firejail) when an application starts up there is a call to
ListNamesfollowed by several calls toGetNameOwnerandAddMatch-- and this pattern is repeated twice.After some investigation, I think I know why this happens: whenever a client connects to the xdg-dbus-proxy socket, the proxy makes a
ListNamescall right after the client has authenticated, and then starts monitoring the services that the client is interested in (according to the filters).It seems to me, though, that this is not optimal when there are more clients connected to the same proxy (actually in our case the client process is probably just the same one, but it opens different connections -- probably because it's using both Qt and glib implementations of D-Bus, but I haven't investigated this yet), because the filter rules are the same for all clients, so the tracking of the service names should be common, and it could be setup just once.
Please let me know if my current understanding is correct, and what are the options to address this issue; my first thought would be to move this logic to the
FlatpakProxyclass (including theget_owner_replyand theunique_id_owned_namestables) but I wonder if you are aware of any hidden dragons there.