[Standards] Proposed XMPP Extension: Stanza Repeaters

Philipp Hancke fippo at goodadvice.pages.de
Thu Mar 20 19:29:43 UTC 2008

Joe Hildebrand wrote:
> On Mar 18, 2008, at 4:25 PM, Pedro Melo wrote:
>> The repeaters concept doesn't solve the privacy list interactions either.
> Why not?  For each list of folks that a server wants to send presence 
> to, it creates a list.  If that list has different people on it for 
> different reasons, it creates different lists.  In the case of presence, 
> the server could, in the face of privacy lists being turned on, create a 
> presence-out list and a presence-probe list for the user in question at 
> each site where you have more than N users, where N should be determined 
> through some sort of analysis at where the trade-off point is.  I'm 
> betting it's at least 10.

I did a quick+dirty calculation with scenario 5.1 from the presence
scaling analyis draft.
I neglected list creation, deletion and all that stuff, simply setting
I1 to 1 instead of C3 (and tweaking I2, I3, I4, I5 and I6 accordingly)
and increased the stanza size by 180 bytes to account for the wrapper
(C7 = 280, C8 = 480).

But while writing a script to calculate those numbers I found an
interesting claim in the draft:
(S2) Number of outbound presence notifications = (S1*C4).
(T1) Number of unavailable presence notifications = 1 per online contact
Why are those restricted to 'online contacts'? As far as I can see, RFC
3920 says
"in which case the server to which the entity is connected SHOULD
  broadcast or multiplex that stanza to all subscribing entities."
I don't see any "online" in there.

Hence I've changed some formulas, mainly
S2 = S1 * I1 (whereas I1 is equal to C3)
T1 = C3, T2 = T1*C9 (both mean: one per _federated_ contact)
and rerun the script. This increased B4 to 580000000 for the "standard"
behaviour of xmpp, which is significant increase over the amount claimed
in the ID.

Repeaters score lower, 251200000, mainly due to S2 = S1 instead of
S2 = I1*S1. I8 is 1720 (this is where the main overhead needs to be
added for repeaters), S3 10560.

The old "smart presence" is even lower - even when adding a 40 byte
hash (+xml grudge) we can get away with additional hundred byte/stanza
instead of 180 (piggybacking) . 197200000 for that, also neglecting
list creation. There it is probably even cheaper (in terms of network
traffic) than repeaters.

Regardless of protocol details, the concept of remote fan-out using
lists stored on the remote side is superior to the "current" way of
doing things.


More information about the Standards mailing list