[Commotion-dev] a bit about mesh apps

[Benjamin Chodoroff]

Hi list,

Over here in Detroit, we've been working on mesh applications. We'll be
pushing out some blog posts and code during this week. Please take a
look at my first draft of the first post below. I'll put it on the
internet more publicly later today!

Overview

Over the past few years, The Work Department has been active in building
community wireless networks in Detroit. We have experimented with
different types of hardware and software, and we have helped
neighborhoods build useful networks to share internet connectivity and
provide local file sharing. Something we haven’t had much of an
opportunity to explore, though, is building more elaborate systems that
leverage the unique traits of mesh networks.

As we worked through other parts of the Commotion project, we
brainstormed ideas for wireless mesh applications. We noticed that our
ideas would oftentimes replicate existing web services - e.g. a local
fileserver for music or movies, or a local message board for
neighborhood discussion. We began to wonder what would make a community
wireless application more appealing than using a centralized
Internet-based application. We agreed that it wouldn’t be enough to
offer someone the simple satisfaction of knowing their data is
decentralized... there would need to be some other benefits to using a
local application.

What would these benefits be? What is special about the architecture of
a community wireless mesh network? In pondering these questions, we
considered what is provided by these networks -- earlier, I mentioned
that the networks provide internet connection sharing and local file
sharing... but that’s only a part of the story. These networks also
provide something much grander: they become community institutions.
Unlike the Comcast hardware that is bolted out of arm’s reach on a
utility pole, our community wireless equipment lives on our porches, in
chicken coops, in our bell towers, and next to our desks. Each piece of
equipment has a story behind it. We know who held the ladder while it
was being installed and who lent their hammer drill to run a cable up to it.

A community mesh wireless router’s IP address is more than a 32 bit
number. It has history and meaning. How can we build applications that
reflect and enhance this?

I had the good fortune to meet Adam Magaluk at the Detroit’s
hackerspace, OmniCorpDetroit. Adam works on mesh wireless systems at
Illuminating Concepts, and is deeply interested in OLSR and embedded
systems. We are both young programmers, and share a desire for modular
and decentralized systems. During our initial conversations and
research, we ended up favoring web browser based application development
-- this way, people who might want to use an application wouldn’t have
to download anything. With today’s web browsers having lightweight
streaming messaging capabilities with WebSocket, we would have a lot of
flexibility in application development.

To build a web browser based application, we can start by limiting the
amount of work the server does to a bare minimum. In the circumstance of
a chat application, we can say that the server should simply keep a
record of who is connected to a chat session (in a sort of subscription
model) and then, as messages are posted, transfer messages from the
publisher to the subscribers.

Limiting the duties of each mesh node to passing messages and keeping
track of connected clients ends up being beneficial in two ways: it
conserves computing resources and encourages decentralized application
development. Since most community wireless routers are low power, low
cost devices running with MIPS CPUs and 4-16GB memory, the former
benefit is clearly attractive. The latter benefit is a bit more complex
- do we really need a fully decentralized application? Why can’t we just
have a little bit of local node storage? It sure would make things
simpler if we could have a local data cache instead of trying to develop
a peer-to-peer storage system.

To begin experimenting with the core concepts of lightweight messaging
systems that can work with hardware that makes up a community wireless
network, we built a system to provide WebSocket service to clients
connected to a Commotion access point. This service can be utilized by
anything on the network, but in our first example application, it is
employed by a web application served from a publicly-accessible LuCI
URL, linked from the splash page. The application provides a simple
interface to chat with other people who have connected to the local
node’s websocket chat system.

Thanks to Hans Christoph Steiner’s work on the jsoninfo plugin, OLSRd
can easily provide some useful network information as a json object to
web applications. Above the network layer, our websocket message server
can provide data about connected clients and possibly other information
in the future.

After you get your head wrapped around the WebSocket sever, its
underlying restrictions, and the mesh network playing field, you can
start to imagine various situations where local messaging might be
interesting. With an idea in mind, a developer can easily jump into a
familiar web application development environment - if you have used
WebSockets or socket.io or the like before, you understand the core
concepts of writing a mesh network application using these building
blocks. As we build more features into the platform, it will offer more
options for developers.

Next Steps

Currently, the system provides a messaging service that doesn’t utilize
node-to-node mesh connections. As it stands, we can develop some
interesting and useful applications, but there is definitely a lot to
gain from adding functionality as well as possibly revamping things in
the interest of security or privacy.

Our next major task is to begin experimenting with systems to allow
neighboring nodes to subscribe to each others’ connections. To use the
chat application as an example of how this might be used, a chat
participant might be able to start a conversation with people connected
to their own mesh node as well as its next neighbors, or some other
arbitrary number of hops.

We would also like to experiment with simple implementations of shared /
distributed storage. Again, to use the chat system as an illustration,
we could have chat participants store chat logs and offer them to new
participants who broadcast a request for the last n minutes of
conversation. There is a lot of distributed storage work for us to
reference, of course, so we have our work cut out for us!

Aside from enhancements and features in the messaging system itself, we
have plenty of ideas for the actual applications. We have recently been
prototyping games that could use a neighborhood or multi-neighborhood
mesh network as a playing field. We have found that prototyping and
brainstorming games is an enlightening process: it helps explain the ins
and outs of the technology to people, and also presents clear challenges
to create obvious and attainable goals within the technology’s
limitations. We’ll be sharing some “capture the flag” style game ideas
that utilize a meshaging system during the next couple of weeks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20120820/9a167dd6/attachment.sig>