-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Service name tracking is setup multiple times #55
Comments
mardy
added a commit
to mardy/xdg-dbus-proxy
that referenced
this issue
Mar 28, 2024
Since all clients connecting to the proxy share the same policy filters, we can setup the name owner data just once, when the first client connects, and store it in the FlatpakProxy object so that all other clients can use it. This avoid duplicating the calls to ListNames and GetNameOwner. Fixes: flatpak#55
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
ListNames
followed by several calls toGetNameOwner
andAddMatch
-- 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 theget_owner_reply
and theunique_id_owned_names
tables) but I wonder if you are aware of any hidden dragons there.The text was updated successfully, but these errors were encountered: