<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Havoc Pennington wrote: <blockquote cite="mid:2cef5bf40806021300t7b89411dwe81197b9671c8b80@mail.gmail.com" type="cite"> <pre wrap="">Hi, I don't know the answers on dbus-glib but some partial answers - </pre> </blockquote> Thanks Havoc, really appreciate it. I guess the Glib stuff needs a proper GObject to interact with, although I'm still not sure how to use (or even if it's possible) the Glib bindings to do add a dbus signal mask. <blockquote cite="mid:2cef5bf40806021300t7b89411dwe81197b9671c8b80@mail.gmail.com" type="cite"> <pre wrap="">On Mon, Jun 2, 2008 at 12:01 AM, João Valverde <a class="moz-txt-link-rfc2396E" href="mailto:backup95@netcabo.pt"><backup95@netcabo.pt></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">auto generates some signal for that or what. Maybe I need to keep two proxies for that, one to the bus and the other to the daemon? And what are the signal names that I should connect to? All I see using dbus-monitor is "NameOwnerChanged", even when my daemon dies. If I only allow a single daemon instance to run and accept replacement, there are situations where I don't care if the name owner changes (reloading a config file without downtime for example)... </pre> </blockquote> <pre wrap=""> NameOwnerChanged is the correct way to track when other processes come and go. Just ignore any changes you don't care about. </pre> </blockquote> I'm slowly getting up to speed on dbus and I figured out how to use "NameOwnerChanged" to track process lifecycle through a well-know name. I already have some code that works beautifully using the low level API. After messing around with inotify to do this and having to work around a lot of corner cases dbus is a joy to work with. <blockquote cite="mid:2cef5bf40806021300t7b89411dwe81197b9671c8b80@mail.gmail.com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">I would also like to ask if it's considered good practice to indiscriminately broadcast events to the system bus, even if no one is listening (my daemon could potentially generate a lot of traffic...) or whether I should set up a one-on-one connection? Maybe do a handshake over the system bus and then set up a peer to peer connection? </pre> </blockquote> <pre wrap=""> The bus daemon will do a good job of only sending messages to clients that care about them. If there are no interested clients, then the messages will just be dropped by the daemon. So, as long as you aren't shoveling huge hunks of data around, the one-to-one connection is definitely not worth it. </pre> </blockquote> Great, that really reduces my workload. My project is a GUI for a daemon. The daemon broadcasts dropped netfilter packets, but since it only cares about connection establishment I think the traffic load should be fine. The signal payload is a name string, ip address as an uint32_t and maybe a timestamp and some other details. My question now is which bus to use. The system bus is heavily locked down security wise and I don't think that's the proper channel for this job. Since this is a daemon running under root, and the GUI runs with user privileges, I think the correct procedure is to use the user session bus to feed the GUI with signals, but how do I connect the daemon (whose session bus belongs to the root account?) with the user session bus? The daemon should be able to run automatically from init.d. Sorry if this is a pretty basic question but I'm pretty stumped. Regards, João Valverde   </body> </html>