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 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)? -- Alban Crequy _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
