[Standards-JIG] RFC 3921 Better User Presence Experience(Implementation Detail)

Mridul 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 
server reconnects).
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.
> -JD

More information about the Standards mailing list