Migrated the blog to this location.

Stray links might happen, and some assets are not reuploaded here yet.

I had the question on PlanetErlang.

Why have you put whole ejabberd source to the repository? You could just put your modules to avoid constant merging from upstream.

Thank you, Anton, for enabling me to express some love to git and github.

The short answer

It’s easy and fun.

The longer answer

The early version of the code was actually in a separate private SVN repository. Part of my install procedure was copying the beams into the ejabberd ebin folder. But each time mod_muc or mod_pubsub modules were updated I had to launch FileMerge and merge things. And those modules are not slim.

Enters git and github. Brian J. Cully has a script updating every hour his ejabberd repository on github from the Process One svn repository.

My own ejabberd repository is fork from his.

And having my own tree up-to-date is only a matter of one (1) command :

“github pull bjc master“

Run sudo gem install github for installing the github gem.

Merges are done automatically. Of course the occasional conflict may arise, but whatever the process, I cannot avoid it.

Pushing to my github repository is also one command :

“git push origin master“

And if I want to send a patch right up to Process One ?

Say for pubsub …

“git diff bjc/master – src/mod_pubsub > pubsub.patch“

Contributing is easy

Fork my project, hack, push, pull request.

Can it be any simpler ? (This question is not rethorical)

Objectives

It’s an ejabberd-based proof-of-concept, with a set of custom modules aiming for making it stateless and very scalable on the storage backend.

All state data (including user accounts, roster information, persistent conference room, pubsub nodes and subscriptions) are stored in AWS webservices, S3 or SimpleDB.

It helps scaling up and down, and keeps managing costs at a proportianal cost. AWS services are very wide, and massively parallel access is what it’s all about.

Default ejabberd configuration uses mnesia, but Process One recommends switching some services like roster or auth to ODBC when load increases.

But DBMS have their own scaling problems, and that’s yet another piece of software to administrate.

CouchDB seems loads of fun, and I’d like to put some effort running ejabberd over it later on. Some work has started, but not much progress yet. (and CouchDB is still software to one needs to manage).

Current state

• ejabberd_auth_sdb : store users in SimpleDB. The version in github stores password encrypted, but forces password in PLAIN over XMPP, that means that TLS is required (really !). I have a version somewhere which exchanges hashes on the wire but stores password in clear in SimpleDB. Your call.

• mod_roster_sdb : roster information is stored in SimpleDB

• mod_pubsub : nodetree data is stored in S3 along with items. Subscriptions are stored in SimpleDB. I reimplemented nodetreedefault and nodedefault, with means that PEP works fine too.

• mod_muc : Uses modular_muc with the S3 storage for persisting rooms.

• mod_last_sdb : Stores last activity in SimpleDB

Still lacking :

Following the names of the modules, where to store data, in my opinion.

• mod_shared_roster : in SimpleDB

• mod_vcard : VCards in S3, index in SimpleDB

• mod_private : S3

• mod_privacy : S3

• mod_muc_log : S3 (with a specific setting for direct serving, maybe)

These modules are the only one which have state that should be persisted on disk. Mnesia is of course still be used for routing, configuration – but that’s transient data.

Transactions and latency

We loose transactions by switching away from mnesia or ODBC. That may or may not be a problem. I think it won’t be, but I don’t have data to prove one way or the other.

Latency also grows, but erlsdb and erls3, the libraries on which the modules are built, can interface with memcached (and are ketama enabled) if you use merle. Additionally using merle will keep usage costs down.

ejabberd mod_pubsub underwent several optimizations recently, and that improved performance of non-memcached AWS mod_pubsub. Initial code had latency around 10 seconds between publishing and receiving the event. Since last week’s improvement, performance is much better.

Down the road

I’d wish to see an EC2 AMI based on this code, just pass the domain name or the ejabberd.cfg file to ec2-start-instance and boom ! you have an ejabberd server up and running.

Want more horse power ? Start another one on the same domain in the same EC2 security group, the ejabberd nodes autodiscover each other and you’ve got a cluster. ec2nodefinder is designed for this use.

Combined with the very neat upcoming load-balancing and autoscaling services Amazon Web Services, there’s a great opportunity for deploying big and cheap!

Alternatives to the AWS loadbalancing would be pen, or a “native” XMPP solution.

A few things would need to be implemented for this to work well, like XMPP fast reconnect via resumption and/or C2S/S2S process migration between servers, because scaling down is as important as scaling up in the cloud.

If you want to participate, you’d be very welcome. Porting the modules I did not write, or testing and sending feedback would be … lovely.

And of course if Process One wants to integrate this code in a way or another, that would also be lovely !

Get it

Get it, clone it, fork it ! There’s bit of documentation on the README page.

[edited : added links to XEP-0198 and rfc3920bis-08, thanks to Zsombor Szabó for pointing me to them]

Thanks/Credits

Je dois beaucoup à Caféine.

Il m’a fait découvrir Avishai Cohen l’année dernière avec ce tweet.

Et la semaine dernière, il avait une place en rab, pour un concert complet dans un Bataclan blindé, et ce, malgré les deux dates. Et le concert du 24 novembre 2009 à l’Alhambra est déjà, lui aussi, complet.

Et il a pensé à moi pour une super place au 4ième rang, juste en face du percussionniste (toujours le membre le plus spectaculaire d’une formation.)

Merci Arnaud !

Laissez-moi écouter Aurora, le dernier album de Cohen, et me remettre dans le bain. C’est parti.

Le concert

Un quatuor contrebasse/piano/guitare/percussion + une chanteuse.

Tous complètement virtuoses et les cheveux rasés (non, pas la chanteuse).

Des inspirations jazz “classique” matinés de flamenco et de musique yiddish.

Une mention spéciale pour le percussionniste, 25 ans max, avec une pêche et une précision terrible.

On voyait qu’ils prenaient un plaisir à jouer. C’était joyeux et magnifique.

Au quatrième rappel, Cohen est venu s’excuser de ne pas pouvoir continuer à jouer, mais il était 22h passé, et il y avait le couvrefeu, sinon, on était bon pour tout la nuit … on serait tous restés !

Quelques notes en vrac :

• Avishai Cohen laissait beaucoup les autres s’exprimer. Il a fallu attendre la deuxième moitié du concert pour avoir un solo de contrebasse.

• Un duo magnifique guitare-piano (il me semble que c’était dans le morceau Leolam) qui donnait des frissons partout.

• Cohen a joué deux morceaux avec 2 cordes en moins sur sa contrebasse. Le temps de faire remplacer les cordes, il a sorti la basse électrique, et nous a régalé avec un solo de basse terrible.

• Toutes la parties d’une contrebasse peuvent servir à faire de la musique, avec la caisse pour le rythme, les cordes sous le chevalet pour les harmoniques

• Entre les morceaux, Cohen savait nous faire rire. “Mes parents sont dans la salle ce soir, va falloir que je joue bien”

• Cohen chante, et il chante bien !

Je ne connaissais aucun des morceaux, tous semblaient tirés de son nouvel album, à part un rappel sur Remembering – en duo basse-piano.

Une remarque pour le public : applaudir les solos, bien sûr ; taper dans les mains en rythme, c’est interdit parce que c’est pénible pour ceux qui veulent écouter la musique. Exception faite si les musiciens le demandent.

Les membres du quatuor

“L’oud d’Amos Hoffman, les percussions créatives d’Itamar Doari, le toucher délicat de Shai Maestro, la voix unique de Karen Malka.”
J’avais pas saisi leur nom pendant le concert, mais je me devais de les citer aussi.

I had some issues with inets under heavy load with erlsdb and erls3.

And when you are talking to Amazon Web Services, you’d want to write in parallel as much as possible. You also want to pipeline requests in one single socket, especially while using SSL encryption (even more costly to establish).

ibrowse seemed very interesting, especially since the CouchDB project started using it !

Got it out of jungerl, which is always a bit of a pain. You can also find it on github, I figured later.

Porting my code to ibrowse was quite easy. Though I had to change a bit of the async code. Instead of sending one message once the inets process received the HTTP response, it sends a message upon receiving headers then a slew of messages for each chunk it receives.

Had a few Too Many Open Files errors while loadtesting. As it appears, I had over 500 connections opened to Amazon AWS. Got more sensible defaults and the problem went away.

Configuration is by host, that forced me to change the naming of the S3 buckets from http://bucket.s3.amazonaws.com/ to http://s3.amazonaws.com/bucket/

One caveat : accessing SimpleDB using SSL gives InvalidSignature errors for the time being. Will squash that soon.

Using ibrowse will also unable me to write a client to S3 that will stream files to and from disk.

The ibrowse version are in the ibrowse branch for both projects.

Just committed erls3 over to github.

Enables access to S3. Tailored for highly concurrent access with small items rather than sending multigigabyte items. Everything you get/send from/to S3 is stored in the VM.

Usage examples will come shortly.

The API is however very straightforward.

Je reviens tout juste de la Cité des Sciences et de l’Industrie pour une journée 50% familial,e 50% XMPP et 100% réussie.

Je ne m’attendais pas à découvrir XMPP, mon objectif primaire était de faire une bijection tête <-> JID (c’est toujours enrichissant).

Les présentations étaient assez peu techniques. Certainement un choix assumé – mais le public était composé surtout de techos, et on aurait pu rentrer dans les détails, avec du XML et des XEP.

A noter que la présentation “Introduction à Jabber facile” a du être annulée, et c’était peut-être celle-là qui aurait donné les billes.

J’aurais aussi aimé qu’elle soit plus positive. C’est-à-dire qu’il y avait beaucoup d’arguments “XMPP >> MSN parce que MSN c’est le mal” (donc c’est en négatif). Ce en quoi je suis d’accord, mais il y aurait fallu beaucoup plus insister sur les points forts de XMPP dans l’absolu : l’extensibilité, la facilité de développement d’applicatif au-delà de l’IM.

Avec trois présentations qui ont être annulées, et ayant manqué la présentation de Laurent Lathieyre sur BuddyMob et celle de Jan Torben Heuer, ma perception était probablement biaisée.

De toute manière, faut pas se leurrer, XMPP va finir par gagner tout comme HTTP et SMTP ont réussi dans leur domaine respectif. C’est juste une question de temps, de code et d’évangélisme !

Un gros succès était la présentation de Kael et de Jehan qui nous ont présentés des bots qui présentaient le programme télé, et les téléchargeaient en pilotant VLC. Kael va publier son code soon, me dit-il.

Pour finir, merci beaucoup, Jehan, d’avoir pris le temps et eu l’énergie d’organiser cette journée.

PS : Et si vous voulez fêter l’anniversaire à nouveau, je préparerai peut-être quelque chose. (Ca fait quelques temps que j’ai pas donné de cours, et ça me manque de faire le clown devant des slides).

Pour fêter ça :

Une journée de présentation sur XMPP à la Villette.

Les infos sont ici et ici.

Merci à Laurent de me l’avoir appris !

Je vais y aller pour rencontrer les gens et écouter certaines conf. Et aussi pour emmener le nain aux expositions permanentes de la Cité des Sciences.

Le communiqué complet :

La communauté francophone des utilisateurs de Jabber/XMPP organise un
évènement anniversaire pour les 10 ans du protocole, samedi 28 février
au Carrefour Numérique de la Cité des Sciences et de l’Industrie.

Cet événement a pour but de faire découvrir au grand public comme aux
professionnels les possibilités de ce protocole de messagerie instantané,
ses usages actuels et futurs, ainsi que de faire un état des arts de la
communication instantanée.

L’évènement vous proposera des conférences d’une part, où vous seront
présentés divers projets ainsi que des thématiques générales par
divers acteurs communautaires (Ludovic Gilbon, Jan Torben Heuer, Jehan,
Kael, Thierry Stœhr, Nicolas Vérité) ainsi que des acteurs
professionnels sponsorisant l’évènement (Process One, Ubikod et Violet),
et des ateliers d’autres part.

Nous remercions en particulier (et dans un ordre aléatoire ne reflétant
aucune forme de préférence) l’ensemble de la communauté qui apporte aide
et soutien, nos sponsors, la XSF pour la gestion du développement du
protocole XMPP, ainsi que les associations AFUL, APRIL, FSF France et
Parinux qui nous ont énormément aidés à organiser l’évènement.

Le programme ci-dessous n’est pas entièrement fixé et est donc
susceptible de changer, mais donne néanmoins une idée des sujets
présentés et des horaires.

Conférences:

10H15: « présentation succinte de la journée et du protocole Jabber pour
la messagerie instantanée et la présence sur Internet » (intervenant:
Jehan — durée: 15 minutes)

10H45: « historique, situation et perspectives de Jabber/XMPP »
(intervenant: Nicolas Vérité — durée 45 minutes)

11H45: « L’utilisation de bots pour automatiser la récupération
répétitive d’informations contextuelles » (intervenant: Kael et Jehan –
durée: 15 minutes)

13h15: « BuddyMob : un réseau social mobile basé sur xmpp »
(intervenant: Laurent Lathieyre, Ubikod — durée: 30 minutes)

14h: « Violet et Violet OOOS : La plate forme Violet Open Object Operating
System » (intervenant: Olivier Mével, Violet — durée: 30 minutes)

14h45: « Social networks based on Jabber/XMPP – The power of decentrality
and privacy » (intervenant: Jan Torben Heuer, en anglais)

15h30: « Introduction à Jabber facile » (intervenant: Ludovic Gilbon –
durée 30 minutes)

16h15: « Les formats ouverts, protocoles ouverts et la messagerie
instantanée » (intervenant: Thierry Stœhr — durée: 30 minutes)

17h15: (intervenant: Process One — durée 30 minutes)

SimpleDB

SimpleDB is a the cloud database by Amazon Web Services.

Still in beta, SimpleDB provides you with metered access to fat storage designed for an internet scale database. Compared to MySQL or other RDBMS, it has few features (no transactions, no joins …), but using it is a no-brainer.

Still having a library wrapping around the HTTP calls to SimpleDB is good.

erlsdb

Hence the erlsdb OTP app. However development seemed to have stopped. So I took it to github and hack it.

It went surprisingly quickly (most certainly due to erlang’s power than my own skills) as I managed to add async http calls, multiple workers and finished implementing the API in a few hours.

Still needs a bit of polish but it’s already waiting for feedback !

Get it here !

examples

(if your eyes don’t burn from the syntax coloring)

ec2nodefinder is an application that enables remote erlang node discovery when hosted on EC2.

This new version uses the EC2 query interface instead of os:cmd’ing the amazon api tools.

It has no external dependencies now when deploying the release. Previous needed Java and the API tools.

Finally removed the need for the cert and pk files. It only uses AMAZONACCESSKEYID and AMAZONSECRETACCESSKEY.

Also new is an implementation of V2 signature code for AWS.
Given that V1 is deprecating at the end of the year, that’s a head start.

I did not see it anywhere in erlang yet, so HTH (as they say).

TODO : the secret key tend to come up in the logs. It will be removed in an upcoming release.