[Telepathy] D-Bus tube establishment, and races

[Guillaume Desmottes]

Le jeudi 24 janvier 2008 à 23:43 +0100, Alban Crequy a écrit : 
> Hi,
> 

Hi

> I am trying to understand how an application can use the Connection
> Manager D-Bus API to establish a D-Bus tube without races. Please tell
> me if I am wrong.
> 
> Once the tube channel is requested, the D-Bus tube initiator follows
> theses steps:
> 
> I1- call the method OfferDBusTube(service, parameters) -> tube_id
> I2- call the method GetDBusTubeAddress(tube_id) -> bus_address
> I3- connect to the bus_address.
> 
> On the client side, the application:
> 
> C1- receive the signal NewTube(tube_id, ...)
> C2- call the method AcceptDBusTube(tube_id) -> bus_address
> C3- wait until receiving the signal TubeStateChanged(tube_id, Tube_State_Open)
> C4- connect to the bus_address
> C5- call some methods on the private bus
> 

Looks OK.

> The step C3 is required by the spec: "The client should not attempt to
> connect to the address until the tube is open."
> http://telepathy.freedesktop.org/spec.html
> 
> My fear is that the client start to call some methods on the private
> bus (step C5) before the initiator application is connected to the CM
> socket (step I3). If this happens, the first D-Bus message in the tube
> may be lost because nobody is listening on the other side of the bus.
> 
> I guess the step C3 is supposed to prevent this. But I don't
> understand how it is supposed to work. Is the Connection Manager
> supposed to emit the TubeStateChanged signal with Tube_State_Open on
> the client side (step C3) only after step I3? In this case, does
> current implementations of Gabble, Salut, etc. send a network message
> to the client when an application is connecting to the bus_address
> (step I3)?
> 

No. This C3 is needed when you accept a D-Bus tube in a 1-1 context (so
no in a muc but only with one contact (which is only implemented in
Gabble for now)). In that case when you accept the tube, you reply to
the SI request but the bytestream have still to be negotiated. So you
can't use your tube while we don't have a bytestream established with
the tube initiator. That's why you have to wait for the TubeStateChanged
signal.

When you accept a muc D-Bus tube the TubeStateChanged signal is
immediately fired so you don't have to wait. But that's a consequence of
our current implementation of the muc-bytestream and that could change
so you shouldn't rely on this.

I'm not sure about your race issue. Is that wrong if we connect to a
private D-Bus bus while the initiator isn't connected to it? I'm
wondering if it's not the responsibility of the application using the
tube to be sure there are actually participants in it.
IIRC we send our D-Bus name when we offer or accept the tube (and so
DbusNameChanged is fired on remote clients). Maybe we should send it
only when we have actually joined the tube?


	G.