So the starting point for an engineer is what types of mesh networks work that don't need to globally broadcast topology updates in real time.
It always amazes me how quick people are to accept someone else's incorrect approach to a problem or to dismiss a new paradigm because others havent had success. Meanwhile they spend enormous amounts of energy tweaking the parameters of an outdated paradigm to try to make it work a little longer.
The main thing holding back new superior approaches to a problem solution is always the people who tried and failed and then kept saying it was unworkable thus preventing others from trying.
I'm not saying this to discourage others from trying. But they should definitely be teams of network protocol experts, rather than a generalist team trying to put a product together as we were. We used 802.11s, and being the largest deployment of a protocol you weren't planning on having to fix yourself isn't an enviable position.
Was there a blog post or anywhere you guys catalogued these problems, your approaches, and what could be learned? I'm looking to take on a similar challenge as a generalist and would love to learn from your attempts :)
For example, here he proposes a hack on top of 802.11s to switch between reactive and adaptive mesh topologies based on measuring the network density -- if you're a small group of kids in a village you want a reactive network, which comes with higher bandwidth saturation costs, but if all the kids come into the same classroom at once you need to quickly switch to adaptive to avoid using up all the spectrum with routing detection:
http://wiki.laptop.org/go/MAD_Heuristics
http://wiki.laptop.org/go/MAD_Architecture
The 802.11s spec is pretty useless for high density areas without such a hack, it seems. I suppose the takeaway message is that your use of mesh networking needs to be extremely tailored to your specific use case, quite possibly including writing custom routing software.
John Gilmore also wrote a summary of the OLPC mesh experience here: http://lists.alioth.debian.org/pipermail/freedombox-discuss/...
This is a problem for the idea that mesh nets should be used to create resilient decentralized networks. Unless the meshnet is safe against attacks, any government or other organization that wanted to take a meshnet down might actually find it easier than taking down a multi-path tree-shaped or centralized infrastructure.
In other words, even setting aside maintenance overhead, simple relay overhead is also going to bring the network to its knees.
So is something like Multipeer Connectivity Framework in existence mostly because it is a much weaker version of true mesh networking? (Or not mesh networking at all?)
Do you think weaker versions of mesh networking that don't solve the underlying problems could also be valuable?
There are some other issues with meshed networks (latency, battery usage when you're just a client node, etc.), but especially for those of the kind described/dreamed about here (which are also known as MANETS -- mobile ad-hoc networks), the routing issue is a huge one.
Finally, I should note the above isn't just academic; several companies have tried to build products based on these kinds of networks -- military contractors being one of note -- and have pretty much come up short.
So until the really fundamental issues are worked out, which is in the realm of academic research, not implementation, we probably aren't going to see anything like this.