[IAEP] Jabber Server

[Morgan Collett]

On Thu, Oct 2, 2008 at 06:23, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Farning wrote:
> | Would it be feasible for Sugar Labs to set up jabber servers so that
> | individual deployments have a zero cost mechanism to collaborate among
> | themselves.
>
> Are you referring to Sugar-compatible collaboration servers or generic
> Jabber chat servers?  They are unfortunately far from the same thing.
>
> Last year, OLPC provided a  hosted collaboration server for a time (IIRC)
> at jabber.laptop.org.  Once there were more than about 50 active users
> with B4 machines and emulators, the memory usage of the modified ejabberd
> and general load on the server became so high that the system would crash
> on a regular basis.  The task of solving that problem became Collabora's
> current Gadget system, which is still in development.

I saw up to 170 users on jabber.laptop.org when it was (at times)
working. At that number, the mesh view rendering (on ~650) took the XO
CPU to a crawl for minutes at a time - something that has probably
been improved, but I haven't had the opportunity to test it lately.

IIRC a big part of the problem was that at that stage we were
regularly reflashing without preserving $HOME, so a new key and jabber
id were created every time. That meant the jabber server had a large
roster (much bigger than the 170 online that I saw) and that's exactly
our scalability bottleneck that Gadget is designed to address.

Since then we made Presence Service automatically reregister on the
Jabber server if authentication of the existing jabber id fails - so
you can regularly "prune" the Jabber server by removing old (or even
current) accounts: See ejabberdctl delete-older-users on
http://wiki.laptop.org/go/Ejabberd_Configuration#Tips.

AFAIK the existing community servers are not being regularly
maintained or watched, which leads to their downtime when this
phenomenon kicks in. Regularly removing accounts should make a big
difference.

> Until Gadget is released, public collaboration servers are infeasible
> because the server cannot handle the resulting load.  We could attempt to
> create virtual private servers for various organizations to avoid the
> scaling problems, but we have no access control mechanism, so we would
> merely be hoping that not too many people joined any one server.  If they
> did, that server would likely crash, and Sugar is not presently designed
> to handle a server crash in an elegant fashion.

If a collaboration server is not treated as a black box, but instead
as a juvenile service that needs its nose blown and diaper changed
periodically, we could do a lot more with what we have now.

Certainly servers for closed or restricted communities (school LAN
etc) should be a lot more stable than those in the wild.

Regards
Morgan