When connecting a D-Bus tube, one first Accepts the tube. This causes the user to appear as having joined the tube. Once this is done, the user can then make a TubeConnection and use it to listen to signals and method-calls. This is racy. If I see another user appear in the tube, and send a message to that user in response to joining, it is possible for that message to arrive before the user is ready. For example, if a signal arrives before the matching signal receiver has been registered, then the message will simply disappear. This violates Telepathy's philosophy of causality. To ensure that messages are never lost, perhaps there must be a sort of two-phase join. Initially, after the user joins, all messages could be queued. Once the user has added all relevant signal receivers and remote methods, then the user should disable queuing. Alternatively, the user could be marked as present in a second step, after registering all local objects. In this case, outbound messages must be queued until the user has joined.
I have this bug sometimes in 1-1 D-Bus tubes in Gabble on the initiator side: ** (telepathy-gabble:3817): DEBUG: data_received_cb: Received 174 bytes, so we now have 174 bytes in reassembly buffer ** (telepathy-gabble:3817): DEBUG: data_received_cb: We need 174 bytes for the next full message ** (telepathy-gabble:3817): DEBUG: data_received_cb: Received complete D-Bus message of size 174 ** (telepathy-gabble:3817): DEBUG: message_received: no D-Bus connection
There is 2 different races here. 1. The program is connected to the D-Bus tube but it has not registered its objects so it is not ready for handling method calls. This is a bug in the program and there is no need to change the tp spec nor the Connection Manager implementation. See Bug #14877 for an example of such kind of bug. 2. The tube is open but the program is not yet connected to the D-Bus tube and the Connection Manager has already a message to deliver. The message is lost because no program is connected on the D-Bus address of the Connection Manager. This is the example I wrote in my Comment #1. To resolve the 2nd race, I would follow your suggestion: queueing messages until the program is connected to the D-Bus address of the Connection Manager. I think we don't need any additional signalisation in the Telepathy D-Bus spec: the Connection Manager knows when the program connects to its D-Bus socket. And only one connection at a time is allowed on this D-Bus socket. So, as soon as a program connects to the socket, we can deliver the messages from the queue and we don't need the queue anymore.
Fix: http://monkey.collabora.co.uk/telepathy-gabble-alban-bug14343/ I have theses logs: DEBUG: data_received_cb: Received 174 bytes, so we now have 174 bytes in reassembly buffer DEBUG: data_received_cb: We need 174 bytes for the next full message DEBUG: data_received_cb: Received complete D-Bus message of size 174 DEBUG: message_received: deliver message from ':1.0' to ':1.1' DEBUG: message_received: no D-Bus connection: queue the message DEBUG: new_connection_cb: got connection DEBUG: new_connection_cb: 1 messages in the queue DEBUG: new_connection_cb: deliver queued message from ':1.0' to ':1.1' on the new connection
That Gabble branch was merged; so is this spec bug invalid?
> That Gabble branch was merged; so is this spec bug invalid? Yes
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.