CODEWITHSUNDEEP
embedded-linuxdbus
user3693586
user3693586

Reputation: 1287

D-bus connection name and object path

I have started understanding D-bus. I have couple of doubhts related to D-bus connection name(dbus_bus_request_name) and Object path(dbus_connection_register_object_path) registration.

  1. We can register multiple object paths with the same name?

  2. Is registering a name for the D-bus connection mandatory?

    i.e. registering only the object path is enough?

Upvotes: 0

Views: 1000

Answers (2)

grawity_u1686
grawity_u1686

Reputation: 16572

Bus names are how clients discover your service. They are not associated with any specific object – it's the entire bus connection that has the name associated with it.

It's possible to make a very close analogy between Internet and D-Bus:

  • All hosts have an IP address; all processes connected to the bus have a "unique name" dynamically assigned (which looks like ":1.2345").

  • Unique names are kind of like dynamic IP addresses; well-known names are kind of like domain names. Clients don't need a well-known name, but servers ought to have one, otherwise clients won't know how to contact the server.

  • Object paths are kind of like HTTP URL paths; 'method call' messages are kind of like HTTP POST requests to a specific path.

  • The bus (or the network) doesn't keep track of object paths at all – it only delivers messages to a specific bus name (or IP address), and it's the service's own responsibility to handle object paths.

We can register multiple object paths with same name?

A service can register as many objects as it wants. In fact, objects are entirely client-side; the bus does not keep track of them at all – it only keeps track of service names.

(And much like webapps can have dynamic URL paths, D-Bus services can have dynamic object paths as well.)

Registering name to the D-bus connection is mandatory? i.e registering only object path is enough?

As mentioned before, the bus does not keep track of object paths – when you "register" an object that's just stored by libdbus so that it knows what to do with messages it receives. There is no global mapping of which objects are owned by which service.

Because of that, it is not possible to send a bus message to only an object path – you must specify the destination service name – therefore it's very useful to register a service name so that clients would be able to find your service easily.

Upvotes: 1

idle_roamer
idle_roamer

Reputation: 51

Every time a peer connects to a dbus message bus daemon (dbus-daemon the most famous implementation), a unique name is assigned to the connection by the daemon. There is no limit on number of connections a peer can make.

Default connection's unique names are no good for peers that would expose API, as the name is random and therefore not navigable. Therefore additional known names need to be requested via dbus_bus_request_name. Obviously client peers do not require known names.

One basic thing needs to be established here, dbus exchanges messages between connections and as far as it is concerned a message has a sender and a receiver, though additional info of the message like object_path and interface_name though required by receiver to handle the request properly, to daemon are irrelevant.

Each object may implement different interfaces, among others there are standard interfaces like introspection which helps other peers to discover what objects and interfaces are exposed by each peer.

From this point onward it is more intuitive, each interface can have methods, signals and properties like many OO language.

Upvotes: 1

Related Questions