[Standards] Proposed XMPP Extension: Stanza Repeaters
stpeter at stpeter.im
Fri Mar 21 21:31:49 UTC 2008
Philipp Hancke wrote:
> 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.
>> And which version of invisible are you talking about?
Or something else?
> 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.
Life is hard. Don't go invisible. :P
>> 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
> which refers to 3920+3921?
Because that spec is not done yet?
> 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).
Thanks for looking into this. Despite the fact that we did not think
about repeaters primarily for the sake of presence, it seems that it
might be helpful here, too.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards