<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
On 12-02-24 10:42 AM, Anthony Verevkin wrote:
<blockquote cite="mid:1a910810-f3b5-4fb3-bcf2-e5e77f5fb5b6@zimbra"
type="cite">
<blockquote type="cite">
<pre wrap="">From: "Thomas Milne" <a class="moz-txt-link-rfc2396E" href="mailto:thomas.bruce.milne-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"><thomas.bruce.milne@gmail.com></a>
I would LOVE to be part of building something like this, anyone know of
anything like this locally?
<a class="moz-txt-link-freetext" href="http://goo.gl/7Vnua">http://goo.gl/7Vnua</a>
</pre>
</blockquote>
<pre wrap="">
I was thinking about this kind of setup earlier and I would also like
to be a part of something like that. However I can see some serious
issues here:
1. Bandwidth. These guys are probably using 802.11g, 54Mbit, 2.4GHz. This
standard allows for 3 independent radio channels with maximum effective
bandwidth of 20Mbit each. 3 channels would be enough to create a basic mesh
so it's OK. If you upgrade to 802.11n but stay within one channel and still
have only one antenna (not using MIMO), your nominal bandwidth would be
75Mbit, taking you to effective 30-40Mbit per channel, shared and
half-duplex, not to mention unstable.
Provided that this is a mesh network and this becomes the maximum bandwidth
even in the bottleneck points (which turn out to become ``backbone''), I
would state that this network would not be good enough to allow web browsing.
As if only you allow users to browse the web, here comes youtube and the
whole network dies. But who wants the network without http nowadays?
2. Access to the roofs. Homeowners have the best access to put the antenna.
But also they are the ones with the worst antenna position, low above the
ground. People living in the hi-rise buildings either rent or are bound by
the condo rules that make it difficult to put the antenna in the best spot.
3. Internet access. The mesh network is a good way to interchange the
information, but the traffic should flow into the Big Internet at some point.
Toronto FreeNET probably might be a gateway for such a mesh network, but
then again they become the ISP. Yes, they do peer at TorIX, and the mesh
network would make the last mile free from Bell, but still Toronto FreeNET
is and ISP which abides the regulations. And what if you want to have the
alternative ISP? How you would balance between them? Would you put the BGP
full table into the mesh network? Well, the first Linksys router in the
chain is simply gonna die right away.
4. Ease of use. Is it going to be a network for all people or the network
``for geeks only''? Network for all people should have the ease of connecting
(the end point should not be a part of the mesh, rather just connect to a
hub of the mesh network). This network would also need to have some phone
support service. If we are about to build the ``geeks only'' network,
this is fun thing as well, but the distance between the geeks in the city
might be a fun-breaker.
So this is a nice thing to do, but it has a lot of caveats. If you have an
idea of how to overcome this, I'd be happy to join you.
Regards,
Anthony
</pre>
</blockquote>
I was looking into this a few months ago for a different (work
related) purpose. I didn't get so far as to set up any tests
(couldn't really find the "download here" link if I recall, or even
download source.tgz).<br>
<br>
Anyway, this might be useful or at least worth further
investigation, in the current context. Basically a glorified
sneaker net, or moped net, but with small changes to the apps you
get fairly usable wikis, e-mail, etc.<br>
<br>
<blockquote>Abstract<br>
<br>
TierStore is a distributed filesystem that simplifies the
development and deployment of applications in challenged network
environments, such as those in developing regions. For effective
support of bandwidth-constrained and intermittent connectivity, it
uses the Delay Tolerant Networking store-and-forward network
overlay and a publish/subscribe-based multicast replication
protocol. TierStore provides a standard filesystem interface and a
single-object coherence approach to conflict resolution which,
when augmented with application-specific handlers, is both
sufficient for many useful applications and simple to reason about
for programmers. In this paper, we show how these properties
enable easy adaptation and robust deployment of applications even
in highly intermittent networks and demonstrate the flexibility
and bandwidth savings of our prototype with initial evaluation
results. <br>
</blockquote>
<br>
<a class="moz-txt-link-freetext" href="http://static.usenix.org/events/fast08/tech/full_papers/demmer/demmer_html/">http://static.usenix.org/events/fast08/tech/full_papers/demmer/demmer_html/</a><br>
<a class="moz-txt-link-freetext" href="http://tier.cs.berkeley.edu/wiki/index.php?title=Home">http://tier.cs.berkeley.edu/wiki/index.php?title=Home</a><br>
<a class="moz-txt-link-freetext" href="http://citris-uc.org/research/projects/tierstore">http://citris-uc.org/research/projects/tierstore</a><br>
<br>
Cheers.<br>
<br>
Martin<br>
</body>
</html>