Thursday, June 28, 2007

Summer of Code Update

This post is somewhat delayed, for a variety of reasons, and from today I'll hopefully be posting more regularly again.

Despite the lack of posts, I have still been working, and I have made some progress too.

Code for pipelining (a single connection) to the BOSH connection manager is roughly in place. My first message was sent through BOSH last week!

I do have a couple of problems, both of which I believe are down to Openfire's lack of full BOSH support.

SASL authentication will not work, because Openfire does not support the xmpp:restart attribute defined in XEP-0206. I have temporarily overcome this by disabling SASL authentication attempts in the simple client I am testing with. I will see how I can make the code backwards-compatible with the old HTTP binding in this respect*.

The second problem is that Openfire disconnects the client if it sends requests too frequently.

As I understand XEP-0124 however, if no requests are outstanding (and hence no way for the server to push data to the client) the server should allow a request within any amount of time. Although the latest version of the XEP is more clear about this, version 1.5 (on which Openfire's support is based) does not explicitly state it. As a result Openfire is being more restrictive than it should be. I intend to file a bug report for this.

My last problem was a bug I encountered in gloox (resulting in message replies not always getting sent), and it affected the test client I have that is using my BOSH class. It happens that the bug was already fixed, and simply merging with the latest gloox trunk fixed it.

My current and next tasks are to fix an intermittent segmentation fault, and an out-of-range exception (which I believe to be both related), and improve the handling of disconnecting from the server.

* This is not helped by Openfire currently reporting the wrong protocol version...

Saturday, June 09, 2007

How to recover an Ubuntu/Linux PC

People often claim that Linux is more stable than Windows. Without hard statistics, this can't really be proven. One thing I do know however, is that when things go wrong it is much easier to recover a Linux PC than a Windows one, without restarting. In this post I will explain what to do, in easy steps, to get your Linux back running as safely as possible.

1. Kill a single graphical application
If you know the problem is a single application that you have open that maybe just froze then it is simple to fix. Press Alt+F2 and type 'xkill' (without the quotes) then press enter. This runs the xkill program, and the next application that you click on will be forced to close. If you change your mind, press the right mouse button to exit from this mode.

It may be worth setting a keypress that will automatically start xkill when you need it. In Ubuntu/GNOME, go to System->Preferences->Keyboard Shortcuts

2. Restart the graphical interface
If you are still having problems, or the whole of the graphical interface is not responding, press Ctrl+Alt+Backspace. This will attempt to stop the graphical display, and then restart it. Any applications you had open will be killed.

3. Switch to a console to end the application
If this didn't work, or you know a certain program is causing the problem, you can kill that program without using the graphical interface. Press Ctrl+Alt+F1. If your PC is running, but slowly, this may take a minute. Eventually you should end up at a text login screen. Log in with your usual username and password, and wait for the prompt to appear.

If you know the name of the program causing the problems, type: killall <program name>. If it continues, you can try to force it to stop, with: killall -KILL <program name>. For system process you may get "Permission Denied" errors. Prefix the above commands with "sudo ", ie. sudo killall...

If you are not sure which program is making the PC unresponsive, use the 'top' command. It shows a list of running programs, and their name, and in the CPU column it shows how much of the computer's processor they are using up. Once you identify the application press 'q' to exit top, and use the commands above to kill the program.

If all is now working, Ctrl+Alt+F7 will switch back to the graphical interface.

4. Emergency reboot procedure
If the steps above all failed, there is one last way to reboot your computer, and it is much safer than pressing the reset button on your PC's case, or pulling out the power cable.

It is important that you type these key combinations in the correct order, allowing the PC some time to complete the command between each one. The SysRq key on your keyboard is often also labelled as "Print" or "Print Screen".

Ctrl+Alt+SysRq+R
Switches the keyboard mode.
Ctrl+Alt+SysRq+S
Writes all data to the disks, necessary to avoid data corruption, unsaved files will still be lost.
Ctrl+Alt+SysRq+E
Tries to end processes in a nice way. Allow a little bit of time before you use the next command.
Ctrl+Alt+SysRq+I
Tries to forcefully kill processes that have not closed.
Ctrl+Alt+SysRq+U
Temporarily makes the hard disks read-only, this makes it safe to reboot.
Ctrl+Alt+SysRq+B
Force reboot.

5. Surrender
If that didn't reboot your PC, press the reset switch, or pull the plug, and cross your fingers :)


If you have any other methods, tips, or feedback to share, post a comment and let me know!

Friday, June 08, 2007

Vote!

I just found this site, The Webware 100 in which Jabber appears next to many other networks and IM-related websites.

Do a good deed, and if you haven't already, vote for Jabber! :D

(That is, if you think it deserves the vote of course. If you don't, let me know and I'll correct you...)

Update: Whoops, I linked to the wrong category!

Tuesday, June 05, 2007

Summer of Code - Week 1 summary

As promised I shall give some update on my progress with the project so far.

We held the second weekly meeting, though with Kev temporarily in stpeter's seat - logs here.

I finally have a clear picture of what I am doing and where I am going.

As I said in the meeting, my project is not something I can make fancy screencasts from. On the other hand, I think I will try and produce some diagrams that show what BOSH is, and how it works. I realise that this is not clear to many people who might be reading this yet :)

Coding
Down to the important part. Today I finished my first steps and managed to get my initial code to compile (through the gloox makefile). I haven't finished the simple test client I will be using, so I can't actually test it yet. If I could however, it would hang immediately after connection... but it's surely a start! :)

Once I get some real code I think I will start producing tarballs of my progress. I am currently working in a local SVN repository, so it is not hard for me to do.

Back to work...