about the D-Bus C API.

[John (J5) Palmieri]

On Tue, 2007-11-13 at 09:34 +0100, Thiago Macieira wrote:
> Em Tuesday 13 November 2007 08:56:15 Wang Jun escreveu:
> > Hi Thiago Macieira,
> >
> > Thank you for your reply. but I kind of find exception to
> > what you said. check below.
> 
> Please reply to the list. If you mail me directly, I might ignore the message 
> because I don't know the answer (or am busy), but other people may be able to 
> answer.
> 
> > On Tue, 2007-11-13 at 08:20 +0100, Thiago Macieira wrote:
> > > Wang Jun wrote:
> > > >I am using D-Bus C API. Is it possible to make sure the well known names
> > > >are returned when dbus_message_get_sender(msg)
> > > >and dbus_message_get_destination(msg) are called?
> > >
> > > No.
> > >
> > > get_sender ALWAYS returns the unique name.
> > >
> > > get_destination returns what the sender chose. It can be either a unique
> > > or a well-known name.
> >
> > can you give a bit more elaboration on this?
> 
> Yes.
> 
> The sender is set by the bus daemon. It always sets to the unique name. 
> Therefore, get_sender always returns a unique name.
> 
> As for the destination, it's set by the sender, so it's what the sender chose 
> it to be. If it set the destination to a unique name, you get a unique name. 
> If it set the destination to a well-known name, you get a well-known name.

We might even kick you off the bus if you try to forge the destination.
I know at some point this call was rewritten by the bus and was only
useful for direct connections (the bus may check if you are indeed the
owner of said well known names these days).  As for getting well known
names that is not really how D-Bus is designed.  Well known names are
simply mappings to make services on the bus easy to find.  How does the
bus know which well known name sent the message if a process owns
multiple names?  Routing of messages within a process is done via the
object paths and interfaces.

> > > >Currently, I am not using any matching rule for listening on dbus as
> > > >I want to catch both method_calls and signals. So I use the
> > > >  dbus_message_get_sender(msg) to check the sender and then call
> > > >the relevant subroutines. But the function returns unique names
> > > >instead of well known name...
> > >
> > > That paragraph doesn't make sense. Without a matching rule, you don't
> > > receive the message in the first place.
> >
> > actually I am not familiar with the C implementation inside in dBus.
> > But My program does be able to receive both SIGNAL and METHOD_CALLS
> > without specifying any addMatch..
> 
> I guess that the dbus-daemon has some implicit rules, then. But you should not 
> be receiving signals without an add match rule.
> 
> Someone else may be able to clarify the behaviour of the daemon in case there 
> aren't any rules set.

Certain signals like disconnect will get through but ya in order for
D-Bus not to wake up an application all the time (very bad for battery
life on laptops) you will not receive signal without match rules.

> > currently I dispatch the call based on interface, path, name..
> > But cannot based on SENDER and DESTINATION due to the problem I
> > mentioned
> 
> You don't want to dispatch based on sender and destination.
> 
> If the destination is set (i.e., method calls), then the destination is you 
> because you received the message in the first place. Therefore, you don't 
> need to check if the destination is you. You should handle all messages 
> equally.

Well you can handle a table of clients and give different responses
based on who made the call.  This is usually done via a UID handshake or
creating a new object path for each instance you wish to keep track of.
Creating new instances is the best.  You could have a method which looks
like New(out obj_path) which clients call to get their object path.
They would then call on that object path.  The service would keep tack
of the client's unique name and 'unref' the object when it got a
NameOwnerChanged signal for the client from the bus.

One thing to note is D-Bus is not an object model - it is a IPC/RPC
mechanism with an object oriented paradigm.  This means while we use
object oriented constructs to describe D-Bus messages the protocol is
inherently stateless.  It is up to the service (or client) to maintain
state and be able to modify behavior of calls based on previous calls.

> If the destination isn't set, it's a signal.
> 
> As for the sender, you shouldn't treat messages differently based on the 
> sender. You should treat all senders equally.

-- 
John (J5) Palmieri <johnp at redhat.com>