User Tools

Site Tools


doc:rfc_oobdp2p

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

doc:rfc_oobdp2p [2014/10/19 17:35] (current)
admin created
Line 1: Line 1:
 +FIXME this is just the copy of a worksheet yet, nothing more
 +
 +
 +P2P filetransfer wird  aus vielen Gründen von der IT nicht geduldet. Ein dezentraler Fileaustausch als solches muss aber nicht schlecht sein, wenn es darum geht, eine variable Anzahl von Geräten mit Updates zu versorgen.
 +
 +Dies soll ein Versuch sein, ein Protokoll zu definieren, was auch die Zustimmung der IT finden könnte.
 +
 +
 +Es besteht im Prinzip aus einem Mechanismus zur Erzeugung von Public Keys zur Unterschrift,​ einem TCP Chat und jeder Menge Logik aussenrum.
 +
 +Der Ablauf ist folgender:
 +
 +Im Prinzip werden von ausgewählten Verteilern (Distributoren) Verzeichnisse bereit gestellt, die von Abnehmern (Clients) abgeholt werden. Dabei wird auch der Versionsstand mit übertragen,​ jeder Client weiß also, welche Version er hat.
 +
 +Initialisierung:​
 +Der Distributor benennt das Verzeichnis,​ was er verteilen möchte. Er erzeugt geschützt durch ein Passwort einen Public und Secret key.
 +
 +Das Programm erzeugt eine Datei, die die Liste der zu verteilenden Daten und ihres Hashwertes enthält, den Public key und die IP Nummer der Distributor- Maschine, sowie eine digitale Unterschrift der Liste. Der Public key in seiner Hex-Notation identifiziert diesen konkreten Verteiler.
 +
 +Diese Datei wird beim allerersten Anlauf per Email an alle interessierten Clients verteilt.
 +
 +Der Client nimmt dann per TCP- Chat Verbindung mit dem Distributor auf und fragt die aktuelle Liste und den Versionszähler des durch den Public Key (PK) identifizierten Verteilers an. Wenn die Version des Distributors höher ist als die eigene, fährt er fort. Nachdem er die Liste anhand der digitalen Unterschrift und des PKs auf Gültigkeit geprüft hat, lässt er sich die Daten übertragen,​ die er nicht schon aus der vorhergehenden Version hat (erkennbar an den Hasswerten) und speichert diese in einem versteckten Unterverzeichnis des Zielverzeichnis . Nach Erhalt der Dateien berechnet er den Hashwert der Daten neu und überprüft diese mit denen aus der Liste. Wenn alles richtig ist, überträgt er die empfangenden Daten aus dem versteckten Unterverzeichnis ins eigentliche Empfangsverzeichnis und geht nun davon aus, die neue Version zu besitzen.
 +
 +Während der Übertragung hat er vom Distributor auch eine Liste erhalten, welche anderen IP –Nummern schon mit dem Distributor kommuniziert haben.
 +
 +In regelmäßigen Abständen, z.B. einmal die Stunde, bzw. wenn gerade eine neue Version empfangen wurde, klappert der Client diese bekannten IP Adressen ab und tauscht sich aus, welche Versionsnummern die anderen besitzen. Hier wiederholt sich das gleiche Spiel: Wer die höhere Versionsnummer hat,  liefert die Daten an den anderen, ebenfalls mit einer Liste der ihm bekannten IPs.
 +
 +
 +So erhält jeder Client relativ schnell die neuen Daten und auch einen Gesamtüberblick (IPs), welche anderen Clients beteiligt sind.
 +
 +
 +Neue Versionen: Die Clients, deren User den Secret Key und das Passwort besitzen, können neue Versionen erzeugen: Sie tauschen die Dateien auf ihrer Platte aus (der jeweilige Vorgängerstand sollte immer in einem versteckten Verzeichnis erhalten bleiben, um versehentliche Fehler rückgängig machen zu können), erzeugen sich eine neue signierte Liste und geben sich bei Anfragen gegenüber anderen Clients als jemand mit höherer Versionsnummer auf. Das löst dann den allgemeinen Updatezyklus aus.
 +
 +
 +Und was soll hieran jetzt besser sein als an anderen P2P Solutions? Gute Frage, ich hoffe es sind Punkte , die eine IT akzeptiert:
 +
 +
 +-          Es findet kein UDP Broadcast statt, also kein Herumschleudern von netzweiter Anfragen auf der Suche nach anderen Teilnehmern
 +
 +-          Es wird nur zwischen IP Adressen kommuniziert,​ die sich selber vorher angemeldet haben, also kein planloses Befunken unschuldiger IP- Adressen
 +
 +-          Das Protokoll ist so offen, das jeglicher Funkverkehr mitgehört werden kann.
 +
 +-          Das geht sogar so weit, dass das Protokoll es zulassen würde, das Clients sich in mehr und mehr Übertragungen einklinken, sobald sie über den Verteilermechanismus an neue IP- Nummern rankommen. Sie würden dann alle Daten sammeln können. Dies muß aber ebenfalls nicht schlecht sein, weil dort dann z.B. die Inhalte zentral auf Viren oder auf neueste Kinoproduktionen untersucht werden können. Gleichzeitig aber arbeiten dann diese von der IT aufgestellten Fallen als zentrale Server, nutzen also den Anderen
 +
 +
 +
  
doc/rfc_oobdp2p.txt · Last modified: 2014/10/19 17:35 by admin