Apologies for the delay from the announcement of some screenshots for the app. I will make up for the delay however :P

Hope everyone had a good easter,
D. Hilliard

As promised here begins the large status update that has been promised.

The last few months have been a little bit crazy with work but in my spare time i've been taking various approaches to building the software for a remote aid deployment system. Many of these attempts were unsuccessful but taught me many a lesson about designing the system around the limitations given whilst also being abstract enough as not have to depend on a particular mesh networking system.

As such all domain specific responsibilities are encapsulated in a daemon that runs on each system connected to the network that helps to accelerate data throughput through the use of cache and latency/speed-based connection sorting.

The user interface was amongst one of the hardest things to do and after several false attempts at building an intuitive interface that offers what is needed I have finally settled on a combination of python and pyqt4.

Til the next update

I apologize for not keeping everyone up to date on the status of the project, but in the coming days, there will be a lot of updates to this and if i can build a module capable of simulating the network infrastructure a demo release of the gui code will be coming to you as soon as possible.

Now for the details:
The gui and most components the user sees are written in python.
The networking daemon (still in development) is written in C and has a set of python bindings.

This blog needs more jokes :D. In that vein, I seriously doubt that a million monkeys on a million computers will create anything of value, maybe a bunch of destroyed computers or WinME :P

Anyway I have been continuing to write code the node server and considering the algorithms for traffic routing that i can employ. The biggest road block I have been having is how to set up the wireless adapter on the efika to start playing nice and work. As far as the hardware is concerned the efika is set up with a wireless card and a linux image (basically a cut down debian install) installed on a usb key. The image is nothing to be proud of as it is completely chaotic and many services that will be needed have not been even touched upon at all. When i can get the time I shall have to do or find a very cutdown version of linux that can fit within a 32MB or less footprint.

One of the issues that I have also been facing is interfaces, especially for the "hyper-nodes" that are designated to communicate between clusters of nodes (villages). These hyper-nodes would have two wireless interfaces most likely. One of these would be hooked up to a directional antenna pointed towards another hyper-node in another cluster and the other would be for the local cluster of nodes.

Moving onto the software side of the equation:
Encryption between nodes, this is a bit of a mystery to me as encryption will definately make the nodes enticing for corporations to employ in their businesses as a dirt cheap networking solution. The trade-off however is the computational overhead that is needed to encrypt transmissions between nodes. There are a number of approaches to encryption that can be taken:
1. Encrypt traffic between nodes. Each node only needs to know the encryption hashes for each connected nodes. The packets need to be decrypted and re-encrypted at each node.
2. Encrypt the data itself, but not the header. This guarantees end-to-end security as it is only seen unencrypted at either end point. The down-side to this is that the two nodes have to negotiate an encryption keyset to use, and this negotiation may happen over an unsecure link thus making the security of the following transactions void.
3. Use public key encryption. When a node recognises the network it requests the authentication public key (all nodes have this, but not the matching private key), which it then uses to encrypt its credentials. This packet is then routed to the master node in the cluster, which decodes the message, generates a private key for the new node and encrypts the resultant packet with a keyphrase provided by the new node in its authentication packet. This new packet is routed to the new node, which is now able to decrypt packets with its own private key.

All these methods ensure that nodes that are authenticated can decrypt packets, and unauthenticated nodes can just function as routing nodes ignorant of the data being passed around.

I suppose I will need to create a proper document with all the specifics in it for interested parties.

Hopefully I will have some time to implement the designs and have someone test the code for me, because it is quite hard to test with only one device.

I have been happily chugging along whenever i have free time documenting the design that has been chosen for the node daemon. I finally have a usb-serial cable with which to connect to the efika so headless (with a wlan card) on-board testing of the software can be commenced.

All my current code is running off a usb key, for two reasons:
1. The old laptop hard-disk died on me losing a considerable amount of non-backed up test data and code as well.
2. It was a hassle pulling the hard-disk out each time i needed to perform a mass write/read operation

About the code, there is no real advantage of using either C or C++ over the other as they are both perfectly adequate for the purpose because well written code should perform well regardless of either language

cheers,
once more,
Denis

I have started coding the core mesh networking daemon that will work in the background with the front-end. The key features that I have deemed to be necessary is to get all of the basic networking components working. That includes registering on the mesh network, routing network traffic, publishing/receiving messages, and being able to configure the daemon as it is running. One of the features which i would like to integrate is the ability for the efika to act as a bridge between an existing LAN network and the mesh network.

The network component will be written entirely in C++ given the scope of it and the requirement for being able to extend the daemon's functionality.

After dividing the system into two components, i decided the backbone of the system was needed before anything else.

When looking at the system and the limitations imposed by the wireless connection between nodes I began to think that my first design was needlessly complex by treating the download mechanism for voice/picture data and messages differently. Essentially the two are the same; "DATA". So with that in mind they can be treated exactly the same. When this was considered I decided that if the UDP packets were too large they waste a large quantity of bandwidth. For example if the packet size was determined as 1KB and the user wanted to send a message with about 20 characters in it, the rest of the packet would be wasted. I am currently deciding on the maximum packet size and at the moment a data payload of 128 bytes plus packet information overhead would be ideal as it is a compromise between size and speed.

Ok now onto how the upload/download manager works. When the user pushes a message onto the network layer, the message is serialized and packetized, then an announcement is placed onto the broadcast socket (to all adjacent connected nodes) that indicates the node has data it wants to upload. Naturally the message can be a general message addressed to all nodes or it could be a message that is restricted to a smaller number of recipients.

If it is a general each node reports back to the transmitting node that it wants to download the data. After a small period of time (a time-out) the transmitting node knows of the connected nodes that are interested in the message. And so it will follow the following formula to determine the minimum number of packets per node that need to be seeded. This formula is round((number of packets+1)/(number of peers)). From this each receiving node shares data to reduce load on the originating node. This process repeats as it ripples through the network uploading the message to all nodes.

However the approach needed for messages that are limited to a small number of recipients requires a different approach to succeed. This will be the topic of the next blog entry.

Always on internet connections are taken for granted by every one who has reliable access to these 24/7. However the traditional system (centralised server - many clients) is not suited to the environments the system will be employed in. However mesh networking is ideal because instead of investing a large amount of money into infrastructure without providing the devices that use the infrastructure is futile.

Time to get to the point now.
The system is essentially designed to operate as two seperate systems:
The system which the user interacts with to retrieve messages, send message and in general interact with the system. The other side is the infrastructure side. This layer would need to run 24/7 to act as a data forwarding node in the system. That is the purpose of the message ticker/manager and the download/upload manager.

The message ticker is responsible for message management. By this the message ticker is responsible for notifying the UI that a new message has been recieved and when the user wants to send a message invoke the appropriate actions to do so. As each member in the network is a node the message ticker has the additional responsibility to forward messages to their destination. The message ticker unlike the download/upload manager is responsible for small chunks of data (each message would be limited to about 1024 bytes to keep network utilisation low.) Because of this imposed limitation and the fact that the system is designed for voice communication the message will also contain instructions on how to retrieve the voice data.

This is where the download/upload manager comes in. Loosely based on the bittorrent model this system allows the network to supply the recorded voice only when requested to do so. Given the complete system will be part of a mesh network, a bittorrent network is the one of the best data distribution methods that does not rely on a centralised server. However unlike a bittorrent network the protocol employed will need to be different and employ a distributed tracker to prevent congestion to the tracker server/source party.

Thanks for reading and I will be updating this very regularly in the weeks to come. So if you have any questions dont be afraid to contact me.

BTW. I am currently looking for someone with experience in UI coding/design to create the front-end to the system.

For those who are interested here is the functional block diagram for the project. In the next couple days i'll update this with the responsibilities of each module.

Due to current demands on my time the project isnt coming along as fast as i hoped. This is as well as the difficulty i have found in sourcing a compact keyboard to use the board with seeing as the original (keyboard) has failed.

Apart from that, I have heard of the EWB challenge which as part of a complete solution involves providing cheap computing to an indian orphanage. When I was informed about it i thought the EFIKA would be the perfect platform on which to run because it is small, compact and uses a fraction of the power of a laptop which is many times more expensive. And with the EFIKA2 coming round the corner, it will be a one stop shop for a compact system that provides the features needed.

Over the previous weeks I have been pruning down a feature list for the first release.

These should be:
A basic (mainly due to my time constraints) and simple to use interface for those who have never interacted with a computer before (i should be uploading mock ups of the interface in a few days).

A facility to create alert style messages that would match the type found in the final design.
These would include a message type and a short recording (max 2min). Ideally these would either be uploaded to a central post which an aid worker would man or transmitted to adjacent communities/nodes.

I have yet to decide on the underlying system that would support the code but the main requirement would be that it can be loaded onto a small flash card and be used as a static image.

As to the graphics card, I am using a radeon 9250 but given the pain of removing the card whenever i need to access the hard drive manually a on-board solution would be awesome and the system would be slimmed down dramatically.

Cheers.
And sorry for the lack of updating.