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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
