Peter Saint-Andre schrieb:
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://www.xmpp.org/extensions/xep-0018.html
or:
http://www.xmpp.org/extensions/xep-0126.html
I think my scenario applies to both, even though I don't
see an explicit "logging in as globally invisible" in
the former.
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
Especially don't go invisible and send probes ;-)
[snip]
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?
Then why are you using the optimization? I think that other protocol has
more traffic than even non-optimized XMPP. And you have a very good
showcase for the optimizations in -bis when comparing both versions ,-)
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.
Helpful? ;-)
B6 for scenario 5:
rfc: 199444444 bytes/second
bis: 45000000 bytes/second
smart/rep: 4544444 bytes/second
As you can see, smart/repeaters is uncompressed as good as bis-opts with
compression. I wonder how good the compression ratio will be with the
repeater data... I'd rather expect compressed traffic that is 20% the
size of the traffic before compression.
I don't think we need to discuss the usefulness of repeaters in MUC and
pubsub. The gain is obvious there, because the stanza rate is usually
much higher than 3/hour ;-)
The main problem with the bis-optimizations is that they only work well
if C4/C3 is small. But you never know C4 in advance. So when do you use
repeaters, when should you use the -bis optimizations?
Afaics, the 'biggest' problem of the repeater approach is the large
overhead (180 bytes) if the stanza itself is small.
I think it is possible to lower that overhead to the 40 bytes of the
hash hexcode:
<presence from='[EMAIL PROTECTED]/foo'
to='repeater.example.com/somehashsomehashsomehashsomehashsomehash'
type='probe'/>
That (125 bytes) is already less bytes than two probes to the
remote domain, which amount to ~160 bytes:
<presence from='[EMAIL PROTECTED]/foo' to='[EMAIL PROTECTED]'
type='probe'/>
<presence from='[EMAIL PROTECTED]/foo' to='[EMAIL PROTECTED]'
type='probe'/>
If we can eliminate repeater creation overhead the trade-off point
could be 2:
Create and store once, 'never' forget until the last
local contact of the repeater creator is gone (this is almost like
storing a roster for the remote user). The hash acts as a checksum
to make sure there is no desync.
Repeaters are already a giant leap in the right direction, but I think
that there are optimizations which would make the fan-out idea usable
even for one or two recipients on each server.
Philipp
