Bug 23630 - Per-connection resource randomization increases the window in which you lose messages
Summary: Per-connection resource randomization increases the window in which you lose ...
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Will Thompson
QA Contact: Telepathy bugs list
URL: http://git.collabora.co.uk/?p=user/wj...
Whiteboard: review+
Keywords: patch
Depends on:
Blocks:
 
Reported: 2009-09-01 11:23 UTC by Will Thompson
Modified: 2009-11-09 03:33 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Will Thompson 2009-09-01 11:23:57 UTC
XMPP messages don't have explicit acknowledgment of message receipt. If you're sending me messages, and I fall offline without telling my server in advance, the messages are lost until the server realizes I'm offline.

Gabble (and other clients) prefer to send messages to the most recent resource that sent us a message.

Suppose I'm talking to you, with resource wjt@example.com/Foo. When my connection unexpectedly breaks, messages are unavoidably lost. But when I sign back in, if I re-use the resource 'Foo', this will (with most servers) replace the previous connection on the server, and subsequent messages will reach me. On the other hand, if Gabble randomizes the resource on connection (as it currently does if you don't explicitly specify one) and I sign in as wjt@example.com/Bar, I'll lose all the messages from you until my server notices that /Foo is dead (which might be tens of minutes), or your client decides to send messages to /Bar instead (because I send you a message, for instance).

So, we should not randomize the resource on every connection, because it exacerbates the problem. Instead, we should generate a resource based on DBus's local machine ID. This would mean that users can still connect from two Telepathy-powered devices without having to know about changing their resource, but means that if your internet connection flakes out (maybe you've got into a taxi, and your laptop loses the wireless and goes over to 3G) then you'll reclaim your old resource.
Comment 1 Will Thompson 2009-09-01 11:28:52 UTC
Gabble should also probably forget the most-recent-sender resource when a resource appears or disappears for a contact, to avoid this situation:

* You're talking to me on my desktop.
* I walk out of the house, leaving it connected, and sign in on my internet tablet.
* Your messages keep going to the desktop.

(Of course, if the tablet is already signed in when I leave the house, this won't help. Maybe we should also drop the binding when a resource becomes more away than others...)
Comment 2 Will Thompson 2009-10-20 09:51:33 UTC
Patch in my branch 'stable-resource'.
Comment 3 Simon McVittie 2009-10-21 09:38:55 UTC
> +  /* 32 bytes of hex. The first 8 should be unique enough... */
> +  return g_strndup (local_machine_id, 8);

This assumes that the machine ID is uniformly pseudo-random, and therefore any byte is as good as any other, but the D-Bus spec doesn't guarantee that. It does note that:

> To generate a UUID, the current reference implementation concatenates 96
> bits of random data followed by the 32-bit time in seconds since the UNIX
> epoch (in big endian byte order). 

So, in fact your assumption is right for libdbus, but it needn't be. Perhaps we should hash the machine ID and use that, in order to mix the pseudo-random and deterministic parts; also, perhaps telepathy-glib should grow a utility function to do this?

(IMO libdbus should hash the random number and the time with a 128-bit algorithm of its choice, and use *that* as the machine ID, and the D-Bus specification should say that the machine ID is uniformly pseudo-random. However, it doesn't.)
Comment 4 Will Thompson 2009-10-22 04:36:37 UTC
(In reply to comment #3)
> > +  /* 32 bytes of hex. The first 8 should be unique enough... */
> > +  return g_strndup (local_machine_id, 8);
> 
> This assumes that the machine ID is uniformly pseudo-random, and therefore any
> byte is as good as any other, but the D-Bus spec doesn't guarantee that. It
> does note that:
> 
> > To generate a UUID, the current reference implementation concatenates 96
> > bits of random data followed by the 32-bit time in seconds since the UNIX
> > epoch (in big endian byte order). 
> 
> So, in fact your assumption is right for libdbus, but it needn't be. Perhaps we
> should hash the machine ID and use that, in order to mix the pseudo-random and
> deterministic parts; also, perhaps telepathy-glib should grow a utility
> function to do this?

http://dbus.freedesktop.org/doc/dbus-specification.html#uuids:

> Implementations should, however, stick to random data for the first 96 bits of the UUID. 

But okay, whatever, branch updated.
Comment 5 Simon McVittie 2009-10-22 11:24:33 UTC
++
Comment 6 Will Thompson 2009-11-09 03:33:28 UTC
Merged to master and 0.8; will be in 0.9.3 and 0.8.8, respectively.

commit bd6522afe807be0f8c2a57ed9fbc47a989cfef45
Merge: b45e8ba 9f690c0
Author: Will Thompson <will.thompson@collabora.co.uk>
Date:   Mon Nov 9 11:32:15 2009 +0000

    Merge branch 'stable-resource-0.9'
    
    Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

commit edf6f8f6486ee9d44e4e9602ae2a56ae38780a87
Merge: 453fe6c 07d1195
Author: Will Thompson <will.thompson@collabora.co.uk>
Date:   Mon Nov 9 11:03:14 2009 +0000

    Merge branch 'stable-resource' into telepathy-gabble-0.8
    
    Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>


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.