GSoC -- Midterm!

So the GSoC is at its half-way point, and it is time for a status update. There are a few things on my mind which are worth mentioning.

The first thing is quite simple -- I have learned a lot.

I do not mean that I have just learned a lot of technical details or gotten better with a certain programming language or something (although both statements are true), but more importantly I have learned a lot about how to work on an open source project -- and the skills I have acquired so far are valuable entirely for their own sake, but many also generalize to other kinds of work.

For instance, working on MeshApp this summer has taught me a lot about methodically breaking up a large task in to many smaller, more manageable tasks. This seems simple and intuitive enough - but the way a big project is broken down into modules will define how (and when) those modules are actually created, which ultimately shapes how the finished product will work. Between the initial planning of the project and the end result lie many points where a decision must be made about how you will get from where you are now to where you want to be.

It is easy to make mistakes early and get a bit lost, especially without very much experience about navigating your way through without slipping around too much. Finding the quickest path from "I want this" to "I have this" is something that requires a lot of experience and a bit of luck. Or maybe it is a bit of experience and a lot of luck. I am not sure yet. Perhaps it depends on the problem at hand. I do not expect very much that luck will help with constructing a rigorous mathematical proof, but perhaps it is in the strange things that we observe which stimulate the imagination where luck is more important.

As an abrupt end to this metaphor, the second thing is this -- I am behind schedule.

This is not something which worries me a great deal, because it is completely natural with projects like this that such things will happen. However -- it does indicate to me a number of things which I must take quite seriously:

(1) The need to work harder. This is simple.

(2) The need to come up with a better strategy which will result in the project being completed on time with making only minimal and necessary changes to the original plan. This is not really so bad, but I wish it was not an issue.

Yet we make progress under the conditions that we have, not the conditions that we choose -- so it must be done.

I will close on a positive note with a simple observation -- It seems to me that the first part of writing code was mostly an uphill battle where every basic tool we need for "survival" had to be either adjusted from whatever we can find, or created from scratch. But there was a way through it, a lot was learned and foundations were put in place. Now we are in the second half of the game, and it is time to apply all of this knowledge and make something useful out of this foundation. It is hardly "downhill from here" but it is not so difficult to pick up the pace once you have a good foundation and there is not so much inertia working against you (so the hill analogy isn't perfect...because on a real hill it is entirely downhill once you pass the half-way point, unless there are two disjoint hills and you are trying to move from the top of one to the other or something.)

I expect to make another major status update within a week, marking the completion of MeshApp 0.1 and a more complete reflection on the technical aspects of what we have achieved.

Introducing MeshApp - A Mobile Application for Ad-Hoc Mesh Networking

The design for MeshApp has been worked out, and we are currently in the process of creating Milestones and opening tickets for MeshApp 1.0.

We have spent quite a while working out the design, but I think it will be worth it - since we have now a very clear picture of how MeshApp will look and what will be happening underneath.

The first week or so was spent brainstorming and doing research. I spent a lot of time thinking about possible features that could be implemented, but many of these ideas were quickly discarded since they would be more difficult to implement than they would be useful. After coming up with a number of ideas which were unclear (or just bad), it became a bit easier to focus on what is really necessary and useful.

There were a couple of things in particular which helped enormously with coming up with the current design of MeshApp.

 First, viewing the source code and documentation for existing plugins to olsrd made life a lot easier. Especially the plugins txtinfo (sends along useful olsrd output) and nameservice (DNS service for mesh nodes). One of the problems I was having at first was attempting to "reinvent the wheel" and think about how MeshApp will interact directly with olsrd. Thankfully, the plugins make this a non-issue.

Second, Mitar suggested we think of the possible kinds of people who will be using MeshApp, what will they be using it for, and what should MeshApp have that makes them think it is "cool". We divided up users into three categories: Non-Technical/Novice User, User instructed to use MeshApp, Technical/Expert User. This idea was helpful in coming up with a concrete design and thinking about how will MeshApp play into "bringing the mesh to the masses".

There are still some open problems that we have to deal with, and inevitably there will be problems that arise which we cannot anticipate. Some issues we are still dealing with:

1. Should MeshApp 1.0 be relatively "raw" (lacking certain functionality and usability features), or should the first release be polished and have more advanced (and time-consuming) technical features? That is, should MeshApp 1.0 be a basic prototype of the application and exclude the more complex features like GPS/Location data, temporary mesh network creator, auto-configuration wizard, etc? 
2. How to get olsrd fully ported to Android - regardless of the particular hardware or firmware version? This is a particular challenge, since olsrd has to run as root, yet more recent versions of Android (namely 2.1) have not yet been rooted. 
3. Getting the Ad-Hoc Routing Protocol (AHCP) to work without IPv6 support, or patching earlier versions of Android with support for IPv6.
4. A telnet command needs to be added to nameservice plugin so we can easily retrieve location data about other mobile nodes on the mesh.
5. How can we add in a metric for accuracy of location data? GPS location is often unreliable and inaccurate, while location via WiFi signal strength tends to give better results. There is functionality built in to Android for this - but how should we include this into our design?

Anyway, now that we are in a good place with the design of MeshApp - there will slightly more regular updates on its development. The progress can also be tracked more closely by checking out our wiki page and subscribing to the wlan-lj mailing lists. 

To anyone reading this blog - your thoughts and input are really valuable to the development of MeshApp. If you have any thoughts, leave a comment here. If you have any feature requests, send them along to the wlan-lj mailing list. If you would like to contribute to the project, send an e-mail to me personally or contact us through wlan-lj.

Hello World!

So, I will be keeping track of my thoughts and developments on my GSoC project here. I am working on porting the OLSR (Optimal Link-State Routing Protocol) Daemon to the Android Operating System and designing a generic GUI that can be easily customized as a front-end to OLSR on a variety of platforms. I am working for the Freifunk project, which acts as a sort of umbrella organization for ad-hoc wireless mesh networking enthusiasts around Europe and elsewhere. My mentor is Mitar, from the wlan-ljubljana project in Slovenia. More information on OLSR, Freifunk, wlan-lj and other community projects can be found by checking out the links on this page. These ambitious projects aim to open up internet access to everyone, which is a goal that I am very interested in working towards.

I am currently in the process of working out the overall design and scope of the project with my mentor. The actual coding doesn't begin until 28 May (a little over two weeks from now), so what I am doing right now is learning as much as I can about OLSR, Android's networking stack, the different wireless cards that are supported by the Android (modified Linux) Kernel, and GUI design using the Android SDK.

This is a lot to digest, but Google gives us two months between announcing accepted projects and the "start your engines - begin coding!" point, so there is time to think about this in great detail before we begin coding.

I'm going to leave the technical aspects about actually porting OLSR into Android and getting it to play nice with the plethora of wireless cards in these devices for another post at a later time. I want to focus on how we are thinking of designing the GUI here.

Mitar suggested that I take a look at the way Transmission has designed the GUI for their BitTorrent client as a model for what we should do. I have been using Transmission as my BitTorrent client of choice for years, but never read much of their documentation. Having seen it now, I am wowed at how smart their approach to building a GUI is. Transmission is a lean, mean, torrrent-tracking machine that has a very wide user base across many different platforms and has been included recently as the default BT client in Ubuntu ("Linux for the masses"). The minimalistic design, both under the hood and in the powerful GUI, makes Transmission blazingly fast and easy to use for everybody (from noobs who just want to download an album from TPB to power users running their own torrent trackers).

From the "About Transmission" page on their website:

"Transmission has been built from the ground up to be a lightweight, yet powerful BitTorrent client. Its simple, intuitive interface is designed to integrate tightly with whatever computing environment you choose to use. Transmission strikes a balance between providing useful functionality without feature bloat. Furthermore, it is free for anyone to use or modify."

You can run transmission:

• Through the command-line, on a remote server.
• Through a web-interface, in the same way you can configure your wireless router (for instance).
• Natively in Mac OS X, using the Growl interface.
• Natively in Linux, using GTK+ or Qt as interface.
• On an embedded device, on a server, or remotely through the internet.

So, we want to be like Transmission in the sense that we need a base system of libraries with native GUI modules built on top of the same underlying libraries.

There are a few problems we face in porting OLSR to Android, since there are complications with having a GUI viewer on top of a daemon running with root permissions in Android.

Our solution is to have the OLSR daemon running as a root process (since it needs to), build on a new GUI module to OLSR. Then, have an IPC (Inter-process communicator) sending along data from OLSR to the non-privileged GUI process which links to the platform-specific GUI that gives a visual interface to the OLSR daemon.

I have several things to get a better grasp of before really diving into the project:

• Compile some C code and write a program in Java that links to it.
• Study the Android SDK and NDK.
• Continue looking at the code for OLSR, look at existing graphic interfaces to network daemons. (It would be interesting, perhaps, to look the Zenmap, a graphical nmap).
• Set up a wireless router using the Freifunk firmware and learn how it works.
• Set up tickets and milestones to go on the project trac.
• Work out a general technical outline for how to do this project.

I will be taking my last exams this Wednesday and then moving out of my apartment (going back to Houston) a couple of days later. I should have another post ready this weekend, about Android's networking stack and the OLSR protocol (i.e. what we are dealing with).

Before the 28th, I will be writing a post (to post on the wlan-ljubljana trac, as well as on this blog) giving a non-technical overview about what this project is really all about, and describe what we are doing in general. 

There will probably be a couple of other posts on here over the next two weeks, corresponding to the successful completion of the tasks I list above.

Until then, I'm studying for exams and packing up. 

-Charles