Wednesday, July 25, 2007

A sign of Jabber's increasing popularity?

Some of you reading this are regulars in the Jabber MUC at This MUC is referenced on, and is the default room to join in many clients.

Unfortunately the past weeks have included events that I can only say are reminiscent of IRC...

  • Flooding

  • Abusive language

  • Spamming/advertising ("hey, check out this cool site! http://..." and leaving again)

Inevitably as Jabber gains good users it will also gain bad ones. While their activity in private chats is of little concern to us, I believe we need to lay down some guidelines for acceptable behaviour in the public conference.

Currently there are a handful of moderators keeping the MUC friendly. However it becomes hard to draw the line between what is acceptable and what is not. This is a matter of opinion that varies between most people.

My hope is that with some guidelines it will be easier for both the moderator and the user (who can then be directed to them if necessary).

The need for these moves is somewhat disappointing, but necessary it seems, if we are to keep the friendly atmosphere that we currently have in this little corner of the Jabber community :) and to continue providing useful help to Jabber newcomers.

I propose the same policy as the official Ubuntu support channels, which works well. Mild swearing is ok, as long as it is not excessive, or directed at a person. Anything else may result in a warning and/or kick at the moderator's discretion.

No deliberate flooding
Though I am not aware of it happening in the Jabber MUC, it has happened in another MUC I am in. A user joined 2 bots into the room, and set them into a loop with each other, and left. Obviously this is deliberate, and I had to ban all 3 JIDs involved (but not until several hundred messages had already been sent to the room).

In IRC it is frequent to get shouted at for pasting more than a couple of lines. In Jabber people seem to be more lenient, and I don't see why this should change. Obviously a warning should be given when needed.

English only
It may seem unfair to prevent people from speaking in their native language. However most languages have their own servers and their own conferences. I don't propose this rule to affect those casual users who come in search of help, yet speak no or little English. Those users are usually directed in a friendly way to a room and server of their native language, where they will hopefully receive better help.

However some users hold long conversations which could easily be taken into private messages, or to other rooms. These conversations are nearly always unrelated to Jabber, and only annoy the other occupants of the room. It also makes it impossible for moderators to moderate when the conversation is in a language they don't know (I have previously been asked to kick people who were being insulting toward other users, although I had no idea because they were not speaking in English).

Obviously these choices are not up to me alone to make, and so I welcome comments and opinions on what I suggest here.

Update: It seems this post caused something of a discussion... :)

Summer of Code Progress

In the past 2 weeks, I have tried every server-side BOSH implementation I can find (although more are always finding me!), and all have their individual problems with my client...

No support for XEP-0206, and hence no SASL login is possible. I also have the reproducible (yet still mysterious) problem I blogged about in my last post. I also have had problems with Openfire's overactivity detection. The XEP specifies that the client is always allowed to make a request if it is to send data. The old version of the XEP which Openfire implemented was not clear on this, and as far as I can tell I get disconnected when I should not be.

Well, it seems to work. Yet ejabberd does not support XEP-0206 either, and also refuses non-SASL logins. This makes it impossible to use with my code for now.

JabberHTTPBind (JHB)
A handy little servlet which implements XEP-0124 and a little bit of XEP-0206. Yet I have problems with this also, as it seems to take wait seconds before the session creation response is received. After that I get a reply, which triggers a reply from gloox, to which the server replies instantly (yes, it appears to be polling for some reason). This happens until I begin getting errors from Tomcat (I believe JHB disconnects the client for requesting too frequently). I suspect a bug in the logic for polling, which I will take a look at after implementing multiple connections.

The problem with Punjab seems quite simple, yet I have been unable to solve it. All my testing so far is being done locally, and Punjab seems to try to resolve 'localhost' on the external DNS. I don't know Python well, so this is the best I can understand of the problem. I intend to speak with the Punjab developer(s) this week.

All of the above are problems I am having, I would not be surprised to learn that many of them are a problem within my code. Unfortunately not having a working server implementation makes it very hard to know where the source of any particular problem lies. If anyone has suggestions about issues I have listed above, please do contact me :)

Today I managed to talk with Ian Paterson (author of the XEPs), who will kindly allow me to test against his server. Also I spoke with the anonymous commenter on my last post who has been very helpful, and offered me their Python implementation to play with as well. I learnt this week that Tigase has BOSH support in-development. With luck I will be able to test against Tigase in the coming weeks.

This week I also began the biggest change in the code for a while - enabling multiple connections to be made to the connection manager. This will help the client to work through proxies which don't support/allow HTTP 1.1 and/or pipelining.

Links round-up

The oldest post in my post cache that may be applicable...

I don't have time to blog about things in general for now, so I'll present you with a list of links I've gathered on my travels through the web...

Make mailto: links open Gmail (Ubuntu):

TortoiseSVN-like script for Nautilus (GNOME):

A helpful article from Microsoft:

A small computer running Xubuntu now on sale (did I already blog about this?):

Flip, a novel programming language:

Why Linux drives don't need defragmenting:

Free web hosting:

Free file hosting:

My Starred Slashdot articles:

Ubuntu Market Share:

GPLv3 & Microsoft:

Written articles vs blog posts:

Using the mouse in UIs:

Spammers vs CAPTCHAs:

OpenMoko phone on sale:

The world's first programmable robot?

I think so, this time:

History of the CD:

Wednesday, July 11, 2007

Summer of Code Update

Time for an update on my progress with my project, now we are halfway through GSoC...

Disconnection (either by error, or as requested by the gloox client) gracefully from the server is working now. I have also made some small improvements in other areas where necessary, too many and too small to list here.

A big problem I am having is that there are regular delays in my test setup. I have a test client for gloox that replies to messages it receives. I have tried both tkabber and Psi as the second client, with the same results.

I checked that my BOSH code is doing everything correctly and it seems the answer is (insert disclaimer here) yes.

Here is the link to a network capture log: Wireshark capture file

The file is so named because the test message I sent was the text "ooo". (No, I don't know why...)

Below is my translation to English of the necessary parts of the log, showing a message going from Psi to gloox (via the server) and the reply going back again:

A: GUI client (Psi 0.10, port 32921->5222)
B: BOSH client (gloox svn, port 45069->5280)
S: Jabber server (Openfire 3.3.2, port 5222)
CM: BOSH connection manager (Openfire 3.3.2, 5280)

# GUI client sends message to server
0 sec: A->S (frame 37 in the capture)
0.000030: TCP ACK for the above

# Server sends message to gloox via BOSH
0.001999: CM->B

# Gloox sends composing event
0.003065: (Composing event) B->CM
0.003090: TCP ACK for the above

# Gloox immediately after this sends reply message
0.003358: B->CM
0.003370: TCP ACK for the above

# Server sends composing event to GUI client
0.004707: (Composing event) S->A
0.004725: TCP ACK for the above

# Server replies with empty response to gloox,due to 30s inactivity (as per spec)
30.007330: (Empty response) CM->B

# Server sends message to GUI client

30.012078: S->A

# All the acks for the last packets
30.012078: TCP ACK for last TCP ACK (RTT to ACK was 30.007 seconds) (??????!)
30.012106: TCP ACK for S->A
30.046637: TCP ACK for (Empty response) CM->B

If anyone could explain why the server appears to hold a message for 30 seconds, please let me know!

The story with ejabberd (which I finally managed to patch, compile and build) isn't good either. Because the new version of the BOSH XEP does not define how to restart a stream, XEP-0206 support is needed, which now defines this function. Unfortunately no server supports this yet, so I disabled SASL until I find a way around this. Unfortunately ejabberd forces clients that advertise XMPP 1.0 to use SASL (which gloox does) so it denies login attempts.

Detecting which version of the BOSH protocol is supported by the server, and using the old method when necessary would work in this case, but not in Openfire's (it reports version 1.6 already).

There are a few server-independent connection managers around, and I will test with those. My intention is to find one that I am able to bring up to date with the current specifications.

This is my focus at the moment, but very soon I will begin implementing multiple connections (a big step) for when pipelining can not be used.