[sugar] Obtaining Buddy objects as contacts are encountered

Dafydd Harries dafydd.harries at collabora.co.uk
Thu May 10 13:57:11 EDT 2007


Ar 10/05/2007 am 16:32, ysgrifennodd Simon McVittie:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> At the moment the Presence Service API assumes we're subscribed to the
> presence of every contact we'll ever encounter, which obviously can't scale to
> a school.

To elaborate on this a bit:

When thinking about scalability of the networking code, we've been using 1,500
as the biggest number of children we might see in a deployment.

If you are subscribed to everybody on the server, and there are 1,500 children
signed in, then you will receive 1,500 <presence> stanzas when you sign in to
the server. A Jabber scalability analysis[0] assumed 200 bytes per presence
stanza, which gives us a figure of 292KiB for initial presence download.

Furthermore, this entails getting a message whenever anybody in the school:

 - signs on
 - signs off
 - shares an activity
 - joins an activity
 - leaves an activity
 - changes their current activity

Since each child has a TCP connection to the server, these messages are not
broadcast/multicast, but rather each message is sent over 1,500 connections.

Also, if there are 1,500 contacts, it makes the mesh view's job of deciding
which children to show more difficult.

We don't think this will work, which is why we're planning to move to a
solution where laptops query the server for specific subsets of the
presence/activity information. We haven't designed in detail yet, but we think
that:

 - you'll always be subscribed to your friends
 - you'll always be subscribed to people in your groups
 - you'll subscribe oppportunistically to people in activities you're in
 - you'll unsubscribe from people who aren't friends/in your groups if you
   haven't interacted with them for a while
 - the server will respond to questions like "is there anybody doing a
   painting activity?", "give me a list of some people to put in my mesh view"
 - the server-side extensions will be implemented via a Python XMPP
   "component" that talks to ejabberd using XML

[0] http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-00.html

-- 
Dafydd


More information about the Sugar mailing list