Mini-Storage-Grid crowdsourced
Ich habe eine verrückte Idee, und ihr sagt mir ob wir das umsetzen können oder nicht. Dabei bin ich auf eure Mitarbeit angewiesen, denn das verrückte daran ist dass es ein verteiltes System sein soll, wobei jeder seinen Client selbst bauen wird (Crowdsourcing).
Also, wir brauchen Speicherplatz, den gibt es da draußen zuhauf, meist auch kostenlos, bei einem Anbieter, „in der Cloud“ oder auch als Peer-to-Peer Grid, ich weiß. Aber es gibt sicher noch kein Speicher-Grid das nur aus unterschiedlichen Nodes besteht. Jeder von euch, der mitmachen möchte, muss sich seinen eigenen Client basteln, theoretisch egal in welcher Programmiersprache. Natürlich müssen die Clients miteinander Daten austauschen, in diesem Fall eure Dateien. Wir brauchen als ein möglichst kleines effizientes Protokoll, mit dem man sich finden und Daten austauschen kann.
Dabei denke ich an folgendes:
- Erstmal braucht man eine Verbindung zu mindestens einem anderen Node, sodass man beginnen kann ein Netz aufzubauen mit allen anderen Nodes. Am Anfang verbindet man sich also zu 1-2 hardcodierten IP-Adressen und fragt diese Nodes nach weiteren IP-Adressen anderer Nodes. So kann man sich nach und nach das Grid aufbauen bis man alle anderen kennt.
- Wer seine Dateien (wir können das ja am besten auf maximal 100KB beschränken) in das Grid hochladen möchte zerteilt sie in maximal 50KB große Teile (Chunks), sucht sich minimal 2 verschiedene andere Nodes und lädt diese Teile hoch.
- Wer möchte kann (und sollte?) die Datei natürlich vorher entsprechend verschlüsseln wenn es private Dateien sind, das ist aber jedem selbst überlassen. Wer etwas Ausfallsicherheit haben möchte lädt diese beiden Chunks bei jeweils 2 oder 3 Nodes hoch, falls mal einer Offline geht.
- Wer seine Dateien wiederhaben möchte sucht sich die entsprechenden Nodes wieder und lädt die Dateien wieder runter und baut sie wieder zusammen.
Die Frage ist, was brauchen wir noch alles? An was sollten wir alles denken? Eine Versionierung wäre eventuell nicht schlecht, da wir sicherlich das Protokoll mit der Zeit weiterentwickeln werden. Wir könnten uns überlegen ob wir auch IPv6 fähig sein wollen. Wir könnten uns überlegen auch eine Art Quota einzubauen: Nur wer selbst 10MB Speicher zur Verfügung stellt darf seinerseite 10MB hochladen (wie macht man das in einem Netz ohne Master-Node?). Wir könnten natürlich auch viel Intelligenz in das Netz einbauen: Wenn ein Node und damit seine Chunks offline gehen, muss der andere Node, der diese Chunks auch noch hat, dafür sorgen dass es wieder 2 Kopien dieser Chunks im Grid gibt. Oder aber der Node, der offline geht, nutzt seine letzten 10 Sekunden noch dafür dass seine Chunks redundant im Netz vorhanden sind und lädt nochmal schnell ein paar Chunks hoch. Und und und.
Aber erstmal geht es um die Basics, sprich nach dem Start andere Nodes finden und Chunks hoch- und runterladen können.
Könnte ein interessantes Projekt werden, jeder kann in seiner Lieblingssprache (oder in der Sprache die er schon immer mal lernen wollte) mitmachen, was denkt ihr?
Nennen wir es Napster!
joghurtKULTUR
23 Aug 11 at 08:45
Hi Michael,
das klingt ziemlich interessant. Hier mal meine Ideen dazu:
Es sollte beim Protokoll Service-Calls und Function-Calls. Service Calls wären das „Finden“ anderer Knoten, bzw. auch die Gelben Seiten. D.h. es muss möglich sein, wenn man einen Knoten gefunden hat, diesem alle selbst bekannten Knoten mitzuteilen und auch alle dem anderen Knoten bekannten Knoten abzufragen. Natürlich immer mit einem Zeitstempel der letzten „Sichtung“ eines Knotens.
Die Function-Class selber machen den Dateitransfer mit Checksum und das zusammenfinden. Vielleicht sollte auch jeder Knoten seine eigene Verfügbarkeit bekanntgeben können a la 24/7 oder wochentags, bzw. es sollte eine Bewertung der Transfergeschwindigkeit von und zu einem Knoten in anderen Knoten gespeichert werden. Damit vermeidet man, dass ein Knoten immer sagen kann, er ist super erreichbar und flott angebunden, sondern jeder andere Knoten, der schon mal eine Verbindung mit dem Knoten hatte kann die Antwort liefern.
Das Speichern und lesen selbst ist auch nicht ganz ohne, denn wie finde ich meine Dateiteile wieder? Eine Möglichkeit wäre, eine Liste von Hash-Summen der Teile beim Urknoten zu hinterlegen. Jeder Knoten kann dann mittels dieser Hash-Summe angefragt werden und die Datei notfalls liefern. Somit wäre auch eine weitere Verteilung möglich, ohne dass man dies beim Upload bereits mitteilen müßte.
Also ich wäre gern dabei. Wir haben auch genug Server mit Speicher, wo ich 10MB immer mal abzwacken kann 😉
Robert
23 Aug 11 at 09:15
Genau da haben wir es doch. Wenn ein Chunk offline geht und das evtl. nicht mal freiwillig, kann dieser doch die Chunks nicht mehr hochladen und die Files sind für immer hinüber.
Vllt wäre da eher so eine Technik brauchbar, wie sie bei Raids eingesetzt wird -> Paritäten. Nachteil ist, dass man zwingend eine bestimmte Anzahl von Nodes braucht außerdem ein Nachteil ist: was passiert, wenn zu viele Nodes offline gehen? Dann sind auch hier die Paritäten nutzlos.
Mindestens einen Master wird es immer geben müssen. Im Torrentnetzwerk ist das afaik ja auch nötig für Magnet Links. Wenn ich das richtig verstanden habe, funktioniert das hier wie bei DNS. Man fragt bei seinem Server an, wenn der es nicht kennt, fragt dieser bei seinem an, etc.
Die Serverliste, die die Nodes kennt, kann ja immer komplett (auch hier wie bei DNS) an die Clients weitergeleitet werden.
Das Hochladen / Runterladen sollte absolut kein Problem sein denke ich. Meiner Meinung ist die Überlegung viel wichtiger, wie man eine Ausfallsicherheit ermöglichen kann. Überlegung hier: Bewertungssystem für Erreichbarkeit. Ab hier kann man dann weiter spinnen.
Sascha
23 Aug 11 at 09:18
Robert, es ist erschreckend, wie völlig unterschiedliche Menschen die selbe Idee haben können! 😀
Sascha
23 Aug 11 at 09:20
Hi,
also ich finde das Projekt sehr interessant, ich stelle mir das als eine Art P2P-Dropbox mit Verschlüsselung vor, aber das lässt sich auch noch diskutieren 😉 Ich wäre auf jeden Fall dabei, ich denke das sinnvollste wäre es, eine Google Group o.ä. aufzumachen, wo man entsprechende Konzepte diskutieren kann, denn die Kommentar-Sektion eignet sich nicht für eine geordnete Diskussion zu verschiedenen Themen.
T-Moe
23 Aug 11 at 09:24
Wenn du 100%-ige Ausfallsicherheit bieten kannst, wird das was. Ansonsten würd ich mich gar nicht erst die Mühe machen mit dem Projekt zu starten.
Und ich würde keine Dateien in dieses Netzwerk hochladen… (geschweige denn einen Client schreiben)
rniederer
23 Aug 11 at 09:37
klingt stark nach der Wuala Cloud 😉
Falls es wirklich jemand umsetzen möchte: es gibt die eine oder andere wissenschaftl. Publikation über Wuala
Tobias
23 Aug 11 at 09:38
wie tobias schon sagte: siehe wuala
außerdem: http://en.wikipedia.org/wiki/Freenet 😉
und das meiste von dem was du erwähnst kann man sich bei gnutella, bittorrent und emule abschauen 🙂
sciuto
23 Aug 11 at 09:43
Also ich wäre sicher mit einem Clienten dabei, wenns ne zugehörige Doku zum gewählten Protokoll und der Umsetzung gibt.
Flyingmana
23 Aug 11 at 10:10
Ich bin für eine Mischung aus Wuala und Syncany!
Wäre auch mit einem Client dabei. Mach doch mal ne Google-Gruppe auf oder so…
DeDu
23 Aug 11 at 10:40
Natürlich sind mir Wuala und Freenet bekannt, aber Wuala ist glaube ich nicht Open Source und Freenet ist zu kompliziert um „mal eben“ einen Client zu schreiben.
Was hier erreicht werden soll ist etwas mit Netzwerkcode zu experimentieren, ein kleines Protokoll zu entwickeln, schauen was passiert wenn jeder Node von einer anderen Person entwickelt wird, und vielleicht in sehr ferner Zukunft ein nutzbares Produkt. Man könnte sich ja durchaus vorstellen solche Nodes auf mehreren Servern zu installieren, eine Authentifizierung davorzubauen und es als Storage-Cloud zu verkaufen, theoretisch möglich aber natürlich sehr kompliziert. Oder aber man baut eine Art Gateway, der Node speichert seine Chunks nicht auf der lokalen Festplatte sondern beispielsweise bei Dropbox, im Google Storage, auf FTPs oder sonstwo, möglich ist vieles. Mit speziellen Supernodes, die immer eine Kopie aller Chunks haben (ähnlich Wuala), aber mit niedriger Priorität befragt werden kann man natürlich für Datenverfügbarkeit sorgen. Durch clientseitige Verschlüsselung, für die man selbst verantwortlich ist und die auch jeder unterschiedlich machen kann hat man die Sicherheit seiner Daten selbst in der Hand.
Je mehr solche unterschiedlichen Nodes es gibt umso resistenter und ausfallsicherer wird das ganze Grid, und wir alle lernen ziemlich viel dabei (hoffentlich). Und man hat die Chance eine neue Sprache zu lernen, beispielsweise Erlang, Go, C#, Python, Perl, Haskell, node.js, Java, ObjectiveC, C++, , was auch immer. Ich würde es glaube ich in PHP und mit einem node.js Client probieren.
Syncany kannte ich noch nicht, werd ich mir mal genauer anschauen!
Also das Storage-Grid ist nur ein Vorschlag, wir können auch ein dezentrales Nachrichten-Netzwerk aufbauen oder ein dezentrales soziales Netzwerk oder etwas völlig anderes, her mit euren Ideen!
Wie soll die Google Group denn heißen?
Michael Kliewe
23 Aug 11 at 11:38
Um eine 100% Aufallsicherheit zu gewährleisten müßte jeder Client über alle Daten verfügen.
Wenn also ein Client eine Datei angebotenbekommt muss er Sie an die Ihm bekannten Clients weiterreichen. Das dürfte schnell zu ner vollen Platte führen.
Wenn wir jetzt mit Paritäten arbeiten müssten nur noch diese verteilt werden und dass am besten noch komprimiert.
Um eine zentrale Anlaufstelle für die Clients werden wir wohl nicht herumkommen, da ansonsten wahrscheinlich mehrere Einzelnetze ohne Schnittmengen entstehen würden. Hier würde es aber reichen wenn der Master eine XML Datei bereitstellt von allen Client IPs die angefragt haben.
Wo die Daten letztendlich lagern (FTP/Google Storage/etc) ist ja wiederum Aufgabe des Client.
Die Daten die ein Client aber speichert sollten aber auf jeden Fall verschlüsselt sein, damit sich der Nutzer des Clients bei illegalen Inhalten nicht strafbar macht. Sei es nur eine Copyrightgeschützte MP3 Datei die bei dem Client liegt, von anderen Verstößen nicht zu reden.
Oliver
23 Aug 11 at 13:40
Man könnte doch zum Beispiel Twitter als Master verwenden. Das Protokoll müsste dann so aufgebaut sein das es aus Befehl + Wert kleiner als 140 Zeichen besteht.
Kommandos die Über Twitter abgesetzt werden:
SYNC: 192.168.178.1
ADD: 105.124.002.045
DEL: 120.025.205.235
Kommandos die von Node zu Node abgesetzt werden:
PUSH: /data/file.txt
DROP: /data/file.txt
Christian Kaps
23 Aug 11 at 14:31
Das mit Twitter umzusetzen ist eine echt witzige Idee. Dann könnte man automatisch den Protokoll-Log abonnieren und alles mit verfolgen können 😉
Da gab es doch die neue Möglichkeit der Bild-Posts…das könnte man ja für Dateien allgemein nutzen.
Aber Spass beiseite, die Grundidee der Verfügbarkeit und die Datensicherheit sind die zentralen Knackpunkte – ich denke, das hat sich gezeigt. Wenn die Verwaltung dieser Themen gelöst ist, ist das reine Dateihandling recht einfach und komplett irrelevant für das Grid, weil Client-Aufgabe.
Robert
23 Aug 11 at 14:59
Äußerst interessante Idee … würde ebenfalls daran etwas mitarbeiten und einen Client erstellen.
Aber man merkt ja schon, wie unterschiedlich die Vorstellungen der einzelnen Leute sein können. Eine Diskussionsplattform wäre also sehr hilfreich (Google Gruppe wurde ja bereits mehrfach angesprochen).
Bei einem solchen System wäre für mich wichtig:
– Verschlüsselung aller Daten (da reicht ja eine Clientseitige Lösung ggf.)
– hohe Verfügbarkeit
– Sicherheit vor Manipulationen (z.B. darf kein „böser“-Client in irgendeiner Weise dafür sorgen, dass woanders Daten gelöscht werden oder man manipulierte Daten anstelle der korrekten erhält, o.ä.)
– Möglichkeit zum restlosen Entfernen meiner Dateien (wenn ich Dateien lösche, müssen sie auch von allen Nodes verschwinden oder zumindest unbrauchbar gemacht werden können (z.B. durch Zerstörung von Schlüsseln o.ä.). Das halte ich allerdings für äußerst schwer realisierbar. Problematisch wird es spätestens, wenn die Lösch-Anweisung nicht alle Nodes erreicht und somit das Grid nach und nach mit „toten“ Daten zugemüllt wird.)
Ich habe mir früher mal Gedanken über ein ähnliches System gemacht, in dem Daten relativ einfach verteilt gespeichert werden sollten. Darin wurde dann mit Paritätsinformationen gearbeitet. Um es vereinfacht auszudrücken: Im Prinzip eine Art Raid 5 im Netzwerk. Eine funktionierende Anwendung wurde hierzu aber nie entwickelt.
Die Idee Twitter als Master zu verwenden finde ich sehr gut. Alternativ würde mir auch IRC oder Jabber einfallen. Aber auch hier muss natürlich ein Schutz vor Manipulation gewährleistet werden können.
Tim
23 Aug 11 at 16:22
„Also das Storage-Grid ist nur ein Vorschlag, wir können auch ein dezentrales Nachrichten-Netzwerk aufbauen oder ein dezentrales soziales Netzwerk oder etwas völlig anderes, her mit euren Ideen!“
Das schöne daran ist, wenn man ein Protokoll fürs Storage hat, also Datein austauschen kann, dann kann man auf basis dessen auch ein dezentrales Nachrichten-Netzwerk aufbauen. Soziales Netzwerk wäre dann auch nur einen Schritt weiter.
Statt twitter könnte man auch identi.ca bzw. jedes mit der darunter liegenden Software status.net laufende verwenden. Twitter wurde für ähnliches ja auch schon im Bereich von Botnetzen genutzt in der Vergangenheit. (selbe Idee und Ziel)
Flyingmana
23 Aug 11 at 17:13
Dann können wir ja gleich die Twitter-Bilderfunktion nutzen und die Informationen mittels Steganographie unterbringen *facepalm*
Also von einem externen Kanal für die Informationsübertragung halte ich garnichts.
Thorsten Häuser
23 Aug 11 at 17:13
> Also das Storage-Grid ist nur ein Vorschlag, wir können auch ein dezentrales Nachrichten-Netzwerk aufbauen oder ein dezentrales soziales Netzwerk oder etwas völlig anderes, her mit euren Ideen!
Das Social-Network klingt doch toll 🙂 Wie Diaspora nur in PHP/MySQL, so dass es jeder nutzen kann.
Chris
23 Aug 11 at 20:20
Dezentrales Messaging: XMPP
Ich denke die Variante mit dem auslagern von Dateien ist ganz cool und werde ich wohl als erstes Node.js Projekt versuchen.
Sascha
23 Aug 11 at 20:25
OKAY, Google Group erstellt:
http://groups.google.com/group/mini-storage-grid
mini-storage-grid@googlegroups.com
Also einfach beitreten und mitmachen!
Michael Kliewe
23 Aug 11 at 21:52
Finde die Idee eigentlich ziemlich genial und wäre mit Sicherheit (sofern eine vernünftige Dokumentation des Protokolls da ist) mit einem eigenen Client dabei. Wahrschienlich in C# oder PHP. Um mich in etwas völlig neues einzuarbieten fehlt mir momentan einfach die Zeit.
Christoph
23 Aug 11 at 23:09
Coole idee! Glatt mal der Gruppe beigetreten, so als fun für nebenbei 🙂
Ole
24 Aug 11 at 23:01
Ich sehe in der Idee keinen Unterschied zum Kad-Netzwerk von eMule. Da werden letztendlich auch Dateien in ein loses Netzwerk geschoben und mehrfach verteilt.
Der einzige Unterschied zum Kad-Netzwerk ist, dass dort ein Nutzer aktiv eine Datei anfragt und damit shared. Bei der neuen Idee muss die Datei aktiv in die „Cloud“ geschoben werden.
Wobei ich den Nutzen aber noch nicht verstehe. Wenn ich selber 10 MB bereit stelle um dann 10 MB zu nutzen… Da kann ich doch auch selber meine eigenen 10 MB nutzen? 😉
Ich sehe den Vorteil auch wirklich eher in einer Art Cloud-Dropbox.
Sven
29 Aug 11 at 11:39
An eine Art Cloud-Dropbox hatte ich am Ende auch gedacht. Ähnlich Wuala, aber quelloffen und ohne Firmenserver die auch juristisch angreifbar wären (USA PATRIOT Act und co.).
Markus
30 Aug 11 at 21:26
Und, seid ihr schon fertig? ^_^
Bin heute über folgendes gestolpert:
http://www.aerofs.com/
Dom
20 Sep 11 at 13:39