demarshalling messages

Dafydd Harries daf at rhydd.org
Thu Mar 22 21:56:25 PDT 2007


Ar 23/03/2007 am 00:27, ysgrifennodd Havoc Pennington:
> Dafydd Harries wrote:
> >I'll try to elaborate. The goal is to allow the OLPC activities to make 
> >D-Bus
> >calls over the network, without having to understand how the D-Bus messages
> >are transmitted.
> 
> This isn't clear to me still - D-Bus already is a way to make calls over 
> the network. So what's the new/different part... what are some examples 
> of "how the messages are transmitted" for example - what details 
> specifically are you trying to hide from the activities?

The messages are transmitted via XMPP, either via a server, or directly to a
peer on the local network (serverless link-local XMPP).

> >Hence my service should act like a normal bus service,
> >listening on a local unix socket, except that messages sent over that 
> >socket
> >are sent to the network, and messages received over that socket have come 
> >over
> >the network.
> >
> >When I receive a message on the local unix socket I need to
> >
> > - validate the sender field in the message header, or add one if it's not
> >   there
> > - extract the destination field in the message header, so I know where to
> >   send it to
> 
> By destination field you mean the field from 
> dbus_message_get_destination() containing a bus name? How would you do 
> routing based on that? What are two concrete examples of the "where" 
> that you would send to, maybe?

That's dependent on the protocol being used. If it's going via the server,
method calls/responses will be directed to an individual Jabber address.
Signals will be broadcast. For link-local connections, messages will be routed
to individual IP addresses. My service is responsible for maintaining a
mapping between D-Bus addresses and transport addresses (JIDs or IP
addresses), using an out-of-bound mechanism.

> >Doing these things entail demarshalling the message, examining it, possibly
> >modifying it, and marshalling it. As far as I can tell, this is not 
> >possible
> >with the current libdbus API.
> 
> What you've described sounds exactly like what dbus-daemon does, and it 
> uses libdbus... basically the DBusConnection demarshals the message 
> stream from a socket (whether TCP or unix domain) and gives you 
> DBusMessage objects, which can be examined and modified; then you can 
> send the modified message objects over another DBusConnection associated 
> with a different socket (TCP or unix).
> 
> But, I have a feeling what you mean is not exactly what dbus-daemon 
> does, so I think I'm still confused ;-)

I understand that I can create a DBusServer, and get DBusConnection objects
for new connections, and I can get DBusMessage objects when clients send me
messages, and I can examine and modify those messages. But I don't see how to

 - get the marshalled form of the DBusMessage so that I can encapsulate it for
   the network transport I'm using

 - take a marshalled message from a network transport I have and turn it into
   a DBusMessage object so that I can send it to my local clients

-- 
Dafydd


More information about the dbus mailing list