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.
>
> yai.
>
>> And which version of invisible are you talking
about?
I meant:
http://w
ww.xmpp.org/extensions/xep-0018.html
or:
http://w
ww.xmpp.org/extensions/xep-0126.html
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
> http://www.xmpp.org/internet-
drafts/draft-saintandre-xmpp-presence-analysis-03.html
>
> 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.
Peter
--
Peter Saint-Andre
https://stpeter.im/
|
