[Standards-JIG] RFC 3921 Better User Presence Experience(Implementation Detail)
mridul at sun.com
Fri Oct 27 14:01:09 UTC 2006
If local server talks to say 100 remote servers over s2s, each hosting
say 10k users - the requirements for the local server shoot up dramatically.
If the (re)connection failure is a jitter in the network , you will end
up with massive presence floods : one for unavailable presence to all
users on local server for each directed presence in remote server , and
another available push from remote server (which will be additional
requirement on the remote server - push all directed presence when a
If the local server is not as 'fast' as the remote server - the load
would be really high.
By the way , since the outbound from the local server failed (the
inbound from remote server could still be connected) , this could result
in cases where the remote server would not push presence updates to the
local server since the outbound never failed.
Add to it that you can have multiple outbound and multiple inbound
streams independent of each other - you have a nice mess.
JD Conley wrote:
>> So , if you have to mirror this at the local server , you will need to
>> cache all n x m presence updates from that server and invalidate all of
>> them with unavailable presence to the n local users as soon as the
>> remote server goes mia - very expensive imo.
> This could be cached in memory but also done in a persistent store (database, file system, etc) as it would not need to be accessed very often -- only when a server rejoins the net. And all you have to store is a list of probe requests that are last known to be active keyed by domain JID. As far as database queries go this one is pretty simple, especially if you already persist the presence of your local users to the DB.
More information about the Standards