[Standards] Proposed XMPP Extension: Roster Versioning

Dave Cridland dave at cridland.net
Mon Mar 10 22:20:01 UTC 2008


On Mon Mar 10 21:55:33 2008, Peter Saint-Andre wrote:
> Dave Cridland wrote:
> > On Mon Mar 10 20:17:53 2008, Joe Hildebrand wrote:
> >> - If the roster has been completely deleted, the response would  
> be >> empty, but have version 0
> > > I've a diff for specifying a sequence validity, which changes  
> when the
> > roster is effectively a new one. (So it'll change if the account  
> is
> > deleted and recreated, and it'll change if the server is restored  
> from
> > backup, and it'll change if the server simply can't really be  
> bothered
> > to use any kind of useful sequence, and instead changes it on  
> every
> > change).
> 
> Joe's suggestion works for me here, but I confess that I don't
> understand the concept of a sequence validity marker.
> 
> 
If we did things Joe's way, then the server would have to know  
whether the roster had been destroyed and recreated since the client  
asked last. And that involves telepathy, I think.

Instead, we push this to the client. Servers just plonk an arbitrary  
splodge (note the extremely technical language) on a roster when it's  
created, and they tell the client what it is at the beginning of a  
session.

Now, if the client sees that the spodge the server says is different  
from the one they saw last, they know their cache is now useless, and  
can discard it, and start from scratch.

This is useful if:

a) The server has to be restored from backup, and so clients may be  
out of sync. The SysAdmin now just pushes the button that says  
"invalidate all sequences". Or maybe the server can tell. (By storing  
these on a persistent, but not backed up, medium).

b) The server doesn't really have sequences at all. In this instance,  
it pretends to have a sequence for the duration of the session, but  
it presents some hash of the roster's contents as the roster validity  
splodge. No changes? No worries. Changes? Cast aside thy cache,  
little client, and I shall bestow upon thee a new roster.

c) The account has been deleted and recreated, and so the new roster  
is no relation at all of the one the client has cached.

d) The heat death of the universe has been and gone, and the 256-bit  
sequence finally rolls over on the roster of Saint Peter Saint-Andre  
(formally canonized by the temple of XMPP, now the state religion of  
the universe).

> I pondered that for a while before settling on the diff. My main  
> concern
> with the roster-push-only model is that there could be an awful lot  
> of
> roster pushes, each of which (1) has TCP and IQ overhead associated  
> with
> it and (2) needs to be acked by the client per RFC 3920 (but in  
> practice
> not all clients do this). But if there would be lots of roster  
> pushes
> (where "lots" is defined by that smart server to which your dumb  
> client
> is connected) then the server could send you the complete roster,  
> right?

Joe and I pondered some more.

The TCP overhead is largely lost by pipelining - the server knows how  
many pushes it needs to send, so that's one TCP packet, one ACK.

The IQ responses can be gotten rid of by sending these - and all -  
roster pushes as message stanzas instead. So, if your client uses  
XEP-0237, you're implicitly telling the server to send you roster  
pushes as <message/> stanzas. Now clients can legally not respond to  
roster push iq's, because they're not iq's anymore. Hoorah!

We can get rid of per-push stanza wrapping overhead by allowing  
multiple items per push, too.

Now what we have is that when you ask for your roster, you get a  
single <message/> based push containing all items, or else you get  
your iq result with the replacement roster. Hardly any overhead at  
all, now.

Given that we're now handling multiple pushes, it seems fair to go a  
step further, and allow clients to have multiple items in a roster  
set. I still think it'd be nice to go the final step and allow  
clients to specify a sequence value here to allow for lockless atomic  
sets, too.

I'll write some text. :-)

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list