Published: 2013-02-28 12:04:24 by Daniele Ricci

A few days ago a little chat with a person made me think about the status of the Kontalk project. Downloads on Google Play are (slowly) growing, user registration too (not at same rate, though). Kontalk is getting known by more and more people, and it's time for more complete tools.

Gitorious is really a great platform, but it lacks of many tools when a project begins to grow. So I had a look around to other platform and I chose Google Code:

  • Git repositories
  • Bug tracker
  • Wiki
  • Release system

I've already migrated most of the repositories from Gitorious. The first issue I'm experiencing is poor referenciation of Git revisions: you can't make a reference to a specific repository: revisions always point to the default repository. This is quite uncomfortable.

Anyway, here is the project URL:

Published: 2013-02-22 20:39:57 by Daniele Ricci

New XMPP preview:

This update features typing notifications and a few bugfixes.

Published: 2013-02-20 17:10:50 by Daniele Ricci
15:52:18+0100 [XmlStream,58,] -- connection 1 start
15:52:57+0100 [XmlStream,59,] -- connection 2 start
15:53:18+0100 [XmlStream,60,] -- connection 3 start
15:53:39+0100 [XmlStream,61,] -- connection 4 start
15:53:40+0100 [XmlStream,61,] -- connection 4 close (RECV: </stream:stream> immediately after SASL success)
15:58:47+0100 [XmlStream,62,] -- connection 5 start
15:58:49+0100 [XmlStream,63,] -- connection 6 start
15:59:11+0100 [XmlStream,62,] -- connection 5 close (resource conflict - ends stream but DOES NOT END CONNECTION)
15:59:15+0100 [XmlStream,64,] -- connection 7 start
16:03:20+0100 [XmlStream,65,] -- connection 8 start
16:03:21+0100 [XmlStream,66,] -- connection 9 start
16:03:47+0100 [XmlStream,68,] -- connection 11 start
16:03:47+0100 [XmlStream,67,] -- connection 10 start
16:04:02+0100 [XmlStream,67,] -- connection 10 close (resource conflict - ends stream but DOES NOT END CONNECTION)
16:04:05+0100 [XmlStream,69,] -- connection 12 start
16:05:41+0100 [XmlStream,69,] -- connection 12 close (client disconnect)
16:08:31+0100 [-]                           -- connection ?? close (ping timeout)
16:08:46+0100 [XmlStream,70,] -- connection 13 start
16:08:46+0100 [XmlStream,67,] -- connection 10 close (client disconnect)
16:08:48+0100 [XmlStream,70,] -- connection 13 close (client disconnect)

There are indeed a few problems with connection management :-)

Published: 2013-02-19 18:57:48 by Daniele Ricci

I admit it: I've been writing the new Kontalk XMPP server very quickly. I didn't immediately considered performance issues because I wanted to have a working prototype as soon as possible.

The first issues are indeed with network lookup: querying the whole network just for a single user is very expensive. Anyway this is a major flaw within the design of the network architecture. I'll get to that later in another post.

The first bottleneck was a surprise: the event loop. As much as I love Twisted and its event loop it is a performance issue. I know long tasks can be divided into smaller shorter tasks, thus taking advantage of deferred execution. But that might not always be possible or true. A single, very small unit of execution might be part of a huge group of many small units, possibly hurting the event loop because of too many enqueued jobs.

One example of this is the JID object: I do instanciate many JID objects even for simple tasks — sometimes even without using them in a meaningful way. It turned out that doing massive lookup (e.g. 100+ users — actually I was testing client sync from my mobile phone) times out the whole procedure: roster lookup is given a certain amount of time to be executed. I had to (dinamically) increase it, according to the number of users I was about to lookup.

Another important issue is process decoupling: although having components of the server split into different processes (router, resolver, c2s, s2s, net) makes code and debugging more comfortable, it does bring its disadvantages. For example, c2s forwards the majority of client stanzas to the resolver — because it doesn't know where to send them. So even a simple presence stanza must go through at least router and resolver. Even for locally connected users stanzas are passed to the resolver before being delivered to the actual client. Those procedures can be improved by making c2s smarter — that is, if a user is connected locally, it might be a good thing to skip resolver. Of course that would involve many other synchronization issues and so on.
Intercomponent communication is (still) achieved through TCP/IP sockets. Using Unix socket might help boosting performance.

Last but not least, XML overhead, particularly concerning network traffic. XML is a verbose language: transmitting it over network is expensive, and parsing is not so cheap. I noticed that on GPRS my Kontalk client is very slow: it needs up to 20 seconds (worst conditions) to complete the entire login procedure. Stream compression and binary XML might help.

Published: 2013-02-11 16:30:26 by Daniele Ricci

I've just published a new preview release for Kontalk XMPP. Here is the link:

The big change here is support for push notifications. Of course many other improvements and bugfix are included.