WebRTC based Jingle for JSJaC

Thanks to Valérian Saliou from jappix.org there’s now an implementation of Jingle for JSJaC. Jingle is a protocol that allows audio and video calls on top of XMPP. The implementation makes use of WebRTC as the underlying transport. And as such by definition it’s the hottest shit. The project is called JSJaCJingle.js and can be found over at github.

Cookie monster’s eating all of my Websockets

Lately I came across to playing around with XMPP Over Websockets. The objective was to get something like page transitions working for Websockets as well as they do with BOSH. With page transitions I mean being able to integrate some XMPP client into a web site that still has the old habit of loading new pages every time new content needs to be displayed. You know this thing with hyperlinks, what we did when we were young. Anyway, in such a case a XMPP client must be able to store it’s state upon unloading a page and restore it once the new page is being loaded. This also applies to the underlying XMPP stream the client is attached to.

The current proposal of XMPP Over Websockets does not support this scenario as the websocket is within a 1:1 relationship to the c2s session (aka the XMPP stream). So upon unloading a page the websocket would be closed and as such the c2s session would have to be terminated as well. So I introduced the notion of a websocket session that manages the underlying XMPP stream and allows websockets being attached to it. The idea was to use session IDs that are being stored at a cookie being sent of the websocket.

Now unfortunately this didn’t work well. As of time of this writing (Feb, 2013) only latest versions of Firefox and Chrome support cookies at the websockets level. E.g. Safari doesn’t handle them at all. Second both are unable to expose this cookie to the JavaScript API. While getting the success case working fine with this approach for the mentioned browsers you fail to being able to handle edge cases like sessions that ran into a timeout and having session IDs which are invalid. Bummer!

So probably we’ll come up with a solution that deals with those situations at the stream level itself using XEP-0198 – Stream Management. To make this work with XMPP Over Websockets there will be slight changes to the draft that allow to not close the stream immediately after closing the websockets but uses some predefined timeout instead.

Introducing Tumblikes

Tumblikes is a webapp based on node.js that allows you to download all your liked posts at Tumblr. It’s useful for backup or offline access. The project is opensource (AGPL) and hosted at Github. For convenience there’s an npm package as well. So you might just want to

$ npm install tumblikes

If you just want to use it, there’s an instance up and running for you at http://tumblikes.x-berg.de. Enjoy!

JSJaC v1.4

Good news folks: JSJaC v1.4 has just been released. With tons of updates and bugfixes for recent versions of browsers it also comes along with support for Facebook authentication, CORS and websockets. Documentation has been switched to JSDoc3 and improved a lot. Thanks a lot to all the contributors (check github to find out more)!

Downloads available:

That said, use git! 😉

bosh speed tests

Now with the newly announced node-xmpp-bosh (NXB) my first tests left me with the impression that this thing is pretty speedy to what I am used to. So I decided to do some quick benchmarks on different implementations of BOSH. I did these tests on my desktop (some intel core 2 duo with 2,4 GHz and 4GB of RAM).

Login-Times (in ms):

Native NXB
Ejabberd 2.1.6 593 (process_delay: 100ms)
417 (process_delay 10ms)
Tigase 4.3.1 145 222
Prosody 0.7.0 111 170

So what we can see here is that NXB might be a feasible improvement over ejabberd’s native BOSH interface while tigase and prosody do fine in both cases.
Would be nice of course to also test with some decent load and see how the configurations behave with different loads put on them. But that’s out of scope of my quick tests for now, sorry.

Update: Ejabberd honors a ‘process_delay’ parameter which makes the BOSH CM wait for this amount of 100ms for incoming packets from the server in order to reduce the overall number of roundtrips between client and BOSH CM. This results in an overall improved client experience. Although it might be a bit slower at login times.
By default this value is set to 100ms so I did my tests again with ‘process_delay’ set to 10ms. A value of 1ms or 0ms made ejabberd fail to work properly unfortunately so I can’t provide any further numbers. But as the overall number of request roundtrips for a login is 4, the maximum number of time saved for the login would be 40ms in best case when only dealing with the ‘process_delay’ parameter.

JSJaC v1.3.4 bugfix release

Unfortunately the last version of JSJaC (v1.3.3) released just some days ago contained some serious bugs regarding handling of xmlns attributes and namespaces correctly. It was introduced by a fix for IE9 which caused other browsers to fail. So if you’re using JSJaC v1.3.3 and your app deals with accessing elements identified by namespaces you’re strongly encouraged to update in order to avoid heavy brain damage.

JSJaC 1.3.3: Grab it while it’s hot!

Thought it’s about time to release all the little fixes and patches I’ve collected over the years for JSJaC and here it is: JSJaC 1.3.3! Along with innumerable bug fixes it contains fixes for IE 9 and two new functions which allow to implement your own data store when suspending or resuming a BOSH session. Have a look at the docs if you’re curious.

jwchat.org now with like button

Better late than never: jwchat.org new features a facebook like button plus a flattr button. So if you like the service here’s your chance to let us know! 😀

ezmlm on debian with dotdeb broken

Today I discovered my ezmlm-idx hasn’t been working anymore. Unfortunately this hasn’t been noticed for quite some time. I’m using the precompiled qmail stack from dotdeb.org. What I found in my logs was

Now that got me real headaches as there aren’t many useful results on google for this topic. The more I was surprised when I found out what caused the problem (thanks to ‘strace -f’): ezmlm was expecting qmail-queue to be found at /var/lib/qmail/bin. While it’s actually at /usr/sbin/qmail-queue. Adding a symlink to it fixed the issue for me.

gateways blocked

Short note: due to abuse I had to block access to all gateways (transports) of jwchat.org for external usage. I’m sorry about this but currently there’s no other way to maintain regular services as is.