Zusammenfassung

  • BitTorrent verlagerte einen großen Teil des ausgehenden Verkehrs beliebter Dateien vom Herausgeber zu den Downloadenden. Webserver, Tracker und der erste vollständige Seed blieben Teil der Verteilung.
  • Cohens reziprokes Choking war eine Client-Strategie, keine vom Wire-Protokoll vorgeschriebene Pflicht. Ein Peer konnte mehr hochladen, als er erhielt, nur den eigenen Download ausreichend unterstützen oder die Freigabe beenden.
  • Eine Studie von 2007 zeigte, dass strategische Clients ihren Upload senken und gleichzeitig ihre eigene Leistung steigern konnten. Die Ergebnisse gelten für die damals untersuchten Swarms und Messbedingungen, nicht für jede spätere Umgebung.

Nicht jede Kopie muss vom Ursprung kommen

Bei einem herkömmlichen HTTP-Download sendet der Ursprungsserver jede Kopie. Wird eine Datei plötzlich populär, muss ihr Herausgeber mehr Ausgangskapazität bereitstellen oder längere Wartezeiten hinnehmen. Bram Cohen beschrieb 2003 eine andere Arbeitsteilung: Laden mehrere Personen dieselbe Datei gleichzeitig herunter, tauschen sie Teile untereinander aus und tragen so selbst zur Auslieferung bei.

Der Effekt ist eine Verlagerung der Kapazität. Der Herausgeber stößt die Verteilung an, aber nicht mehr jeder Datenstrom muss allein von seinem Server kommen. Cohen argumentierte, dass sich so auch sehr beliebte Dateien erschwinglich anbieten ließen, besonders dort, wo der Upload der Nutzer nicht nach Datenvolumen abgerechnet wurde. Das ist eine bedingte Aussage. Ein unlimitierter Tarif macht weder Netzkapazität noch Strom und Betrieb kostenlos, und nicht jeder Anschluss wird gleich abgerechnet.

Auch die Ausgangsseite bleibt konkret. Der Herausgeber legt eine .torrent-Metadatendatei auf einem gewöhnlichen Webserver ab; ein Tracker hilft den Downloadenden, Peers zu finden; ein Seed mit der vollständigen Datei muss die Verteilung starten. Cohen beschreibt den Bandbreitenbedarf von Webserver und Tracker als gering im Vergleich zum Dateitransfer. Der Seed muss trotzdem mindestens eine komplette Kopie aussenden. BitTorrent verteilt den größten Datenstrom neu, aber es beseitigt den Ursprung nicht.

Deshalb wäre „kostenloses Hosting“ eine zu weit gehende Zusammenfassung. Der Herausgeber kann weniger Bytes senden, doch die Auswirkung auf seine Rechnung hängt von Preisen, Kapazitätsgrenzen, tatsächlichen Peer-Uploads und der Dauer des Seedings ab. Die Arbeit verschwindet nicht; ein Teil der Zustellung wandert zu den Teilnehmenden und ihren Anschlüssen.

Gegenseitigkeit ist keine Zuteilung

Cohen beschreibt Peers, die anhand ihres jüngsten Downloads auswählen, an wen sie senden. Diese Variante von Tit-for-Tat nutzt Choking: Ein Client kann den Upload zu einer Verbindung zeitweise unterbrechen, ohne den Download von dort zwingend zu beenden. Ein optimistisches Unchoke probiert regelmäßig einen bisher ungenutzten Peer aus. So kann sich eine bessere Verbindung zeigen, statt dass nur bekannte Gegenleistungen belohnt werden.

Die technische Grenze ist wichtig: Cohen schreibt ausdrücklich, dass der Choking-Algorithmus nicht zum BitTorrent-Wire-Protokoll gehört. Das Protokoll ermöglicht den Austausch von Daten und Signalen; die Entscheidung, welche Gegenstelle ein Client bedient, bleibt eine lokale Implementierungspolitik. Wer sagt, das Protokoll garantiere Gegenseitigkeit, verwechselt beides. Verfügbare Dateiteile, wechselnde Verbindungen, Unterschiede zwischen Clients und freie Upload-Kapazität bestimmen die tatsächlichen Tauschbeziehungen.

Der Herausgeber entscheidet, ob er BitTorrent einsetzt; die Nutzer entscheiden sich dafür, weil sie die Datei haben möchten. Cohen betonte zudem, wie stark die einfache Bedienung – Link anklicken, Speicherort wählen – zur Verbreitung beigetragen haben könnte. Sie könne wichtiger sein als Leistung und Kostenverteilung. Ein Anreizsystem hilft nur, wenn die Teilnahme praktisch genug ist.

Der Gegenversuch von 2007

Michael Piatek, Tomas Isdal, Thomas Anderson, Arvind Krishnamurthy und Arun Venkataramani prüften 2007 erneut, ob Anreize BitTorrent robust machten. Ihre Modellierung auf Basis realer Messspuren ergab, dass Peers Ressourcen beitrugen, die ihre eigene Leistung nicht unmittelbar verbesserten. Mit BitTyrant entwickelten sie einen strategischen Client, der aktive Peer-Gruppen und Upload-Raten so anpasste, dass er mit weniger Upload mehr Download erreichen konnte.

Die Zusammenfassung der USENIX-Konferenz nennt für einen 1-Mbit/s-Client in den untersuchten Live-Swarms einen medianen Leistungsgewinn von 70 Prozent. Zugleich warnten die Autoren, eine flächendeckende Nutzung strategischer Clients könne die durchschnittliche Leistung pro Swarm gegenüber den getesteten Implementierungen verringern. Das stellt die Annahme infrage, Tit-for-Tat allein sichere robuste Beiträge. Es misst weder alle späteren Clients noch heutige Swarms; die 70 Prozent sind keine allgemeine Geschwindigkeitszusage.

Der Unterschied liegt zwischen einer Regel, die Austausch organisiert, und einer Regel, die Beiträge erzwingt. Gegenseitigkeit konnte nützliche Uploads belohnen. Optimistische Tests und unterschiedliche Anschlusskapazitäten ließen aber auch Beiträge übrig, die sich nicht direkt auszahlten. Ein strategischer Client konnte versuchen, diesen Spielraum zu nutzen. Ob viele solcher Clients einen bestimmten Swarm schwächen würden, hing vom Verhalten der Peers und der verbleibenden Kapazität ab.

Vollständigkeit braucht weiterhin einen Träger

Der Herausgeber setzt die Verteilung in Gang, indem er Metadaten bereitstellt, einen Tracker oder eine andere Peer-Suche erreichbar hält und einen vollständigen Seed startet. Danach bestimmt jeder Client selbst, wie viel er beiträgt. In Cohens Entwurf verteilt keine zentrale Instanz verbindliche Upload-Anteile an die Beteiligten.

Das bringt Skalierungsspielraum, aber auch eine Versorgungslücke. Der Herausgeber muss nicht die gesamte Ausgangskapazität allein kaufen; Nutzer können selbst bestimmen, wie lange sie weiter seeden. Doch das Protokoll schafft keine dauerhafte Upload-Versorgung. Verlässt der Seed das Netz, bevor alle Teile verbreitet sind, oder trennt sich der letzte Peer mit einem seltenen Teil, kann die Datei unvollständig werden. „Rarest first“ hilft, knappe Teile früh zu vervielfältigen. Es kann ein Teil aber nicht zurückholen, wenn seine letzte Kopie verschwunden ist.

Die Betriebsfrage lautet deshalb nicht, ob BitTorrent Hosting „gelöst“ hat. Zu messen ist, welcher Anteil des Verkehrs noch vom Ursprung kommt, wie viel die Peers wirklich übernehmen und was eine vollständige Kopie erhält, wenn die Nachfrage abebbt. Cohen machte Downloadende zu möglichen Verteilerknoten. Die spätere Forschung zeigt, warum man diese Kapazität beobachten muss, statt sie vorauszusetzen.

Quellen