*Text noch nicht fertig*

**** P2P : BitTorrent ****

Dies hier ist nahe verwand mit [Peerverse].

*** Idee 1 ***

Hier skizziere ich, wie ein ordentliches Distribution-Framework für BT (BTDF) aussehen könnte.

** Unbeschränkte unabhängige lightweight Komponenten **

BitTorrent braucht mehrere Komponenten.  Ein ordentliches BTDF muss deshalb aus unbeschränkten unabhängigen lightweight Komponenten bestehen:

- Alles kann zwar auch theoretisch auf einer Maschine laufen, aber alle Komponenten müssen so ausgelegt werden, dass sie redundant auf mehreren Maschinen laufen können.

- Es werden so gut wie keine Resourcen vorausgesetzt.  Die notwendige Infrastruktur (z. B. ein Apache+PHP oder Python, RAM und CPU natürlich) muss vorhanden sein, aber es sollte alles möglichst noch auf 128 MB RAM und Pentium 1-Rechnern ablaufen können.

- Es gibt keine Limitierungen.  So viel wie die Hardware unterstützt, so viel unterstützen die Komponenten.

- Nicht notwendige Bestandteile (MySQL) sind strikt zu vermeiden.  Embedded Datenbanken wie SQLITE (lokal, nur für die jeweilige Applikation) sind empfehlenswert.

- Abgesehen von einer einfachen textbasierten Konfiguration, die möglichst zentralisierbar sein soll, sollte es keine Grundlagen oder sonstige statische Informationen geben.  Weitere Informationen, wie z. B. die Liste der .torrents, sollten, wenn notwendig, in Textform vorliegen, oder ganz und gar auf der Basis des Filesystems ablaufen (Verzeichnis mit einem .torrent reicht aus, um das .torrent zu serven).

- Alles muss so "automagisch" wie möglich funktionieren.  Manueller Eingriff in die Abläufe soll möglichst nicht einmal bei Störungen notwendig werden (typischer Fall:  Eine Standleitung mit einem Seeder kommt runter, Seeder geht so "out of sync".  Soll sich automatisch beheben).

- Leicht verständlich, leicht nutzbar, leicht bedienbar.  Der Code kann beliebig kompliziert sein, aber die Administration muss so einfach sein wie möglich.

- Erweiterungsfähig nach außen:  Alle Schnittstellen müssen offen für andere Systeme sein.  So sind möglichst CSV (TAB-getrennt), XML und BT-interne Formate als Datenaustauschmittel anzubieten um zusätzliche Systeme (Webserver, Plattformen, etc.) anzubinden.

- Der Datenaustausch zwischen den Komponenten muss implizit und explizit lösbar sein.  Explizit bedeutet, dass man andere Transportwege (eMail, rSync, FTP, etc.) einbauen kann um die Datenintegrität zu gewährleisten.

- Die Kommunikationsschnittstelle muss explizit gelöst werden.  Es darf niemals eine direkte Kommunikation zwischen Komponenten und Clients existieren, sondern es gibt immer Transportprozesse, die diese Funktion übernehmen.  Die Idee ist, dass man z. B. nativ I2P oder SSH-Tunnel in jegliche Kommunikationsschicht einbauen kann ohne die Applikationen zu rekompilieren.


* Web Service: LOW *

Irgendwoher müssen die .torrent-Dateien stammen.  Dies ist meinstens ein Webserver.  Das BTDF soll selber keinen solchen Webservice zur Verfügung stellen.  Stattdessen aber folgende Teile:

- Ein Webbasiertes Status- und Verwaltungsfrontend.  Dieses ist nicht für den allgemeinen Anwender gedacht, sondern nur für die Leute, die das BTDF betreiben.

- Das Statusfrontend muss in der Lage sein, den Status des gesamten Verbunds zu überwachen, so dass man die Störung jedweder Komponente sofort sehen kann.

- Das Frontend muss Schnittstellen zur Veröffentlichung von diesen Informationen bieten.

- Der WebService wird dafür also ebenfalls CRON-Jobs laufen lassen, die aktiv Dinge überprüfen, z. B. eine RRDB zur Verfügung stellen.

Die Priorität für diesen Dienst ist LOW, sprich, er kann nach und nach entwickelt werden.  Für den Betrieb einer BTDP ist dieser Dienst nicht sofort notwendig.

Der Webservice soll auch später "lokal" laufen können, d. h. auf einem nicht öffentlich zugänglichen Webserver, der z. B. im Intranet steht.


* Tracker: LOWEST *

Der Tracker ist ein zentrales Utility für BitTorrent.  Inzwischen arbeitet BT zwar auch prinzipiell trackerlos, aber der Tracker stellt für die Content-Distribution zumindest in der Initialphase eines Downloads via BT ein wichtiges stabilitätsmerkmal dar.

- Er muss über mehrere Rechner splitbar sein, z. B. per Round-Robin-DNS.

- Es ist nicht notwendig, dass jeder Rechner in allen Swarms vorhanden ist.

- Der Tracker bindet die AutoSeeds ein (Permaseed ist ein Ausdruck vom Osprey-Projekt, und dieser Begriff passt leider nicht ganz).

- Der Tracker führt Buch über die Clients, und erkennt somit Clients mit geringer Bandbreite im Downlink (Clients im Desparate Mode), asymmetrischen Verbindungen (DSL), High Capacity Uplinks (Seeds) oder Distributionsknoten (AutoSeeds).

- Der Schwarm wird durch die Tracker dann in mehrere Teile geteilt, so dass Clients mit geringer Bandbreite nur wenige Verbindungen zu leistungsstarken anderen Peers bekommen, ggf. direkt an einem AutoSeed hängen.

- Der Tracker monitort außerdem den "Progress" der Clients, und gibt so Hints an die AutoSeeds.

Der Tracker hat LOWEST priority.  Es gibt ausreichend Tracker, die zwar das hier geschriebene nicht können, aber die reine Funktion erlauben.  Für den Anfang reicht ein Tracker, dem man automatisch (per Shell-Script, möglichst per "cp") .torrents unterschieben kann.

* AutoSeed: HIGHEST *

Dies ist die zentrale Komponente.  Sie macht die BTDP aus, da sie anlaufstelle der Clients ist.  Folgende Punkte sind zu lösen:

- Kanalisierung:: Die Connects der Clients werden kanalisiert, so dass der Rechner, der die Verbindungen bekommt, nicht mit dem Rechner, der die Verbindungen verwaltet identisch sein muss.  Ziel ist, dass Konzentratoren "millionen" von Connects verarbeiten, und diese über wenige Tunnel an den AutoSeed weiterreichen der dann die Buchhaltung macht und die Daten über die Kanäle verschickt.  Zweite Idee ist, dass man so nativ Protokolle wie I2P anschließen kann, ohne den AutoSeed verändern zu müssen.

- Upload:: Es muss möglich sein, die Daten über den Schwarm direkt in den AutoSeed hochzuladen.  Die Idee dahinter ist, wenn der AutoSeed aus irgendeinem Grund die Daten verliert (Platte wird getauscht) muss er die Daten wieder anfordern.  Der Datentransfer ist dabei idealerweise natürlich BitTorrent von einem anderen AutoSeed (oder aus dem Schwarm).  Der PermaSeed von Osprey kann das beispielsweise nicht.

- DataStore:: Die Datenhaltung vom AutoSeed muss von dem Seed-Prozess unabhängig sein.  Ein AutoSeeder kann also z. B. die Dateien, die er seedet, per FTP anfordern.  Sind die Daten derzeit nicht verfügbar seedet der AutoSeed eben einfach diesen Teil nicht.  Er akzeptiert aber trotzdem die Verbindung für den .torrent!

- Unlimitiert:: Der AutoSeed kennt keine Limits in Sachen wieviele .torrents oder Clients er bedient.  Milliarden inaktiver .torrents müssen so möglich sein.  Sobald ein Client den .torrent anfordert, seedet der AutoSeed diese Datei.  Das dauert ggf. etwas, bis die Daten vom DataStore angefordert werden.  Für eine BTDP ist das kein Problem.  Der Tracker kann Meldungen verbreiten, die die Clients darauf hinweisen, dass der Download vielleicht erst in 24h beginnen wird.

- Fair:: Die AutoSeeds dienen nicht unbedingt dazu, maximale Downloadraten zu erreichen.  Dafür kann nämlich ein Schwarm sorgen.  Das Ziel ist Fairness.  So versorgt der AutoSeed Clients im Desparate Mode mit Priorität, und seedet .torrents mit möglichst wenig Overhead.  Das bedeutet, er schickt nicht möglichst kleine Datenmengen an möglichst viele Clients (das erzeugt viel Overhead bei den Clients), sondern nimmt sich reihum die Clients vor, und gibt ihnen dann eine volle Breitseite an Datendurchsatz, wobei Schwärme mit wenig Clients favorisiert werden.

- Für die Steuerung dieser Priorisierung ist ein spezielles Handling mit dem Tracker erforderlich, da die Tracker evtl. ja die Swarms partitioniert haben, und der AutoSeed somit nicht über ausreichend informationen verfügt.

Ansonsten verhält sich ein AutoSeed wie jeder ganz normale BT-Client, mit dem Unterschied, dass er aufgrund der Kanalisierung über endlos viele IPs verfügen kann.

* DataStore: MEDIUM *

Der DataStore ist eine unabhängige Komponente.  Die Priorität ist MEDIUM, weil es in die Entwicklung vom AutoSeed hineinspielt.

- Initial wird der AutoSeed nur über einen lokalen Cache verfügen, in dem die Dateien zwischengelagert werden.  Der DataStore selber ist nicht verfügbar.

- Der DataStore kann auf einen beliebigen Rechner ausgelagert werden, und spricht dort ein beliebiges Subsystem (Filesystem, FTP, etc.) an.

- Mehrere AutoSeeds können zum DataStore verbunden sein, und jeder AutoSeed kann zu mehreren DataStores verbunden sein.

** Fazit **

Ich muss mit dem AutoSeed beginnen.  Dieser AutoSeed besteht also aus folgenden Komponenten:

- BT Library:: Im Unterschied zu allen BT-Libraries die es gibt, brauche ich eines, dessen IO-Routinen vollständig virtualisiert sind, damit die Kanalisierung funktioniert.

- Filesystem Cache:: Dies ist ein Verzeichnis, in das die Dateien von den .torrents gespeichert werden.  Da dies am Anfang alles ist, was ich habe, kommt es dem Verzeichnis eines FTP-Servers gleich, in dem allerdings die Dateien unter speziellen Strukturen (eben zur Verwaltung der .torrents) liegen.

- 

* BT-Library *

  Für jeden Connect wird so ein Objekt aufgebaut, das den Client verwaltet.