Anfragestrategie
Ähnlich wie bei den Algorithmen für das Entdecken von neuen Peers sind auch die Algorithmen für die Anfrage von Daten extrem wichtig. Hier gibt es wieder zwei grundlegende Möglichkeiten: der Empfänger kann die Daten analysieren, die er empfangen hat, und anhand dieser Daten neue Datenblöcken bei seinen Nachbarn anfordern. Bei der zweiten Möglichkeit bekommt der Sender von allen Empfängern eine Zusammenfassung der empfangenen Daten, und entscheidet dementsprechend, welche Daten er den Empfängern zukommen lässt. Dadurch wird die Logik des Empfängers extrem vereinfacht, weil er praktisch nur noch “dumm” die Daten empfängt. Nachteil ist allerdings, dass Synchronisierung unter mehreren Sendern notwendig ist, um das Senden vielfache Senden derselben Datenmenge zu verhindern.
Anfragestrategie heisst aber auch, welche Datenblöcke (ziemlich alle Verfahren teilen die zu versendende Datenmenge in kleinere Blöcke auf) in welcher Reihenfolge anzufordern sind. Empfangen zum Beispiel alle Knoten die Daten in derselben Reihenfolgen, bleibt kaum noch Spielraum übrig, um von mehreren Knoten gleichzeitig andere Daten zu empfangen um so den Durchsatz zu erhöhen. Weiter stellt sich die Frage, ob ein Knoten direkt nachdem er erfahren hat, dass es neue Daten gibt, diese anfordert (bzw. zugeschickt bekommt, je nach Anfragemodell)? Würde er ein bisschen warten, wäre es möglich, diese Daten auch bei anderen Knoten zu bekommen. Es muss also zwischen “Geschwindigkeit” und “Fairness” abgewogen werden.
Da mich P2P-Streaming mehr interessiert: bei Streaming fällt zumindest die Frage nach der “Frische” der Daten weg. Alle Knoten bekommen halbwegs dieselben Daten gleichzeitig, ein grosser Spielraum macht da kein Sinn, weil dann der Stream ja veraltet ist, und für Empfänger nicht mehr interessant. Streuen könnte man da höchstens innerhalb der “Pufferzeit”, also der Zeit, die von den Peers benutzt wird, um einigermassen viele Daten zusammen zu kriegen, damit der Stream nicht ruckelt. Ich meine auch, dass bei Streams ein Anfragemodell, wo die Empfänger die Sender fragen, nicht effizient ist (aber das wird sich noch reinstellen, dividuum ist da anderer Meinung, und im Moment funktioniert sein Ansatz deutlich besser :).
So, demnächst geht es weiter