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