[patch] direct service connections

[Colin Walters]

On Sun, 2004-10-31 at 17:50 -0500, Havoc Pennington wrote:
> On Sun, 2004-10-31 at 14:44 -0500, Colin Walters wrote:
> > Attached is a simple patch which adds a new method,
> > dbus_bus_connect_service_direct; this method returns a new
> > DBusConnection.  The remote service has to implement a special
> > org.freedesktop.DBus.Service method,
> > org.freedesktop.DBus.Service.GetDirectConnection, that returns
> > the address of the service.
> 
> An issue here is that you seem to imply semantics that a service[1] will
> expose the same objects and interfaces on all connections. But that
> isn't how it currently works; the object tree is per-connection. So you
> can't get separate "direct connection" and "via bus connection" to the
> same objects.

I was only thinking of speed/security uses for this.  When would you
actually want to expose separate object trees on different connections?

> I think the elegant (but not necessarily right) approach here is to
> imagine that libdbus or the binding library automatically manages
> DBusConnection (file descriptors), and the app developer asks for
> objects (DBusGProxy or equivalent) without specifying the connection.

At the binding level, I agree.

> One way this could work internally is that when you activate a service
> on the bus, the bus could "redirect" (like http redirect) to an address
> for direct connection. The app would then establish a new connection to
> that address if it doesn't already have one, and instantiate the object
> proxy.

Hmm.  And whether or not the bus would do the redirect thing would be a
flag in the .desktop file or something?

I'm not sure how your suggestion would be different at the libdbus API
level though.  You'd need to return a new DBusConnection object somehow
when the bus wants to do a redirect.  Also the implications with auto-
activation seem unclear.

> There are a host of complexities, though. A simple one, an address isn't
> a unique identifier for a remote process; we might need some sort of
> guid made up by each process that's used to decide whether a new
> DBusConnection has to be opened and potentially also to avoid a race
> (redirecting process is replaced by another process at same address).

I didn't understand this at first, but then I got to the end of the
message and it made sense.  Replied there.

> A harder one is that we probably have to split the object tree from the
> connection objects. So e.g. signals would go out over all connections
> using that object tree. Method calls would only go out over one
> connection though. Exactly how all this works is pretty complicated.
> 
> Location independence is something DCOP has lived without, though I know
> some people have been unhappy with that - IIRC said people were even
> doing something similar to what you are, i.e. transferring image data.

Really?  Does anyone have a reference for that?  Google didn't give me
any pointers from a quick search.

> Maybe a simple solution along the lines of yours would be to request a
> direct redirect for *a specific object*, so something like:

And then the bindings level would ensure that only messages to that
object are routed over the direct connection?  I guess that makes sense,
because then you don't have to take the reliability tradeoff for any
other objects exposed by that service.

> Another line of thought on this issue is how to make the current D-BUS
> address into the equivalent of an IOR (object reference). The idea being
> that you could pass around in string form the full instructions for
> accessing an *object* (not just a process). That would then be the
> natural return value for the above RequestRedirect.

Hm.  And would application developers (who are using bindings) be aware
of IORs?  I don't see, in this case, why they would need to be.  What do
they buy us?

> Here's another line of questioning:
>  - say imsep starts up and owns org.fd.Imsep on the bus
>  - you contact org.fd.Imsep and it refers you to an alternate IOR
>  - you thus connect to the Imsep process directly
>  - the process loses the org.fd.Imsep service on the bus
>    and is replaced by another process owning the service
>  - what happens to the direct connection?

Yes, I think this is a tradeoff that you get with direct connections;
you lose the reliable service tracking and message routing that the bus
does.  I think that it probably isn't bad to just have the direct
connection stay around if it hasn't been closed, and an app can continue
using it.  In the important cases such as when the remote app crashes,
*all* connections to get closed, and so the app/libdbus can notice that
and re-request a direct connection.

> [1] note here by service you mean process/application, not what dbus
> actually calls a service 

Hm, yes, I guess you're right.  It probably isn't useful to have two or
more open direct connections to the same process.  But on the other
hand, it doesn't seem common for an application to own more than one
service; would this be a problem in practice?

On the other other hand, an application might want to explicitly use
separate sockets (DBusServer) for each service - this allows one to have
distinct OS-level access controls on the particular sockets.  Not sure
if that'd be useful in practice though.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://freedesktop.org/pipermail/dbus/attachments/20041031/431339a0/attachment.pgp