[Standards] Proposed XMPP Extension: Stanza Repeaters

Philipp Hancke fippo at goodadvice.pages.de
Fri Mar 21 20:15:09 UTC 2008


Peter Saint-Andre schrieb:
>> Interesting optimization - as far as the traffic savings are concerned.
>> Yet it breaks invisible (at least): it makes the sender appear online to
>>  the other side indefinitely.
> 
> Invisible is broken anyway. 

yai.

> And which version of invisible are you talking about? 

The scenario where the remote contact is online when you send
the probe, but does not respond (blocked outbound presence).
Then he receives your initial presence, but never receives updates
(S2*C4) or the terminating presence stanza.

> And no it doesn't break that, because the server sends
> unavailable when you go invisible.
>>> many server implementations perform.
>> Which ones? I've just tested jabberd14 and ejabberd and neither of
>> those stops sending me presence updates or unavailable.
>>
>>> Perhaps it is not clearly described in RFC 3921 or rfc3921bis.
>> Could you point to to the paragraph where it is described at all?
>> 5.1.1, 5.1.2 and 5.1.5 only talk about not sending to contacts which
>> have bounced back an error (and even that sounds like a bad optimization
>> to me).
> 
> Section 4.4.2 of rfc3921bis says:
> 
> Note: As an optimization, if the subscription state is "both" then the
> user's server MAY choose to broadcast subsequent presence only if the
> server has received available presence from the contact at some point
> during the user's session; i.e., if the server never received available
> presence from the contact and the user has a mutual presence
> subscription with the contact, it MAY decline to send subsequent
> presence to the contact.

Touché. Why don't you mention the usage of this optimization in
http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-03.html
which refers to 3920+3921?

So we have three alternatives to compare:
1) rfc-style (and the looser is...)
2) bis-style
3) repeaters

My script indicates that repeaters 'win' (measuring B4 or B6, neglecting
creation overhead) against bis-optimizations in scenarios 1, 2, 4 and 5
but lose in scenario 3 (with B6 25166 instead of 22917).
They 'win' always when measuring B5.

2000 bytes in B2 seem to be the minimum amount that could be 'wasted'
for repeater creation (in scenario 1), which afaics amounts to 550 bytes
for that scenario (plus disco + deletion).

Philipp



More information about the Standards mailing list