[Standards-JIG] proto-JEP: Smart Presence Distribution

Michal vorner Vaner michal.vaner at kdemail.net
Wed May 17 20:25:47 UTC 2006

On Wed, May 17, 2006 at 09:29:22PM +0200, Carlo v. Loesch wrote:
> Jean-Louis Seguineau typeth:
> | Sounds awfully like a fairy tale, isn't it ;) Once upon a time AOL published
> | statistics on the subject that are not in agreement with this ratio. But
> | maybe AOL is not relevant, they only have a few million concurrent users
> | online at the same time... That said the messages were 3 to 1 over presence
> yes this information is VERY relevant. this tells you what kind of ratio
> jabber SHOULD have, because aol has no distribution to handle at all, it
> doesn't have any retransmission overhead at all.
> what i was talking about isn't the amount of times people change their
> away status. i was talking about the amount of presence stanzas traveling
> S2S, which is a lot higher, because every status change is transmitted
> n times. without any optimization, the overhead is big. really big.
> with our JEP the overhead is reduced. it still isn't topologically
> optimized, that's the job for multicast, but even just sending a presence
> update to each server once instead of n times makes quite a difference.
> i should probably explain "topologically optimized" and "multicast":
> you're in france or quebec or antigues, i don't know, but you have a
> dozen friends in say argentina. in an ideal world your presence info
> would only travel to argentina once, then redistribute on location.
> we probably won't make multicast THAT smart, but it gives you an idea
> where we are heading to.
> yes multicast involves more trust on your friends' servers, but it's
> the only way jabber can scale to surpass the big proprietary services.
> why? because multicast stops the proliferation of overhead, which is
> the problem.
> | changes. If you want to demonstrate gains, you usually do sampling before
> | and after, then compare (basic experimental approach). You do the whole
> | process. You do not want to outsource your demonstration either, do you? 
> i don't mind outsourcing the tests to you. i trust your results will
> show the obvious and inevitable, unless you have an interest in not
> improving jabber.
> | What's the all point if the reduction is not important?
> the reduction happens anyway, you can't go wrong.
> the difference is only how much the reduction is.
> | Nope. I'm the one building the servers others are using to provide big
> excellent! then you can look up the figures that show how much
> presence overhead is currently happening in interserver communications
> of jabber! please do!

Alright, if it is really the issue jabber would not survive and we have
to spent a long time debuging, the OK. But it could be without breaking
the whole XMPP-CORE and XMPP-IM and without the relaying on the other's
synced roster.

The idea with each server having a multicast component and keeping the
list for some time would do the job, if there would be something
unsynchronized, it would get corrected by time, just after the list
timed out, it could be done to both presence and messages (possibly with
the same lists, which can be used in MUC).

These list could be only run-time, so no problems with database, they
would not break anything and they could be built as needed, according to
any rules, privacy or others.

And, anyway, there would not be much to synchronize, if the list
changed, a new one would be created, with new one, deleting the old one, 
which would mean less problems.


Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060517/4ef17e55/attachment.sig>

More information about the Standards mailing list