Das Protokoll

[Michael Kliewe]

Ich finde es ähnlich wie Christian Kaps es schon schreib: Je einfacher
je besser. Ähnlich wie beim memcached-Protokoll sollten wir erstmal
mit sehr einfachen Befehlen wie HELO, SYNC, ADD, DEL, GETLIST, UPLOAD,
DOWNLOAD etc. anfangen.

Unsere erste Aufgabe ist also uns auf ein Protokoll in Version 1 zu
einigen. Wir brauchen als eine Nummerierung. Natürlich könnten wir es
einfach V1, V2 etc. nennen. Eventuell sollten wir aber auch in
Betracht ziehen dass es mal Forks oder ähnliches gibt, sodass wir zwei
Versionen 23 haben, einmal die Version der Gruppe A und einmal die der
Gruppe B. Deshalb würde ich vorschlagen wir geben dem Protokoll noch
einen zweiten Parameter, beispielsweise so:

VA1
VA2
VA3

Ich denke wir sind uns einige dass wir über TCP Verbindungen reden,
wir brauchen also einen Port den wir standardmäßig nutzen. Natürlich
kann man später auch einen beliebigen nehmen (z.B. Port 80 um durch
Firewalls durchzukommen ;-) . Aber erstmal sollten wir uns einen
Standardport ausdenken.

Sobald wir diese Fragen geklärt haben können wir denke ich einen neuen
Thread starten speziell zur Version 1 des Protokolls, wo wir dann die
einzelnen Befehle festlegen, um ein Peer-to-Peer Netz aufzubauen.
Dinge wie "Hallo, ich bin Node X, (ich gehöre meinem Besitzer Y), ich
spreche die Protokolle V4 und V5, gibt mir mal deine Liste deiner
Nachbarn, (lass uns ab jetzt verschlüsselt kommunizieren wenn du das
kannst)" und sowas, also wirkliche Basics um überhaupt ein Netzwerk zu
erstellen und miteinander kommunizieren zu können. Wenn das erledigt
ist und soweit funktioniert kämen als zweites dann Dinge wie "hier ist
meine Liste der Hashes die ich kenne, gib mir mal deine Liste" etc.

Was denkt ihr?

[Christian Kaps]

Kann dem nur übereinstimmen. Erst klein anfangen und dann langsam aufbauen. Was ich aber auch wichtig finde, ist das man erst mal die Grundstruktur des Systems bespricht. Master(ja/nein), wenn ja was für ein System(Twitter, geschlossenes System, ...).

Gruß Christian

[Sascha Ohms]

Porttechnisch können wir theoretisch alles oberhalb von 49151. Diese sind nicht bei der IANA registrierbar und sind somit definitiv von nichts offiziellem genutzt. Ich meine, aktuell sind das alles nur Spinnereien, was bedeutet, dass der Port sowieso erstmal egal ist. 60000 kann sich z.B. jeder gut merken und ich wüsste aktuell nichts, was den belegt. Ebenfalls ist damit das Root-Problem erst mal gelöst.

Was die Versionisierung angeht, sollten wir dann doch eher sowas wie V1a, V1b etc verwenden. Damit kann man wohl noch etwas mehr anfangen und rein nach der Versionisierung macht das auch Sinn. So könnte man alle Forks z.B. später zu V2 mergen.

Zur Grundstruktur: keine externen Text-Only Dienste nutzen! Ich mein, die Streaming API ist genial und um es mal ganz frei zu sagen: scheiße schnell, aber ich bin dagegen. Twitter hat API Limits und wenn mal wieder ein Whale vorbei schaut, wars das komplett mit unserem Dienst. Ich wäre für das Funktionsprinzip von DNS ( rein logisch gesehen jedenfalls). Was natürlich voraussetzt: Wir brauchen Master Server. Aber ernsthaft. Wenn das Protokoll sauber ist und der Server nicht gleich wegen 2k Anfragen offline geht, kann man ja immernoch mit Redundanz arbeiten.

Nun ist die Frage, wie man sowas auf unser System ausbreitet. Bei DNS gibts immerhin Root-Server für die bekannten TLDs. Sowas hätten wir hier ja z.B. nicht.

Mfg
Sascha

[Robert Kummer]

Also ich würde nichts gegen Master haben. Allerdings sollte es so
sein, dass es nicht nur einen Master gibt, sondern unendlich viele
Master grundsätzlich geben kann. Ein Master könnte dabei eine
erweiterte Funktionalität im Vergleich zu normalen Nodes anbieten.
Bspw. Dienstequalität von normalen Nodes, keine Dateiaktivitäten,
lediglich Auskunftswesen a la, wo kann ich Datei XY finden,
Verfügbarkeitsstatistik, freier Speicher von diversen Nodes, welche
Master und Nodes kenne ich denn so.

Als Datentransfer auf ein Kommando würde ich eine Struktur wie JSON
oder XML bevorzugen, weil dann eine Versionserweiterung leichter eine
Abwärtskompatibilität ermöglichen kann. Neue Keys/Tags werden dann
einfach nicht interpretiert in Clients, die geringere
Protokollversionen unterstützen.

Kommandos a la HELO, SYNC, usw. finde ich ausreichend. Es sollte nur
grundsätzlich die Möglichkeit geben Parameter zu übergeben.

Bei der Verschlüsselungsanfrage würde ich auf das HTTP-Protokoll
hinweisen. Dort ist es ja üblich, dass ein Browser mitteilt, dass er
bspw. eine GZIP-Komprimierung entpacken kann. Erst nach dieser
Bekanntgabe kann der Server entsprechend sinnvoll GZIP-Content senden.
Wenn unser Node auf eine Anfrage entsprechend mitteilt, welche
Verschlüsselungsmethoden es kann und welche Dateiübertragungen er kann
(GZIP, TGZ, ZIP, 7Z, ...), dann sind partielle Chunks weniger
problematisch.

[MKuckert]

Ich halte ein an HTTP-angelehntes Format am sinnvollsten. Die
Aufteilung in einfache Schlüssel-Werte-Paare als Header, die Angabe
einer Adresse, das Standardformat für die Version und der vom Header
sauber getrennte Body sind Anforderungen für jedes Protokoll und mit
HTTP erfolgreich im Einsatz. SIP hat das Format kopiert und ist damit
ebenfalls sehr erfolgreich. Ist das Protokoll nah genug an HTTP wäre
das Bedienen des Netzes per Webbrowser oder einfachem HTTP-Client
sogar möglich, wenn ein Node entsprechend tolerant ist.

Mögliche Anfragen an Hosts wären dann solche Geschichten:
DOWNLOAD /file-signature protokoll/1.2.3
…

mit einer Antwort:
protokoll/1.2.3 200 Download
Content-Length: 12312312
…

Dann gilt es das Problem zu lösen, dass sich Nodes im Netz anmelden
und andere Nodes mit gesuchten Chunks finden können müssen. Hier
kommen wir um eine zentrale Registry wohl nicht umher. Da könnten wir
auch wieder bei SIP schnüffeln - hier sind Registry-Server am Client
konfiguriert, die die Nodes zu gesuchten Chunks finden. Hierzu meldet
sich jeder Node bei seiner Registry an und nennt die bekannten Chunks.
Die Anmeldung wird in regelmäßigen Intervallen bestätigt (Hallo, ich
bin immer noch da) und Änderungen mitgeteilt. Geht der Node
kontrolliert offline, meldet sich dieser an der Registry ab - oder die
Anmeldung verfällt nach einer gewissen Frist (analog der Lease Time
bei DHCP). Der Masterknoten kann erkennen, wenn Chunks nur wenig im
Netz verteilt vorhanden sind oder ein früher erfolglos gesuchter Chunk
wieder verfügbar ist und dafür sorgen, dass andere Knoten diesen Chunk
ebenfalls vorrätig halten sollen (zur Not per Download vom Node und
Upload bei einem anderen Node). Da das ganze Dezentral laufen soll
kann auch jeder seine eigenen Masterknoten aufstellen. Um das eigene
Netz mit anderen Netzen verknüpfen zu können werden die Masterknoten
"per Hand" miteinander bekannt gemacht oder über eine Registry für
Masterknoten. Die Belastung dieser Registry wäre verhältnismäßig
gering, da es hier um reine Registrysuchen geht.


On 23 Aug., 22:20, Michael Kliewe <michael.kli...@googlemail.com>
wrote:

[corvus]

On 23 Aug., 22:20, Michael Kliewe <michael.kli...@googlemail.com>
wrote:

> Wenn das erledigt
> ist und soweit funktioniert kämen als zweites dann Dinge wie "hier ist
> meine Liste der Hashes die ich kenne, gib mir mal deine Liste" etc.
>
> Was denkt ihr?

kleiner ideeneinwurf bezüglich der chunksize.
da könnte man sich ja am bittorrent protokoll ideen holen. denn da
gibts ja die torrentfiles (in denen grob gesagt die einzelnen chunks
drin stehen) und da hat man sich auch gedanken dazu gemacht.
denn mit fixer chunksize geben große files große hashlisten und die
verteilung der liste dauert länger da die mehr infos übermittelt
werden müssen.

hier ist kurz beschrieben was ich meine: http://wiki.vuze.com/w/Torrent_Piece_Size

[MKuckert]

Das Torrent-Format hat bestimmt einiges an Ideen, die übernommen
werden können. Die Grundidee dürfte dabei aber sein, dass eine Datei
in mehrere Chunks zerteilt wird und zu diesen eine Liste erstellt
wird. Die Liste enthält die Reihenfolge der Chunks und deren
Signaturen. Dann muss irgendwie markiert werden, wo der Chunk abgelegt
wurde. Muss dieser Hinweis die Adresse des Zielnodes sein? Oder eines
Registry-Knoten, an dem die Chunks und deren Speicherort bekannt
gemacht werden? Damit der speichernde Node die Chunks später auch
wiederfinden kann, nachdem der Chunk evtl. auf anderen Nodes
repliziert wurde und der eigentliche Zielknoten nicht mehr verfügbar
ist.


Im Grunde besteht das Protokoll aus mehreren Teilen:
- Kommunikation zwischen hochladendem und speicherndem Node
- Kommunikation zwischen Node und Masterknoten (Suchen von Chunks,
An-/Abmelden von Nodes, Änderungen an Chunks (neu, gelöscht, ...))
- Kommunikation zwischen Masterknoten?!
- Format der Chunklisten

Für die Kommunikation ist im Grunde ein gemeinsames Protokoll mit
entsprechenden Nachrichten möglich.

[Markus]

Wo der abgelegt wurde, hmm muss das rein? Kann doch der Masterserver
bzw die Nodes suchen, wer weis schon wo das später landet? Vielleicht
auch ähnlich dem freenet routing (benötigt keinen Master)?
Rein müsste auf jeden Fall Version, Client-Signatur (Signaturkette der
Nodes?), Daten-Hash, Datengröße
(variable Chuck-Größen?), Nutzdaten, gewünschtes Verfallsdatum (siehe
Müllentsorgung)
Es wird dann einfach bei den Nodes (Routing) oder bei einem Master
angefragt wer ist on und hat Chuck mit Datengröße xy und Hash xyz.
-> Node zyx, zyx2, ...
-> ggf Check ob Node vertrauenswürdig
-> dort anfragen und schicken lassen
Soll die Liste in der die Infos zu den Chucks stehen auch ins Grid
oder nur beim Client bleiben?

[corvus]

die frage die sich mir gerade stellt.

wer soll zuständig sein für das verteilen der chunks auf die nodes?

1) sollte der client seine chunks an einen master senden der die
chunks dann auf die nodes verteilt und sich eine liste erstellt auf
welchem node welches chunk geladen wurde?
2) sollte der client selber seine chunks X-mal hochladen auf
verschiedene nodes und dies info auf welche nodes er geladen hat einem
master mitteilen?
3) soll der client einem/mehreren node(s) seine chunks geben und der/
die node(s) verteilt danach auf andere nodes und teilt die info der
verteilung einem master mit?

1 hätte den vorteil das master ja eher gut angebundene server sind
(sein sollten) und somit die info auf welchem node sich welcher chunk
befindet sofort verfügbar ist und die verteilung der chunks auf andere
nodes sind schneller
2 hat den nachteil das man seine datei dadurch mehrmals uploaded. wenn
man nur eine langsame internetverbindung hat kann das hochladen recht
lang dauern. bei 1 müsste der client die chunks nur einmal uploaden.
3 könnte das gleiche problem haben wie 2

[corvus]

zu 2)
mit multicast könnte man dem problem entgehen das der client die
chunks mehrmals hochladen muss. ein chunk hat mit multicast gleich
mehrere empfänger :)
ob und wie einfach sich das implementieren lässt sollte man noch
prüfen...

[corvus]

Hab mal ne Tabelle gemacht mit den Funktionen von Master, Node und
Client.
Ideen, Verbesserungen, Ergänzungen?

Wie der Client die Chunks verteilt oder ob das ein Master/Node macht
hab ich mal nicht berücksichtigt...

https://docs.google.com/spreadsheet/ccc?key=0AmjrxHrtGkjfdEJhS3VEMndFU0J1QVY0cWt5dVNWSkE&hl=de

[Markus]

Theoretisch ja, praktisch ist das gewaltiger Aufwand und würde auch
ein generellen Wechsel von TCP auf UDP (nochmal Zusatzaufwand für
Fehlerkorrektur etc) erfordern. Damit dürften sich die wenigsten
auskennen. Also imho nichts für uns. ;-)

[Markus]

Auf den ersten Blick schaut schon mal ganz gut aus denke ich.
Vielleicht noch irgend eine Art von "Hello" Client->Node?

> https://docs.google.com/spreadsheet/ccc?key=0AmjrxHrtGkjfdEJhS3VEMndF...

[Markus]

Die Kommunikation zwischen den verschieden Stellen soll auch
verschlüsselt erfolgen, denk ich?

Wollten wir da was eigenes basteln oder gibt es da was leicht zu
nutzendes bestehendes? Was meint ihr zu

OpenSSL zum Beispiel in PHP: http://www.php.net/manual/en/book.openssl.php

Wie sieht das in anderen Sprachen aus, Lizenzen? Es sollten ja
unterschiedliche Clienten werden.

Direkt damit verbunden wie sollen sich ein Teilnehmer gegenüber den
anderen ausweisen? Der RSA-Algorithmus ist eigentlich ausreichend,
denk ich.
http://de.wikipedia.org/wiki/RSA-Kryptosystem
Müsste es auch fertige Bibliotheken geben.

Wuala verwendet zum Beispiel zur Authentifizierung 2048 bit RSA
Signaturen, AES128 zur Datenverschlüsselung und SHA256-Hashes der
Datenpakete.
Sowas in der Art müsste eigentlich "schnell" machbar sein. Muss ja
nicht gleich ausarten, sonst werden wir nie fertig. ^^

[Markus]

Ich wäre auch für das JSON - Datenformat.. Ist auch leicht
interpretierbar und der Overhead hält sich in Grenzen.
Anfragen was der Node überhaupt unterstützt müsste man natürlich auch.
Deswegen der Vorschlag vorher ein "Hello".
Nicht das man den Node mit nicht implementierten Features oder neuen
Protokollen belästigt mit dem er nichts anfangen kann.

[Markus]

Keine Einwände? Auch gut. :-)

Werde die Tage mal ein experimentelles Protokoll fertigstellen, damit
man endlich mal anfangen kann.