i2p.www/www.i2p2/pages/how_peerselection_de.html

{% extends "_layout_de.html" %}
{% block title %}Wie die Auswahl der Knoten und Profiling funktionieren{% endblock %}
{% block content %}
<p>Die Webseite wird gerade &uuml;berholt und dieses Dokument kann alte Informationen enthalten</p>
<p>die Auswahl der Knoten in I2P ist einfach der Prozess in dem
der Router aussucht, &uuml;ber welche Knoten des Netzwerkes er unsere Nachrichten
sendet (welche Knoten um Teilnahme im Tunnel gefragt werden). Um dieses zu schaffen
beobachten wir, wie performant andere Knoten sind (die Knoten "Profile") und 
benutzen diese Daten um zu sch&auml;tzen wie schnell die Knoten sind, wie oft diese
unsere Anfragen akzeptieren k&ouml;nnen und ob sie &Uuml;berlastet sind oder
andersweitig nicht f&auml;hig sind, das Versprochene zu leisten.</p>
<p>
Beanspruchter Bandbreite wird nicht vertraut und wird <b>einzig und allein</b> 
benutzt um die Knoten zu vermeiden, die zu zu wenig Bandbreite anbieten um Tunnel
weiterzuleiten.
Die gesamte Auswahl der Knoten wird mit dem Profiling gemacht. Dieses macht
<a href="how_threatmodel.html#timing">Timing Attacken</a> noch schwieriger.</p>

<h2>Knoten Profile</h2>

<p>Jeder Knoten hat ein Set von Daten die von ihm gesammelt werden, inklusive
Statistiken &uuml;ber die Antwortzeit auf eine Netzwerkdatenbank Anfrage,
wie oft seine Tunnel nicht funktional sind und wie viele neue Knoten sie uns
mitteilen k&ouml;nnen. Auch einfachere Daten sind enthalten, wie etwa der
Zeitpunkt des letzten Kontaktes oder wann der letzte Fehler in der 
Kommunikation war. Die einzelnen gesammelten Datenpunkte k&ouml;nnen
im Monotone abgelesen werden (Link folgt).</p>
<!-- <a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/PeerProfile.html">code</a>
</p> --!>

<p>Momentan gibt es keine "L&ouml;schstrategie, um sich der Profile der Knoten
zu entledigen, die nicht mehr aktiv sind (oder wenn das Netzwerk aus tausenden
von Knoten besteht, die gering performanten Knoten zu entfernen). Jedenfalls
ist die Gr&ouml;sse der Profile recht klein und nicht damit verbunden, wieviele
Daten von dem Knoten gesammelt werden, so dass ein Router tausende aktive Knoten
Profile halten kann ohne das der Overhead ein ernstes Problem wird. Sobald es 
notwenig wird, k&ouml;nnen wir die schlecht performanten Profile kompakter 
machen (indem wir nur die n&ouml;tigsten Daten behalten) und k&ouml;nnen so
hundert tausende Profile im Speicher halten. Dar&uuml;br hinaus k&ouml;nnen
wir einfach Knotenprofile l&ouml;schen (z.B. nur die besten 100.000 behalten).</p>

<p>Die tats&auml;chliche Gr&ouml;sse der Knotenprofile im Speicher sollte
noch analysiert werden und ungebrauchte Daten sollten enfernt werden.
Dieses ist ein gutes Thema f&uuml;r weitere Nachforschungen und Optimierungen.</p>



<h2>Die wichtigen Daten der Knoten</h2>

<p>Die Profile k&ouml;nnen somit als eine Zusammenfassung der Performance
der Knoten bezeichnet werden, zu einer effektiven Auswahl der Knoten
fassen wir diese jedoch zu vier einfachen Werten zusammen. Diese stellen
die Geschwindigkeit des Knoten, seine Kapazit&auml;t, wie sehr er in das
Netzwerk integriert ist und ob er nicht funktioniert.</p>

<h3>Geschwindigkeit</h3>

<p>Die Berechnung der Geschwindigkeit (wie im Quellkode implementiert)
<!--
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/SpeedCalculator.html">here</a>) --!>
wird einfach mit den Profilen durchgef&uuml;hrt und sch&auml;tzt, wie viele
Daten wir durch einen einzigen Tunnel durch diesen Knoten in einer Minute 
senden oder empfangen k&ouml;nnen. Daf&uuml;r werden einfach die Werte der
Vergangenheit betrachtet.
</p><p>
Vorhergehende Algorhythmen brauchten viel l&auml;nger um mehrere
aktuellere Daten zu betrachten und daraus die Werte f&uuml;r die Zukunft
zu sch&auml;tzen. Ein weitere, &auml;ltere Berechnung nahm die gesamte
Bandbreite des Knoten (statt je Tunnel), jedoch stellten wir fest, das
diese Methode langsame Knoten mit hoher Kapazit&auml;t (das sind die mit
kleiner Bandbreite aber hohe Kapazit&auml;t in der Anzahl der Tunnel) als
zu hoch bewertete. Noch fr&uuml;herere Methoden waren noch komplexer.
</p><p>
Die derzeitige Berechnung ist seit Anfang 2006 unver&auml;ndert und ist
ein weiteres Gebiet zur weiteren Forschung um die Effektivit&auml;t auf
dem derzeitigem Netzwerk zu best&auml;tigen.
</p>

<h3>Kapazit&auml;t/h3>

<p>die Berechnung der Kapazit&auml;t <!--(as implemented 
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/CapacityCalculator.html">here</a>) --!>
bearbeitet die Profile und sch&auml;tzt wie viele von uns angefragte Tunnel
der Knoten in der n&auml;chsten Stunde akzeptiert. Daf&uuml;r betrachtet 
die Methode, wieviele Tunnel der Knoten in letzter Zeit akzeptiert hat, wie
viele er verneint hat und wie viele der akzeotierten Tunnel er abgebrochen
hat und extrapoliert die gew&uuml;nschten Daten. Zus&auml;ztlich gibt es
einen `Wachstumsfaktor` (falls der Knoten nicht inaktiv ist oder Anfragen
zur&uuml;ckweist), damit wir weiterhin versuchen, mehr Tunnel anzufragen. 
</p><p>
Die Abbruchquote der Tunnel war lange Zeit nicht aktiv in der Berechnung
der Kapazit&auml;t, erst mit 0.6.2 wurde sie wieder aktiv gesetzt. Es wurde
offensichtlich, das unzuverl&auml;ssige und nicht erreichbare Knoten
sicher erkannt und vermieden werden m&uuml;ssen f&uuml;r eine konstante
Nutzung des Netzwerkes.
Jedoch braucht der Tunneltest die Mitwirkung einiger anderer Knoten, somit
ist es schwer, die eindeutige Quelle der Fehler zu identifizieren.
Die letzten &Auml;nderungen geben jedem Knoten im Tunnel eine gewisse
Fehlerwahrscheinlichkeit und benutzen diese auch zur Kapazit&auml;tsberechnung,
Diese letzten &Auml;nderungen ben&ouml;tigen ggf, zus&auml;tzliche 
Feineinstellungen und sind auch ein Gebiet f&uuml;r weitere Forschungen
zur Effektivit&auml;t im aktuellem Netzwerk.
</p>

<h3>Integration</h3>

<p>Die Berechnung der Integration
<!-- (as implemented 
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/IntegrationCalculator.html">here</a>) --!>
ist nur f&uuml;r die Netzwerkdatenbank notwendig (und, falls eingebaut, zum
Erkennen und reparieren von Netzwerk`splits`). Zur Zeit wird es f&uuml;r nichts
benutzt, da der Kode zum Erkennen der Splits in gut verbundenen Netzwerken
nicht n&ouml;tig ist. Jedenfalls beh&auml;lt die Berechnung der Integration
die &Uuml;bersicht, wie oft uns ein Knoten einen uns unbekannten weiteren
Knoten mitgeteilt hat (oder die Daten f&uuml;r einen uns bekannten Knoten
aktualisiert hat).</p>

<p>
In kommenden Versionen wird diese Integrationsberechnung benutzt werden, in
Kombination mit anderen Methoden zur Berechnung der Konnektivit&auml;t und 
Zuverl&auml;ssigkeit der anderen Knoten. Daraus wird die F&auml;higkeit
des Knoten getestet, ein Floodfillrouter in der <a href="how_networkdatabase.html">Netzwerk Datenbank</a>
zu sein. Durch diesen Test, ob der Knoten ein sinnvoller Floodfill Router
ist oder nur so tut als ob, k&ouml;nnen sinnvolle Entscheidungen getroffen
werden zur Sendung und Speicherung von Datenbankanfragen an den Knoten.
Dazu k&ouml;nnen Knoten mit hoher Kapazit&auml;t, die noch keine Floodfill
Router sind, zu Floodfillroutern definiert werden, falls nicht genug
Floodfillrouter vorhanden sind im Netzwerk. Somit wird eine grosse
Schwachstelle im derzeitigem Floodfillsystem behoben.
</p>

<h3>Versagen</h3>

<p>Die Berechung zum Versagen
<!-- (as implemented 
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/IsFailingCalculator.html">here</a>) --!)
eines Knoten kontrolliert ein paar Daten aus den Profilen und erkennt, ob
der Knoten &uuml;berladen ist oder nicht seine Versprechen zum Tunnelaufbau
einhalten kann. Sobald ein Knoten als "Versager" gekennzeichnet ist, wird
er vermieden, wann immer das m&ouml;glich ist.</p>

<h2>Knoten Organization</h2>

<p>Wie oben beschrieben, gehen wir durch jedes Knotenprofil um ein paar
zentrale Berechnungen auszuf&uuml;hren und anhand diesen Ergebnissen 
sortieren wir die Knoten in f&uuml;nf Gruppen - fast, capable, well 
integrated, not failing und failing. Wenn ein Router einen Tunnel 
aufbauen will, nimmt er einen Knoten aus der "Fast" Gruppe, falls er
nur einen Testtunnel aufbaut, aus allen Gruppen, bis auf die "failing".
Innerhalb der Gruppen jedoch sucht der Router sich zuf&auml;llig einen
Knoten aus, damit die Last (und das Risiko) ausbalanciert wird. Auch 
verhindern wir damit einige einfache Angriffe.</p>

<p>Die Gruppierung ist nich exklusive und die Gruppen sind nicht ohne
Beziehungen zueinander: <ul> 
<li>Ein Knoten ist active, wenn wir in den letzten Minuten eine Nachricht von ihm
    erhalten oder an ihn gesendet haben</li>
<li>Ein Knoten ist "High Capacity", wenn seine Kapazit&auml;tsberechnung den
    Median aller aktiven Knoten &uuml;bertrifft.</li>
<li>Ein Knoten ist "Fast", wenn er "High Capacity" ist und seine Bandbreitenberechnung 
    den Median aller "High Capacity" Knoten trifft oder &uuml;bertrifft.</li>
<li>Ein Knoten ist "Well integrated", wenn seine Intigrit&auml;tsberechnung den 
    Mittelwert aller aktiven Knoten trifft oder &uuml;bertrifft.</li>
<li>Ein Knoten ist "failing",  wenn der Test auf Versagen "wahr" ergibt.</li>
<li>Ein Knoten ist "not failing", wenn er nicht "high capacity" oder "failing" ist.</li>
</ul>

<!--
These groupings are implemented in the <a 
href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/ProfileOrganizer.html">ProfileOrganizer</a>'s
reorganize() method (using the calculateThresholds() and locked_placeProfile() methods in turn).</p>
--!>

<h2>To Do</h2>

<p>Wie obenbeschrieben, ist jede dieser Berechnungen kritisch f&uuml;r die
Auswahl der Knoten und brauchen eine kritische &Uuml;berpr&uuml;fung auf
ihre Effektivit&auml;t im heutigem Netzwerk.
Auch muss die Gr&ouml;sse der Profile im Speicher noch betrachtet werden,
unn&ouml;tige Daten entfernt werden und eine Entfernungsstrategie
eingebaut werden.</p>

{% endblock %}