[Standards] synchronized rosters (was: Re: Proposed XMPP Extension: Stanza Repeaters)
fippo at goodadvice.pages.de
Wed Mar 19 20:07:17 UTC 2008
Pedro Melo wrote:
> On Mar 18, 2008, at 3:31 PM, Philipp Hancke wrote:
>> Peter Saint-Andre wrote:
>>>> The roster at the remote host could be used as the distribution
>>>> list, no
>>>> need for costly updates. Just reverse-query the roster if your DB
>>>> provides that (easy for SQL-based rosters, not as simple for LDAP-based
>>> Rosters can get out of sync. The roster at the remote host is not
>>> necessarily to be trusted.
>> How is keeping the roster in sync more difficult than keeping the
>> list at the repeater in sync?
> And to keep the roster in sync, there is already a nice <presence
> type="probe">. The replies of those can include remote subscription
> status that we can compare to our local information to detect
Do you send a single probe to the remote domain and the remote
domain replies with presence and subscription status for each
What I dislike about this is that the overhead grows with number of
subscribers. For calculations let's assume 30 (?) additional bytes in
each probe reply, I5 in the presence scaling analysis.
The benefit is that you precisely know which elements are desync and
resync should be quite cheap therefore.
If the sender attaches a hash (generated like in the repeater proposal,
calculated each time that part of your roster affecting the remote
server changes) to each 'presence broadcast' this is independent from
the number of subscribers on the remote domain. This scales badly if the
number of presence changes is high.
Let's assume 60 additional bytes (sha1+xml stuff) overhead in C8.
The cost of resyncing is considerably higher, as you don't know which
elements have changed.
What is making the comparison difficult: how often does a desync happen?
I've never seen a desync on our chatroom and their equally distributed
memberlists, so I assume it happens rarely. Once a week? Once a month?
> Maybe this should be another thread.
subject changed accordingly
More information about the Standards