[sldev] Question: Replacing current group chat with XMPP?

[Edward Artaud]

There are a lot of tradeoffs of pub/sub vs polling, do a google seach
on the words 'pub sub polling' and you'll see many pages on the
subject.  True pub/sub (as opposed to RESTful pub/sub aka polling)
means the server has to be statefully aware of who's subscribed.  In
practice, not being statefully aware of your subscribers scales better
than being aware of them, and as Poppy points out, nice things like
caching and ETags/If-Modified-Since/304 Not Modified can be applied in
an much more fault tolerant and inexpensive brute force way rather
than true pub/sub which typically requires a lot more complex (and
harder to maintain systems) to operate at scale.  As to the user
experience, there's no reason why any of the approaches discussed
would have to chage the existing user experience.  My point is that
something I learned while implementing just such a system several
years ago was that group IM with no constraint on number of
participants is a totally different beast than 1 to 1 IM.


On Mon, Sep 8, 2008 at 4:25 PM, Paul Oppenheim (Poppy Linden)
<poppy at lindenlab.com> wrote:
> David M Chess wrote:
>>
>> I don't really understand this scaling argument.  In my experience,
>> neither "push everything everywhere" nor "constantly ask if there's anything
>> new" scales; what scales is actual pub/sub.  In the case of group IM,
>> messages get pushed by some server (or some cluster of entities acting as a
>> logical server) to all and only those places where someone cares.  There's
>> some overhead in keeping track of where there are places that someone cares,
>> but in most use-cases I've seen it's the approach that scales the best.
>
> Do you have any references / links / copypasta / personal stories on this
> kind of architecture research? I've been hungering for scalability research
> lately, and been surprised by much of what I've read. I would assume polling
> with caching would be much faster than pub/sub because you can use much
> dumber machinery, but I've also not investigated too many message queuing
> systems (I also don't work directly on IM). I can't speak for others on this
> list, but if you cook up a scalability resource mail you've got an audience
> of at least one ;)
>
> + poppy
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>