Bug 14343

Summary:	Connecting to a D-BUS tube can lose messages
Product:	Telepathy	Reporter:	Ben Schwartz <bens>
Component:	tp-spec	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED INVALID	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium	CC:	alban.crequy, will
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Ben Schwartz 2008-02-02 21:12:40 UTC

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.

Comment 1 Alban Crequy 2008-04-11 03:29:49 UTC

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

Comment 2 Alban Crequy 2008-04-11 07:14:36 UTC

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.

Comment 3 Alban Crequy 2008-04-11 08:45:43 UTC

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

Comment 4 Will Thompson 2009-02-13 16:38:33 UTC

That Gabble branch was merged; so is this spec bug invalid?

Comment 5 Alban Crequy 2009-02-14 00:00:07 UTC

> 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.