Aberration » Jabber/XMPP

Roster Versioning in jabberd2

Tomasz Sterna — Sat, 11 Jul 2009 19:38:58 +0000

Thanks to the encouragement from Prosody Team, I spent 2 hours and implemented XEP-0237 Roster Versioning in jabberd2. The code is in jabberd2 SVN repository.

Unfortunately the only client supporting XEP-0237 is Gajim Trunk.

Roster Versioning in jabberd2 ©, .

jabberd2 packet throttling in action

Tomasz Sterna — Mon, 06 Jul 2009 11:15:02 +0000

Today I saw jabberd2 packet throttling in action and nicely visualized. There is a visible 16 pkt/s (64 stanzas per 4 seconds) cutoff on the following graph:

jabberd2 packet throttling in action ©, .

Transport clustering in jabberd2

Tomasz Sterna — Tue, 16 Jun 2009 23:16:59 +0000

The added value feature of clustering changes in jabberd2 is a possibility to multiplicate not only Session Manager component, but also components connected with XEP-0114 component protocol. Namely: Transports to other networks.

Component protocol connections differ from jabberd2 components that the hash used for selecting component instance to route to is computed using a ‘from’ address, not ‘to’ address. This means that the server (and s2s) userbase is distributed amongst the components (evenly).

I am currently running several clustered transports with no changes to the transport code. Pretty neat. :-)

Transport clustering in jabberd2 ©, .

Clustering for jabberd2

Tomasz Sterna — Sat, 13 Jun 2009 15:05:12 +0000

The largest problem for large jabberd2 deployments is a single-process, single-threaded Session Manager.
Being single-threaded means that it can process only one XMPP packet at a time. More importantly, when it waits for some data (from the storage mostly) it does not process any other packets.

One possible solution would be to rewrite the SM to be multi-threaded. And I do mean rewrite – the way it is designed now, would mean rewrite (or reassembly) from scratch.

Other possible solution is to make the SM multi-processed. This means a possibility to launch many Session Manager instances to service one XMPP domain. This would balance processing load between many processes (possibly machines) and spread storage load on many separate DB connections.

Most server implementation approach this with a separate ‘clustering’ component, which tracks which session component is handling which user.
In case of jabberd2 I think it is not necessary. We already have the all decision making overseer – the router component.

I just committed to SVN trunk a router version, that handles many SM and/or external components (i.e. transports) instances for one XMPP domain. Router selects the destination instance using a hash of user JID (receiver in case of SM instances, sender in case of external components). This is an approach that most clustering HTTP deployments use, which select the web server using session-id hash.

I’m running clustered jabberd2 on Chrome.pl with no problems.

Clustering for jabberd2 ©, .

Virtual domains for jabberd2

Tomasz Sterna — Wed, 10 Jun 2009 13:54:46 +0000

One of jabberd2 annoyances was its requirement to run one SM instance for every serviced domain. I already did some work for dynamic jabberd2 configuration introducing default host option in c2s.xml to remove requirement of restarting C2S every time one adds new serviced domain. But it still required launching separate SM process instance.

Today I committed virtual domains support changes to SVN branch http://codex.xiaoka.com/svn/jabberd2/branches/vhosts which allows you to configure more than one serviced domain in only one SM instance.
I successfully configured 3 domains in one SM instance and was able to talk between these 3 and one another in second SM process. All 4 connected to one Router process instance.

Unexpectedly it was pretty simple – it took me only ~6h. to get it working. :-)

Of course all domains serviced in one SM process have identical configuration. If you need domains with different configuration, you need to create another sm.xml and launch separate SM process for them.

The SVN vhosts branch changes need some polishing and testing. I would appreciate if you tried these and tell me what you think.

Virtual domains for jabberd2 ©, .

nginx and BOSH / Comet connections

Tomasz Sterna — Mon, 25 May 2009 10:10:14 +0000

Yesterday I was scratching my head badly, why on earth my development BOSH installation (I am developing a web based Jabber client) did not work, while the production one did fine. After digging (telnet and hand crafted HTTP+XMPP requests did the job well) I found out, that my local nginx installation was “to new”.

The latest nginx version does proxied request caching. It buffers the proxied server response and pushes it to the client as a whole. It does help in mitigating client-backend bandwidth differences, but breaks Comet requests like the BOSH one. There is an option added to nginx for this very purpose: proxy_buffering. You need to disable the buffering: proxy_buffering off;.

So, the complete BOSH proxy location should look like this:

location /http-bind/ { proxy_buffering off; tcp_nodelay on; keepalive_timeout 55; proxy_pass http://xmpp.server:5280/xmpp-httpbind/; }

nginx and BOSH / Comet connections ©, .

Changes in Tigase packages for Ubuntu

Tomasz Sterna — Fri, 08 May 2009 09:55:11 +0000

I reworked Tigase packaging. The changes are:

Separated tigase-xmltools, tigase-utils, tigase-extras, tigase-muc, tigase-pubsub packages
Moved the tigase-server shared files to common /usr/share/tigase folder
Packages are now built straight from Tigase SVN

The process is fully automatic (the poolling cycle is in 2 hours interval), so you may expect fresh packages in Xiaoka APT repository any time. ^_^

OpenFire to Tigase converter

Tomasz Sterna — Tue, 05 May 2009 10:47:30 +0000

After refactoring the Tigase Converter, its now very easy to add new server source modules.

Today I released v. 2.3 of the converter with support for OpenFire server migration.

Another good news is that the converter is now available from official Tigase repository.

Have fun with Tigase. (Handling 500k+ simultaneous user connections and more…)

ejabberd to Tigase converter

Tomasz Sterna — Tue, 28 Apr 2009 13:17:03 +0000

About a week ago I released my jabberd2-2-Tigase converter allowing jabberd2 deployments to Tigase migration. From that time I’ve refactored it to be more modular and today I added ejabberd conversion module.

You may get the v2 of Tigase Converter from my $HOME at Xiaoka Codex.

jabberd2 to Tigase converter

Tomasz Sterna — Fri, 17 Apr 2009 12:58:30 +0000

To be able to migrate my jabberd2 deployments to Tigase, I created a simple converter. It’s nothing fancy, but it did the migration for me fine. I tried to make it flexible – you may redefine the SQL queries to fetch user data from other XMPP server database schema. Only jabberd2 SQL queries are included though.

Get the converter at: Xiaoka Codex ~smoku