Portrait of Edd Dumbill, taken by Giles Turnbull

Subscribe to updates

Feed icon Atom or RSS

or get email updates

What I make

expectnation
a conference management web application


XTech Conference
a European web technology conference

Grasping the OBEX nettle

Yesterday was an archetypal hacking day. It started off not so well at all, with multiple machine lockups and reboots. The root of the troubles has been with the OBEX code I'm working on for GNOME Bluetooth. OBEX is the protocol that allows you to "beam" files between devices.

There is a library that implements OBEX, called openobex. I've been working with openobex for a while, reusing the code from its sample application. Unfortunately, this application was buggy: when a transfer was cancelled, it didn't clean up properly, and the next attempted transfer made an OBEX server crash. This also seems to leave Bluetooth devices in an unknown state, sometimes requiring them to be reset.

It all gets much worse on Linux 2.6: the way the crash confuses the Bluetooth devices causes hard lockups of the machine. This plainly shouldn't happen. So I spent several hours recompiling various kernels, applying this patch and that, before deciding the problem still hadn't been fixed. I'll be corresponding with the BlueZ developers to try and sort this on 2.6. Clearly no user space app should be able to lock up the machine.

Having downgraded to 2.4.23 kernel, however, I was able to get on and grasp the nettle of rewriting the GNOME Bluetooth OBEX support. As the previous code was the result of shoe-horning the openobex example into a GNOME app, it was very hard to figure out where bugs were. In order to get OBEX support to fit the idiom of the GTK event loop, I have reimplemented the support as a GSource.

GSources are a way of polling file descriptors and calling some functions when there's data. They make it easy to add new events into the main event loop. I also found out where the problem was with the openobex crash: after a connection had been broken, the internal state machine of the library was not reset. My current solution to this is to set the flags manually: they're exported from the openobex library, so they're part of the published application interface as far as I'm concerned. This does seem a little fragile, but the alternative is basically to shut the whole show down and bring it up again, which feels like overkill.

At the end of the day I ended up feeling happy to have solved this problem, and laid good foundations for solid OBEX support in GNOME Bluetooth in the future. With a small amount of care my code can be adapted to provide the same features for infra-red beaming too, and I might do this in time.

Now I want to get on and finish the rewrite, in order to get a tarball release of GNOME Bluetooth out. Life is so full that I'll be finding this difficult, I'm sure!

blog comments powered by Disqus


You are reading the weblog of Edd Dumbill, writer, programmer, entrepreneur and free software advocate.
Copyright © 2000-2012 Edd Dumbill