hi! Dose the translation of batman-adv support fast roaming between batman nodes(every batman node has two wireless interface under a bridge,one works in ap mode,another works in adhoc mode for batman' routing)
Hallo, vielleicht bekommt man Batman auch in Openmoko Linux Handy?
Dann hätte man eine Alternative zum Terra-Net, was bestimmt closed source ist.
Danke Gruss
P2P-Mobilfunksystem ermöglicht Gratis-Anrufe Quelle: http://www.openmoko.org/
"Mesh-Netzwerk mit Handys bedeutet das Ende von GSM-Netzen" - Technologie ist im WLAN-Bereich ein Hoffnungsträger Das schwedische Unternehmen TerraNet hat eine Möglichkeit entwickelt, mobile Kommunikation ohne ein herkömmliches Mobilfunknetzwerk umzusetzen. Die Handys werden dabei in ein Peer-to-Peer-System eingebunden und vernetzen sich untereinander, berichtet BBC online. Der Grundgedanke ist ein sogenanntes Mesh-Netzwerk, eine dezentralisierte Infrastruktur, bei der jeder Knoten - in diesem Fall sind es die Mobiltelefone - nur soviel Leistung bringen muss, um sich mit dem nächsten zu verbinden. Der größte Vorteil der Technologie ist, dass Gespräche durch die Umgehung eines Providers kostenlos geführt werden können.
Mesh-Technologie ist derzeit vor allem im WLAN-Bereich ein Hoffnungsträger. Mesh-fähige Geräte senden und empfangen Daten. Gleichzeitig nehmen sie Router-Funktionen wahr und leiten Daten an andere Clients weiter. Die Ingenieure wollen damit Funklöcher stopfen. Dieselbe Intention verfolgte Anders Carlius, der Gründer von TerraNet. Durch die Anwendung der Mesh-Technologie bei Mobiltelefonen, soll es selbst in Gebieten mit schwacher Mobilfunkversorgung möglich sein, Telefonate zu führen. Ein Anruf wird dabei solange von Telefon zu Telefon weitergeleitet, bis er das Zielgerät erreicht.
Projekte in Tansania und Equador
Carlius arbeitet seit 2002 an der Idee und konnte erste Projekte kürzlich in Tansania und Equador starten. Das System ist derzeit vor allem für Gebiete gedacht, in denen die Aufstellung von Basisstationen entweder nicht möglich oder schlicht unrentabel ist - beispielsweise in Wüstengebieten. "In manchen Gegenden in Afrika, Südamerika, Indien oder China können wir die Ersten sein, die den Menschen die Möglichkeit zur Kommunikation geben. Darüber hinaus gibt es noch eine Vielzahl an Möglichkeiten, unsere Technologie anzuwenden", meint Carlius gegenüber pressetext.
Sobald ein TerraNet-Gerät eingeschaltet wird, sucht es seine Umgebung im Umkreis von etwa einem Kilometer nach weiteren Geräten ab und verbindet sich mit ihnen. Somit wird das Netz mit jedem weiteren Gerät erweitert und die Abdeckung durch das Netz vergrößert. Ein Anruf in ein anderes, nicht direkt verbundenes Handy-Netzwerk soll über VoIP funktionieren. Dazu müsste lediglich ein Gerät pro Netzwerk mit dem Internet verbunden sein. Befindet sich das Zielhandy also nicht im eigenen Netz, wird der Anruf über das Web zum entsprechenden Mesh-Netz weitergeleitet.
Nur mit speziellen Handys
Derzeit funktioniert das TerraNet-System nur mit speziellen Mobiltelefonen. Allerdings hofft Carlius, dass die Technologie künftig ähnlich wie Bluetooth als zusätzliche Funktion in handelsübliche Handys integriert wird. Weniger angetan von der TerraNet-Idee sind laut Carlius die großen Mobilfunkprovider. Der TerraNet-Gründer liefert zugleich die Begründung: "Peer-to-Peer-Kommunikation im Mobilfunk könnte möglicherweise das Ende der GSM-Netze bedeuten." Die Technologie sei nicht ausgereift und funktioniere nicht, lauten die Gegenargumente, die Carlius jedoch nicht gelten lässt. Er verweist auf den Telefonhersteller Ericsson, der bereits drei Mio. Pfund (4,4 Mio. Euro) in TerraNet investiert habe.
Hey,
i tested this today (and fixed a 2 bugs regarding this ;), and that works. I used the same setup as you described, and when reassociating it kept pinging ... :) The host-announcements for the bridging are sent with the batman-packets, and it takes 1 second maximum for the ap node to make the first announcement when it got a new host. (But probably a little longer until the whole mesh-network knows). If you want to use this please use the batman-saxnet branch of batman-advanced for now until its merged back into the trunk.
Best Regards, Simon
On Thu, Sep 13, 2007 at 02:08:30PM +0800, 唐鼎 wrote:
hi! Dose the translation of batman-adv support fast roaming between batman nodes(every batman node has two wireless interface under a bridge,one works in ap mode,another works in adhoc mode for batman' routing)
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
hi! but 1 second delay is too long to some real-time applications. i have look insight the batman-adv code. caching source host's mac and originater's mac when batman node forwards a packet maybe is better way ----- Original Message ----- From: "Simon Wunderlich" simon.wunderlich@s2003.tu-chemnitz.de To: "The list for a Better Approach To Mobile Ad-hoc Networking" b.a.t.m.a.n@open-mesh.net Sent: Friday, September 14, 2007 2:46 PM Subject: Re: [B.A.T.M.A.N.] translation of batman-adv
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hey,
Yes we thought about that too (actually that was my first idea), but this might lead to inconsitency as not all hosts will get an update when a node moves but only those nodes which are on the way. Furthermore the packet reading (and cache updating) increases latency to forwarding. A solution might be to increase the rate in which batman-packets are sent (because then host announcement goes with them), or create a new packet type for announcement and send these more often. Both brings us much more noise in the mesh. I wonder if having a wifi-mesh is good for (hard?) real-time applications. Even reassociating to a new access point might take a few seconds (scanning & finding), or there is packet loss if you get out of the range from the previous ap until your wifi card changes to another AP.
Regards Simon
On Fri, Sep 14, 2007 at 03:11:35PM +0800, 唐鼎 wrote:
hi! but 1 second delay is too long to some real-time applications. i have look insight the batman-adv code. caching source host's mac and originater's mac when batman node forwards a packet maybe is better way
hi i have a question: when a node moved from one ap to another ap, will the two aps announce this node until the "previous node" age out? ----- Original Message ----- From: "Simon Wunderlich" simon.wunderlich@s2003.tu-chemnitz.de To: "The list for a Better Approach To Mobile Ad-hoc Networking" b.a.t.m.a.n@open-mesh.net Sent: Friday, September 14, 2007 4:03 PM Subject: Re: [B.A.T.M.A.N.] translation of batman-adv
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
A client node take its decision about chosing a gateway in a unilateral way, that is chosing gateway on a ranking basis (or wathever else) checking the path "node-->gateway" or "node-->hop-->gateway" (also if the second is not always preferred, chosing a poor link "node-->gateway" rather then best links "node-->hop-->gateway").
Presuming the node has a bouquet of canditate gateways: we can think to use an udp packet polling the candidate gateways and asking them "how you see me?" so the the node itself can obtain a path evaluation computed at gateway side and not only at node side. For example presuming node A can chose among gateways G1 and G2 (the candidate gateways) it will make its choice upon path evaluation:
A --> hops --> G1 A --> hops --> G1 where [hops] can be also 0 (no hops between A and Gn)
and computing OGMs coming from neighboors.
Well, node A can send two udp packet (same format as OGM but different op-code in payload||different dest port) to G1 and G2 asking to send their path evaluation like "G1 --> hops --> A" evaluation (received from candidate G1) and "G2 --> hops --> A" evaluation (received from candidate G2). In this way node A has a more clear vision about the entire path A <--> G_candidate and can take a more serious decision.
Using udp requests we introduce low latency than tcp and with a separate thread on gateway (with a poor resources consumpion) we can manage this task without effetcing the main.
What are you thoughts about?
-- Antonio
No,
the batman-adv currently has a timeout for client-macs of 5 minutes. But as soon as another new ap announce the mac as his node, the old ap will recognize this, update his table (remove the client-mac) and stop announcing it. So only the new ap will keep on announcing, not both.
Regards, Simon
On Fri, Sep 14, 2007 at 06:30:11PM +0800, ?? wrote:
hi i have a question: when a node moved from one ap to another ap, will the two aps announce this node until the "previous node" age out?
Hi Antonio -
your suggestion sounds reasonable and is worth thinking about. However I think this issue will become less important with B.A.T.M.A.N.-IV since it will massively improve the routing metric. I think it is fair enough that a gateway client will unilaterally choose the gateway - the number of OGMs received should provide enough information for the client to choose the right gateway.
cu elektra
A client node take its decision about chosing a gateway in a unilateral way, that is chosing gateway on a ranking basis (or wathever else) checking the path "node-->gateway" or "node-->hop-->gateway" (also if the second is not always preferred, chosing a poor link "node-->gateway" rather then best links "node-->hop-->gateway").
Presuming the node has a bouquet of canditate gateways: we can think to use an udp packet polling the candidate gateways and asking them "how you see me?" so the the node itself can obtain a path evaluation computed at gateway side and not only at node side. For example presuming node A can chose among gateways G1 and G2 (the candidate gateways) it will make its choice upon path evaluation:
A --> hops --> G1 A --> hops --> G1 where [hops] can be also 0 (no hops between A and Gn)
and computing OGMs coming from neighboors.
Well, node A can send two udp packet (same format as OGM but different op-code in payload||different dest port) to G1 and G2 asking to send their path evaluation like "G1 --> hops --> A" evaluation (received from candidate G1) and "G2 --> hops --> A" evaluation (received from candidate G2). In this way node A has a more clear vision about the entire path A <--> G_candidate and can take a more serious decision.
Using udp requests we introduce low latency than tcp and with a separate thread on gateway (with a poor resources consumpion) we can manage this task without effetcing the main.
What are you thoughts about?
-- Antonio
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
b.a.t.m.a.n@lists.open-mesh.org
-
?? -
a.anselmi＠oltrelinux.com -
elektra -
Simon Wunderlich -
thomasasta＠gmx.net -
唐鼎