On Mon, Mar 24, 2008 at 1:45 PM, Philipp Hancke <[EMAIL PROTECTED]> wrote: > 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 > >
Nice. I haven't seen the argument yet but maybe I've just overlooked it. Reducing the number of presence and message stanzas don't just reduce traffic but maybe a more important fact is that the servers need to parse less XML and need to route less stanzas internally. It's a big improvement since a big part of the overall processing time of a server is spend on XML parsing. Tobias
