[Berlin-wireless] olsrd-bmf plugin / mDNS plugin

[Henning Rogge]

Am Dienstag 15 Dezember 2009 16:16:46 schrieb Alexander Morlang:
> Am 15.12.09 09:54, schrieb Rolf Pfeiffer:
> > Nochmal im Ernst: in einem Funkmesh ist einiges anders. ZB ist es
> > normal, dass geforwardete Multi-/Broadcasts mehrfach empfangen werden.
> 
> ...
> 
> > Es mag Szenarien und Anwendungen geben, wo Multicast diesen ganzen foo
> > wert ist. Aber dann möchte ich vorher eine quantitative Abschätzung oder
> > Simulation sehen. Zum "einfach Ausprobieren" ist das Schadenspotential
> > einfach zu hoch - imho -
> 
> Danke für den diskussionsansatz, tatsächlich bin ich trotz aller
> begeisterung für service discovery nicht besonders glücklich mit dieser
> implementation, da sie halt mDNS nur relayed, statt selbst zu
> implemetieren um eine tabelle des states der anderen zu pflegen, um
> requests selbst beantworten zu können.
Eine angepasste Mesh-Implementation die nach außen "Zeroconf" spricht wäre 
natürlich optimal.

> allerdings gibt es einige grundannahmen, bei denen ich auch skeptisch bin:
> * es ist nicht gut, wenn service discovery bandbreite ver(sch)wendet.
> 
> Es ist super, wenn unsere bandbreite verwendet wird, um die
> kommunikation innerhalb des meshes zu fördern, immerhin ist es so, das
> internet zugang nur ein service ist, aber intranet die kernfunktion. ein
> intranet ohne service discovery bringt nichts, daher halte ich es sogar
> für gut, wenn wir dafür bandbreite verwenden.
Ohne Service-Discovery ists schwierig das Netz für viel mehr als "Gateway zum 
Internet" zu nutzen...

> * die annahme, das man es irgendwie "regeln" kann:
> 
> Sorry, vergiss es, pico peering basiert auf zensurfreiem routing und
> freiem peering. Wenn du filterst, dann agierst du ausserhalb des
> freifunk. Dann machst du filterfunk, nicht freifunk.
> 
> Wenn du unter technischem Vorwand nutzdaten filterst, und genau das ist
> mDNS, dann bist du nicht besser als die, die wir kritisieren (und
> teilweise bekämpfen)
Das mDNS-Plugin zu "bremsen" oder zu "blocken" ist ohne eine Modifikation des 
OLSRd sowieso nicht drin... außer man schreibt nen OLSR-Proxy.

IPTables ist dafür zumindest ungeeignet.

Das BMF hingegen basiert sowieso darauf das auch der lokale Knoten das BMF 
installiert hat.
 
> Also, preventive verbote, forderung von Bremsen, genaustes evaluieren
> statt probieren sind die natürlichen feinde der freifunk community.
> 
> Wehret den anfängen, bleibt wach, seid neugierig.
> 
> mit wprobe und tcpdump kann man paketanteile und airtimeverbrauch
> abschätzen, das ist viel besser als bremsen und verbote zu fordern.
ich bezweifle das tcpdump da die Anzahl der relevanten Pakete ermitteln kann, 
da sie mit den normalen OLSR-Messages zusammen in gemeinsamen UDP-Paketen 
kommen. Zumindest beim BMF.

Henning
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 198 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20091215/8586424c/attachment.pgp>