<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">Am 14.09.2015 um 22:38 schrieb Tim
Niemeyer:<br>
</div>
<blockquote cite="mid:1442263101.19110.86.camel@mastersword.de"
type="cite">
<pre wrap="">Am Montag, den 14.09.2015, 22:29 +0200 schrieb DelphiN:
</pre>
<blockquote type="cite">
<pre wrap="">Wow. OK, dass ging jetzt schnell.
Ich denke auch, das wir broadcast filtern sollten, würde mir aber die
Implementierung nochmal gern genauer anschauen und ggf. sogar in einem
etwas größeren Kreis diskutieren.
Ist das OK, wenn ihr mit dem patch noch ein paar Tage wartet?
</pre>
</blockquote>
<pre wrap="">Ja, auch ich möchte da gern bisschen Feedback haben. </pre>
</blockquote>
Mein bescheidenes Feedback, wenn es dem Netz erstmal deutlich hilft
(ich persönlich kann es nicht wirklich einschätzen) sollten erstmal
gefiltert werden (danke nochmal an die Erklärung in der U-Bahn da
hab ich eigentlich erst begriffen was das Broadcastproblem genau
ist). Rückgängig kann man das ganze ja immer machen wenn die
Ressourcen mal da sein sollten (was vermutlich nie der Fall ist ;)).<br>
<blockquote cite="mid:1442263101.19110.86.camel@mastersword.de"
type="cite">
<pre wrap="">Mit einigen Leute
habe ich bereits direkt darüber diskutiert, wobei die Diskussionen nie
abgeschlossen wurden. Am liebsten wären mir auch einige Tests, ob
grundsätzlich das Netzverhalten (abgesehen der beschriebenen
Eigenschaften) noch korrekt geht.
Allerdings würd ich ungern monatelang damit warten wollen, zumal der
Feedback bereits in der Vergangenheit oft immer eher rar gesegnet war.
Letztlich haben wir ja immer auch die Möglichkeit das wieder
rauszuwerfen, wenn irgendein Problem damit auftritt oder wir es einfach
nicht mehr haben wollen.
</pre>
<blockquote type="cite">
<pre wrap="">Danke schon mal, Tim!!
</pre>
</blockquote>
<pre wrap="">Gern.
Tim
</pre>
<blockquote type="cite">
<pre wrap="">DelphiN
Am 14. September 2015 22:14:21 MESZ, schrieb Tim Niemeyer
<a class="moz-txt-link-rfc2396E" href="mailto:tim.niemeyer@mastersword.de"><tim.niemeyer@mastersword.de></a>:
Ich weiß, Filter sind böse. Trotzdem sollten wir diesen Schritt in
Erwägung ziehen, insbesondere durch das zuletzt stark gestiegene
Traffic Aufkommen.
Was wir verlieren werden ist tatsächlich (sofern die Filter fehlerfrei
laufen) überschaubar. Immerhin haben wir ja bereites einen Broadcast
filternden Mechanismus, in dem wir die Hoods gebaut haben. Über die
Hoods hinweg funktionieren Broadcasts nicht. So lange man sich innerhalb
einer Hood bewegt funktionieren allerdings solche Dinge wie Zeroconf
oder ähnliches mit diesen neuen Filtern nicht mehr.
Auch wenn es ein kleiner Schritt gegen die Freiheit innerhalb der Hoods
ist, halte ich sie für notwendig. Unsere Gateway Server verbrauchen
trotz der Hoods mehrere TerraBytes im Monat an Traffic, wobei ein
Großteil unnötiger Traffic ist.
Mit dem Pico-Peering ist das Verfahren mMn vereinbar, da nicht der
Traffic der
Peering Partner gefiltert wird. Lediglich der in das
Mesh-Netzwerk ein- und ausgehende Traffic ist gefiltert. So lange also
z.B. ein Knoten ohne Filter verwendet wird, bleiben auch Zeroconf
Dienste erhalten.
Tim Niemeyer (1):
firewall: filter broadcasts
bsp/default/root_file_system/etc/firewall.user | 89 +++++++++++++++++++++++++-
1 file changed, 88 insertions(+), 1 deletion(-)
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>