[jdev] Minimising number of MUC rooms

[Theo Cushion]

On 30 May 2012, at 13:21, Kevin Smith wrote:

> On Wed, May 30, 2012 at 1:13 PM, Theo Cushion <theo at jivatechnology.com> wrote:
>> I agree that there is never going to be a silver bullet that will solve all issues. However, there is always going to be a limit on the rate of stanzas that can be dealt with in a timely manner what ever the platform.
> 
> I'm not sure there's a silver bullet that'll solve all your problems
> trivially - but I'm also not sure that there isn't a solution that
> gains you more than what you currently propose.
> 
> So, there are two things being discussed here:
> 
> 1) Your use case and the need to limit the work done by the client on
> login. I think this is addressable for your deployment by limiting the
> number of rooms that need to be joined prior to there being activity
> in them (or possibly by using pubsub nodes rather that MUC rooms,
> although this is not a clear win and requires you to do significantly
> more client work).
> 
> 2) Allowing servers to 'force' or 'autojoin' users into MUCs - this is
> a feature that's generally interesting and speccing it up seems
> sensible even if it won't help your cases (although it might, in
> combination with some new server code).

It would certainly be nice to be able to get what ever saving is possible from the standards, as then everyone can benefit rather than focusing on application specific code.

>> Anything that can be done to minimise it will create more breathing room. By those estimates I'd say losing a 1/3 of the stanzas across the wire is a significant optimisation.
> 
> Right, it is.
> 
>> Perhaps the saving could be greater, why would there be 300+ back? If I were only the occupant, would I not just get my own presence back?
> 
> It'll receive presence from anyone in the room (I've not counted this)
> its own presence (I did count this), any message history
> requested/sent (I've not counted this) and the room subject, which
> indicates the join is complete (I did count this).

Is this possibly a great fit for the Pubsub/Muc hybrid. Clients can permanently subscribe selectively to things they are interested in. For example, I don't care about room subject, but presence and history I might care about. Having this information map on to nodes to the MUC jid gives very fine control over what information is required using an existing standard. Could the Pubsub/Muc hybrid simply come down to certain predefined mappings, plus room for arbitrary information.

>> If a Pubsub/MUC/Pubsub Inbox hybrid were created then there could be further savings.
>> 
>> Taking a higher level view, we use a combination of Pubsub/MUC to create different channels so that we can guarantee the right messages go to the right clients. XMPP gives us a bunch of neat features for dealing with this. However, at the moment the majority of our traffic is centred around setup, as opposed to the actual content - this does not seem sensible.
>> 
>> This issue is certainly compounded on the web, where users may leave your site and return minutes later. However, I would have thought suggestions on limiting the amount of handshaking that is required to be done is universally beneficial.
> 
> I'm not going to disagree.
> 
> /K