[Berlin-wireless] olsrd-bmf plugin / mDNS plugin
Alexander Morlang
alx
Di Dez 15 16:16:46 CET 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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.
* 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)
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.
>
> Rolf
>
Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksnqF0ACgkQhx2RbV7T5aF4FgCcD3Z1iLIMyeNPLKHcp90k0hux
5QgAn3RhHTTs+nM/BNuB7DpFQkW40eLn
=EOjn
-----END PGP SIGNATURE-----
Mehr Informationen über die Mailingliste Berlin