User Tools

Site Tools


Sidebar

**The OOBD Book** Download as [[epub|eBook]] \\ Download as [[https://drive.google.com/folderview?id=0B795A63vSunRbk1jc3U5VFFJbkU&usp=sharing|PDF / Mobi]] * [[start|Documentation]] * Installation * [[startup_javame|OOBD-ME (Mobile Phones)]] * [[startup_android|OOBD-Android]] * [[startup_windows|Windows OOBDesk]] * [[startup_embedded|Raspi & Co]] * [[startup_usage|Start the programs]] * [[startup_oobdscript|First Success: Run the OOBD script]] * [[lua_start|Lua in OOBD]] * [[tools_quickscript|Click your Script: Quick Script]] * [[lua_make-your-own-scripts|Make your own OOBD Scripts]] * [[lua_tutorial|The OOBD Lua Tutorial]] * [[lua_make|Lua Build Enviroment]] * Web UI * [[:de:doc:webui_tutorial|Web User Interface Tutorial(German)]] * [[webui_guide|Web UI Package structure]] * [[:de:doc:webui_simulator|UI Emulator for development(German)]] * [[hw_start|The OOBD Hardware]] * [[hw_quickstart|OOBD Cup Quick Start]] * [[hw_assembly-cupv5|Build your own Dongle]] * [[hw_busswitch|Add a second Bus to DXM]] * [[hw_bootloader|Flash the Bootloader]] * [[hw_firmware|Flash the Firmware]] * [[hw_flash-from-usb-stick|Flash the Firmware from USB-Stick]] * [[hw_commands|The Firmware Commands]] * [[tools_start|The OOBD Utilities]] * [[tools_kadaver|Kadaver]] * [[tools_quickscript|Quick Script]] * [[tools_cortex-crc32|Cortex-CRC32]] * [[tools_filelist|Filelist]] * [[tools_olp|OLP]] * [[tools_oobdcopyshop|OOBDCopyShop]] * [[tools_oobdtemple|oobdtemple]] * [[tools_oodbcreate|OODBCreate]] * [[tools_opendiagx|OpenDiagX]] * [[tools_oobdcmd|OOBDcmd]] * [[tools_oobdflash|OOBDFlash]] * PGP * [[pgp_setup|Install PGP Keys]] * [[dev_start|Development]] * [[dev_googlesetup|Join the News]] * Setup your Developer Environment * [[dev_cygwininstall|CygWin Environment]] * [[dev_setupswing|Java Swing]] * [[dev_setupme|Java ME]] * [[dev_setupandroid|Android]] * [[dev_androidlivecd|The Android Debug Live CD]] * [[dev_setupfirmware|Firmware]] * [[dev_clientdesignguide|User Interface Design Guide]] * [[dev_systemspec|The OOBD System Spec]] * [[dev_readotherformats|Import XML files]] * [[dev_links|Link Collection]] * [[dev_roadmap|Road Map]] * [[rfc_start|Specifications (RFC)]] * [[rfc_firmware_syntax|OOBD Firmware: General Command Syntax]] * [[rfc_canuds-mode|OOBD Firmware: Protocol : UDS (P 6 ..)]] * [[rfc_canraw-mode|OOBD Firmware: Protocol : CANraw (P 6 ..)]] * [[rfc_rtd-real-time-data-protocol-for-the-oobd-firmware|OOBD Firmware: Protocol : Real Time Data (RTD) (P 6 ..)]] * [[rfc_pgp-encrypting-sensible-data-with-pgp|PGP Principle]] * [[rfc_onion|The ONION Message Format]] * [[faq|Frequently Asked Questions]]

doc:rfc_oobdp2p

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

This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information
doc/rfc_oobdp2p.txt · Last modified: 2014/10/19 17:35 by admin