public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Mitar <mitar@tnode.com>
To: drwho@virtadpt.net
Cc: Juliusz Chroboczek <jch@pps.jussieu.fr>,
	b.a.t.m.a.n@open-mesh.net,
	Battle of the Mesh Mailing List <battlemesh@ml.ninux.org>,
	babel-users@lists.alioth.debian.org
Subject: Re: [B.A.T.M.A.N.] [Battlemesh] Battlemesh-like experiment in Washington, DC
Date: Wed, 10 Aug 2011 18:53:13 +0200	[thread overview]
Message-ID: <4E42B779.70905@tnode.com> (raw)
In-Reply-To: <4E42B411.9050601@virtadpt.net>

Hi!

> The Byzantium control panel is an application which allows the user to
> (de)configure network interfaces, add or remove them from a mesh, and
> enable or disable services and web applications running on a node.  It
> runs on a node (listening only on the loopback interface) and is
> accessed with any web browser.  Technically, it is a web application,
> but seeing as how Byzantium will package a couple of web applications
> for public use on a mesh anyway (Etherpad-lite, crypto.cat, status.net,
> and a few others) it made more sense to call it a control panel.

Interesting. Just as an information, in our network (wlan slovenia) we
have taken directly the opposite approach and made a centralized system
for deploying nodes (centralized in the sense it is one of the services
of the network, but the network itself still runs operates if this
service is removed from operation, this server/system/service only
streamlines node deployment (and prevents IP collisions so that it
maintains ). The point we have seen is that web interface on the node
takes simply too much time to maintain once you have many nodes which
you want to configure the same (and update configuration and so on). It
takes time to click all those things. And that it is still too technical
for common people to use.

So we have taken completely other approach: nodes without any web
interface, where you have a service in the network which issues
pregenerated firmware images with all configuration already in there. So
you just select what hardware you have, where the node will be and
everything else is done by the system (for power users you can also
select additional OpenWrt packets and mangle with configuration, but it
is not necessary). You flash the image, power it up and this is it.

Now, the next step is to make this service distributed (like every node
can be it) and we have best of both worlds. ;-)

But currently we are making it modular, so that different networks can
adapt it to their needs:

http://dev.wlan-si.net/wiki/Nodewatcher

> IPv4.  We considered IPv6, and in fact we get it for free with the Linux
> kernel, but not all applications are aware of or play nicely with it.

Yes, but if everybody just waits for applications to be ready ... ;-)

I think it is crucial especially for decentralized networks to start
using it.

Maybe instead of random IP allocation you could try some distributed IP
allocation system where you would take some temporary IP and request
what is free (using distributed hash storage or something). But yes,
there were already so many other ideas for this problem discussed and
yes, there is a problem of mixing layers.

> This is an interesting problem to us, and one of the things we have in
> mind once Byzantium is stable is correcting problems with
> interoperability.

I would invite you to take part here:

http://interop.wlan-si.net/

It is an initiative by many networks to find some common ground. As I
see it is a bit more centralized that your approach (we are mostly using
centralized node databases), but probably we could also find some common
ground with you. For example, currently we are defining a common
database schema to be able to describe our nodes in a common way so that
we can then have common applications working over that.

You could probably use the same schema internally in your control panel
in a distributed way so that maybe some centralized system in your
network could still fetch this data and use it (for example to draw a
map or something).


Mitar

  reply	other threads:[~2011-08-10 16:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-16 13:42 [B.A.T.M.A.N.] Battlemesh-like experiment in Washington, DC Juliusz Chroboczek
2011-07-16 15:34 ` Marek Lindner
2011-07-18 17:41   ` The Doctor
2011-07-20 17:25 ` The Doctor
2011-07-20 18:55   ` Juliusz Chroboczek
2011-07-21 14:35     ` The Doctor
2011-07-21 16:20       ` Juliusz Chroboczek
2011-08-08 19:05         ` The Doctor
2011-08-09 11:35           ` [B.A.T.M.A.N.] [Battlemesh] " Mitar
2011-08-09 16:51             ` The Doctor
2011-08-09 20:13               ` Juliusz Chroboczek
2011-08-10 16:31                 ` The Doctor
2011-08-09 21:04               ` Mitar
2011-08-10 16:38                 ` The Doctor
2011-08-10 16:53                   ` Mitar [this message]
2011-08-10 17:47                     ` [B.A.T.M.A.N.] [Babel-users] " haxwithaxe
2011-08-10 21:54                       ` Mitar
     [not found]               ` <CAEVTcgUMYVjHbNnP8wBBsGEtAoH+BNW3G1vBoktDoOPMDcsoQw@mail.gmail.com>
2011-08-10 16:53                 ` [B.A.T.M.A.N.] " The Doctor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E42B779.70905@tnode.com \
    --to=mitar@tnode.com \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    --cc=b.a.t.m.a.n@open-mesh.net \
    --cc=babel-users@lists.alioth.debian.org \
    --cc=battlemesh@ml.ninux.org \
    --cc=drwho@virtadpt.net \
    --cc=jch@pps.jussieu.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox