[Standards] Inconsistent Subscriptions in XMPP
pavlix at pavlix.net
Wed Feb 25 23:38:09 UTC 2009
On Thu, 26 Feb 2009 00:15:18 +0100
Robin Redeker <elmex at x-paste.de> wrote:
> On Tue, Feb 24, 2009 at 01:49:50AM +0100, Pavel Simerda wrote:
> > There are several cases when subscription databases in XMPP are
> > inconsistent.
> > You may view subscription information as a global distributed
> > database. Subscription state between two JIDs, for example a at A and
> > b at B are stored in two places at the same time. Servers A and B
> > maintain their own copies of subscription state.
> The problem is not just subscription state, but any state that is
> not synchronized, basic presence information comes to mind, they also
> get out of sync sometimes. Maybe it's less of a problem, because a
> client logging in again, can refresh that state.
Ah, thanks for pointing out.
> Subscription information of course isn't as easily 'synchronized'.
Not so easily, but it's possible... as in most situations, you mostly
know you've screwed it up...
And you must write all your contacts to delete you and add back. That
If at least these scenarios were caught and the servers would
synchronize upon your communication. You write Alice, Alice writes
you... and by that time the servers would synchronize.
The same could work for presences... and repeated request... so if you
screw up the server... you would just let it send subscription requests
for all contacts and then the servers would detect and fix all
Other scenarios might come in hand.
> I don't know whether servers already do this, but having a consistent
> state for presence, would allow for caching the presence information
> on the receiving server.
> A generic synchronisation protocol would of course help any
> state information that has to be shared with other servers.
Hmm, not sure if generic or specific, but I would like to see some.
> I brought this topic up some weeks ago (and I think also a year ago),
Then bring it again, please :).
> but I'm not a server developer (If I was, I would probably have
> already implemented some proof of concept protocol to do this). But
> these things don't seem to bother the (and/or developers)
They're lazy (everybody is).
> users much
> and there doesn't seem to be much (or enough) interest for consistent
> information sharing amog servers.
It shouldn't be too complicated. We should prefer a nice and easy way
to go. You probably that a review of the core protocols is underway.
Maybe we can have a chat on Jabber?
Freelance consultant and trainer
in networking, communications and security.
Jabber, Mail: pavlix(at)pavlix.net
More information about the Standards