Eigene Cloud Lösung: Server Client Kommunikation

  • Ersteller Ersteller ph1lipp
  • Erstellt am Erstellt am
P

ph1lipp

Gast
Hallo,

wie der Name schon sagt, würde ich mich gerne ein wenig näher mit Server-/Clientkommunikation beschäftigen. Man findet ja oft ein Standardbeispiel und das in allen möglichen Programmiersprachen. Das ist hier nicht die Frage, die hab ich schon gemacht und auch verstanden.

Mir geht es viel mehr darum, wie kommunizieren die beiden nach Verbindungsaufbau miteinander.

Ich habe mir folgendes vorgestellt:
Ich habe eine Serversoftware auf einem Linuxsystem und die Clientanwendung läuft auf einem Android Gerät. Dementsprechend der Androidteil in Java, der Serverteil in C(oder Vala), schlimmstenfalls auch Java(aber sollte ja eigentlich egal sein).
Der Client verbindet mit dem Server, es findet ein Login statt, danach werden Dateien synchronisiert.
Jetzt findet man dazu aber recht wenig.
Werden die Daten dann einfach linear nacheinander als string/binary gesendet, so nach dem Motto "Login: MeinName, Passwort: pipapasswort", Server filtert dann die Variablen raus und überprüft, sendet danach ein OK, danach kommt die Anfrage ala "sendedaten" und dann sendet der Server halt die Dateien in Binärform.

Ersteinmal natürlich die Frage: Ist das so überhaupt sinnvoll? Oder geht es besser? Gibt es da opensource Implementierungen, die ich mir als Beispiel mal anschauen könnte? Was passiert, wenn die Verbindung abbricht, wie kann man sie wieder aufnehmen? Wie kann ich ein automatisches synchronisieren regeln? Paralleler Thread?

Vielen Dank schon mal.
 
Was du suchst nennt sich Protokoll, und um dir ein Protokoll vorzuschlagen, musst du schon genauer beschreieben, was du synchronisieren willst mit welchen Eigenschaften.
Wenn du kein fertiges Protokoll nehmen willst, kannst du natürlich auch ein eigenes erfinden, so wie dein eigenes - obwohl das noch einige Probleme hat (Loginname mit einem Komma).
 
Wi ice-breaker richtig sagt, du brauchst ein Protokoll, dabei kannst du dich von bestehenden (HTTP etc.) inspirieren lassen oder aber was völlig neues entwickeln.
Das mit dem "linearen" Senden von Daten, was eher in Richtung plaintext geht, ist ein Sicherheitsrisiko, da ein Angreifer möglicherweise einfach die Logindaten mitlesen kann.
Da bieten sich Systeme wie SSL für eine vollständige Verschlüsselung oder nur für die Logindaten eine Digest-Funktion an.

Opensource fällt mir grad keine Implementierung ein aber gibts wahrscheinlich schon.
Verbindungsabbruch musst du natürlich behandeln, eine Lösung wäre ein sofortiges Wiederaufbauen und das Arbeiten mit atomaren Schritten.
Automatisches Syncen lässt sich entweder mit Polling, Pushing oder einer dauerhaften Verbindung realisieren.
Threads sind keine schlechte Idee, aber sehr "fehleranfällig" bei unsauberer Programmierung.
 
Im Zweifel: Lies die Source von Owncloud. Das bietet unter anderem Datei-Sync, basiert aber komplett auf PHP & HTTP.
 
sacridex schrieb:
Ich habe mir folgendes vorgestellt:
Ich habe eine Serversoftware auf einem Linuxsystem und die Clientanwendung läuft auf einem Android Gerät. Dementsprechend der Androidteil in Java, der Serverteil in C(oder Vala), schlimmstenfalls auch Java(aber sollte ja eigentlich egal sein).
Der Client verbindet mit dem Server, es findet ein Login statt, danach werden Dateien synchronisiert.
Jetzt findet man dazu aber recht wenig.
Werden die Daten dann einfach linear nacheinander als string/binary gesendet, so nach dem Motto "Login: MeinName, Passwort: pipapasswort", Server filtert dann die Variablen raus und überprüft, sendet danach ein OK, danach kommt die Anfrage ala "sendedaten" und dann sendet der Server halt die Dateien in Binärform.

Ersteinmal natürlich die Frage: Ist das so überhaupt sinnvoll? Oder geht es besser?

Man könnte beim Synchronisieren der Daten in der Client/Server Kommunikation z.B: über Hashwerte ermitteln ob sich eine Datei geändert hat oder nicht. Oder über einen Zeitstempel. Dazu müssen nur die passenden Funktionen im Client und im Server implementiert werden.

So z.B.:

Client und Server bauen sich eine Liste ihrer Dateien auf die synchronisiert werden sollen.

Fall 1: Client hat eine Datei. Server hat die gleiche Datei. Beide sind gleich

C: Ich habe Datei foto.jpg. Hashsumme ist: 16bacd39ba12
S: Ich habe die Datei foto.jpg auch. Hashsumme ist: 16bacd39ba12

Das war schon.

Fall 2: Die Datei auf dem Client ist anders und neuer als die gleiche Datei auf dem Server

C: Ich habe Datei foto.jpg. Hashsumme ist: 16bacd39ba12
S: Ich habe die Datei foto.jpg auch. Hashsumme ist: 14ca44baac34
C: Meine Datei ist vom 14.05.2012 10:05:32.010
S: Meine Datei ist vom 13.05.2012 23:16:12.040

Somit sendet der Client die aktuellere Datei zum Server. Oder eben umgekehrt.

Die Fälle dass der Client eine Datei hat, die der Server nicht hat und umgekehrt gibts auch noch und die Kommunikation läuft ähnlich ab.
Und eben diese Kommunikation muss man über das schon oft angesprochene Protokoll definieren. Man könnte z.B. über Zahlencodes die verschiedenen Aussagen codieren.

001 -> Ich habe eine Datei
002 -> Ich habe die Datei auch
003 -> Ich habe die Datei nicht
004 -> Meine Datei ist neuer
005 -> Meine Datei ist älter
006 -> Hashwert ist

usw.

Eine Anfrage könnte somit so aussehen (Fall 1):

C: 001 foto.jpg
C: 006 16bacd39ba12
S: 002 foto.jpg
S: 006 16bacd39ba12


Die Dateiübertragung an sich kann man auch noch optimieren, indem man sie z.B. vor der Übertragung zippt oder indem man nur die Unterschiede der beiden Dateiversionen überträgt (Delta-Übertragung).
Da ist viel Spielraum für billiante Ideen :)
 
Zuletzt bearbeitet:
MacGyver:
Warum selber eine halbgare Lösung aus den Fingern saugen (die auch noch offensichtlich bei kleinen
Änderungen in großen Dateien furchtbar ineffizient ist) und da noch sagen es gäbe "Spielraum für
brilliante Ideen", wenn es mit rsync eine bewährte Methode gibt? Das ist doch total bescheuert :/

€: Statt überhaupt irgendwas komplett selbst zu erfinden, würde ich eher ein relativ kleines Programm
um rsync und einen bewährten Authentifizierungsmechanismus (ssh?) herum machen. So minimiert man
die Wahrscheinlichkeit, totale Scheiße zu bauen sehr und spart sich noch viel Arbeit.
 
Zuletzt bearbeitet:
Da rsync bereits über ssh kommunizieren kann ist man eigentlich schon fertig.

Die wichtigste Regel bei der Programmierung lautet nun einmal: Erfinde das Rad nicht neu. Schnapp dir eine Open Source - Implementierung, die deiner Zielstellung möglichst nahe kommt und erweitere sie um deine speziellen Anforderungen.
 
Der Threadersteller will es aber für ein Android Smartphone entwickeln. Kann er da einfach ein kompiliertes rsync ausführen?
Wenn nicht muss er SSH implementieren (oder eine Library nutzen) und rsync implementieren (die einzige Library ist unmaintained) also ein ziemlicher Aufwand, da kann eine Quick&Dirty mit schlechteren Eigenschaften durchaus von Vorteil sein. Die Effizienz von rsync zu Erreichen ist schwierig, aber in die Nähe davon zu kommen nicht (Hashes auf Chunks der Datei zum Begrenzen des Uploads).
Genauso gut ist es auch möglich, dass rsync über 3G eventuell gar nicht so gut funktioniert, da es nicht für so hohe Latenzen entwickelt wurde und andere Lösungen sinnvoller sind (ich entwickle teilweise in der Wireless Sensor Network Ecke und kenne daher dieses Problem).

Also proforma zu sagen, dass man eine fertige Lösung nehmen soll ist nicht gut. Es stimmt zwar im Großteil der Fälle, aber hier kleingen meinen Alarmglocken, dass eine neue Lösung auch sinnvoller sein kann.
 
ice-breaker schrieb:
Genauso gut ist es auch möglich, dass rsync über 3G eventuell gar nicht so gut funktioniert, da es nicht für so hohe Latenzen entwickelt wurde und andere Lösungen sinnvoller sind (ich entwickle teilweise in der Wireless Sensor Network Ecke und kenne daher dieses Problem).

Aus dem rsync-Paper:
This report presents an algorithm for updating a file on one machine to be identical to a file on another machine. We assume that the two machines are connected by a low-bandwidth high-latency bi-directional communications link.

€: Wenn es tatsächlich kein rsync für Android gibt, lohnt es sich doch, dieses Verfahren zu implementieren, statt selbst irgendetwas zu erfinden, denn es ist bewährt und von Leuten entwickelt worden, die tendentiell schlauer sind, als wir alle hier.
 
Nun, das ist aber kein Grund, sich nicht von bestehender Software inspirieren zu lassen. Owncloud.org rücken z.B. auch die Sources für die Sync Clients raus. Die Clients sind zwar für Linux, Mac und Windows, aber da Android effektiv ein Linux ist, sollte da doch sicher was machbar sein. Und wenn nicht hat man zumindest einen Ansatz.
 
asdfman schrieb:
MacGyver:
Warum selber eine halbgare Lösung aus den Fingern saugen (die auch noch offensichtlich bei kleinen
Änderungen in großen Dateien furchtbar ineffizient ist) und da noch sagen es gäbe "Spielraum für
brilliante Ideen", wenn es mit rsync eine bewährte Methode gibt? Das ist doch total bescheuert :/

Warum sollte man es nicht machen wenn man Spaß dran hat?
Und wenn die Lösung bei großen Dateien ineffizient ist, dann besteht der "Spielraum für brillante Ideen" darin herauszufinden wie es besser ginge.
Sollen wir uns jetzt alle beim Thema Dateisynchronisierung zurücklehnen und immer schön rsync nehmen, weils das schon gibt und gut funktioniert?
Ich fände das im Gegensatz zum selbst ausprobieren total bescheuert. Denn man lernt dann nichts und man bleibt immer auf dem technischen Stand den es schon gibt.
Außerdem gibts für fast alles schon fertige Lösungen in Form von Sourcecodes und Bibliotheken. Warum sich also überhaupt die Mühe machen überhaupt über eine eigene Cloudlösung nachzudenken?
 
Das Zauberwort heißt Kosteneffizienz.
Wenn du permanent das Rad neu erfindest, dann verbraucht das Zeit und Geld. Ich könnte es mir z.B. nicht leisten, für jeden Kunden eine neue Methode zu erfinden, wie man Inhalte einer Webseite leicht verwaltet. Lieber nutze ich bestehende Lösungen und baue darauf auf.

Und nicht zuletzt: Permanent was neues zu erfinden entspricht lediglich dem Geist der Wegwerf-Gesellschaft. Wenns mit bestehendem Code schneller, billiger und leichter geht, dann ist das auch besser für die Umwelt.
 
Das Wichtigste ist, dass das Problem nicht trivial ist und klügere Leute es schon besser gemacht haben.
Es ist so gut wie ausgeschlossen, dass wenn man das Rad neu erfindet etwas herauskommt, das die
Arbeit rechtfertigt. Wenn man denn selber was machen und dabei lernen will, kann man ja ein bekanntes
Verfahren nach einer Spezifikation implementieren.
 
Danke für die ganzen Tips. ;)

Auch wenn mir einige hier davon abraten, werde ich versuchen eine eigene Lösung zu erarbeiten.
Soll erstmal nur eine kleine Bibliothek werden, die Daten nach Login synchronisiert. Verschlüsserlung über TSLv3.
Und ja, das ist mir die Zeit schon wert. Unabhängig davon, was dabei rauskommt. ;)
Ich werde euch auf dem Laufenden halten.
 
Also, wenn du einen Parser für x509-Zertifikate hingeschrieben bekommst, der einwandfrei funktioniert
und die dann noch korrekt validieren kannst, ziehe ich wirklich meinen Hut vor dir.

€: Siehe auch hier: http://www.youtube.com/watch?v=VUKCDm04AqI
Im Video geht es eigentlich um etwas anderes, aber man erfährt auch etwas darüber, wie gut x509 ist
und was da so alles auf dich zukommen wird.
 
Zuletzt bearbeitet:
Daaron schrieb:
Das Zauberwort heißt Kosteneffizienz.
Wenn du permanent das Rad neu erfindest, dann verbraucht das Zeit und Geld. Ich könnte es mir z.B. nicht leisten, für jeden Kunden eine neue Methode zu erfinden, wie man Inhalte einer Webseite leicht verwaltet. Lieber nutze ich bestehende Lösungen und baue darauf auf.

Und nicht zuletzt: Permanent was neues zu erfinden entspricht lediglich dem Geist der Wegwerf-Gesellschaft. Wenns mit bestehendem Code schneller, billiger und leichter geht, dann ist das auch besser für die Umwelt.

Ich glaube nicht dass es hier um das Investieren echter Arbeitszeit oder um ein kommerziellen Produkt geht. Wohl eher um einen Lerneffekt zu erzielen.
Und permanent bereits bestehende Dinge neu zu verwursten entspricht nicht gerade einem Begriff wie Innovation oder Erfindergeist.
Frei nach Homer Simpson: Warum willst du was neues erfinden? Nimmt etwas was es schon gibt und bau ne Digitaluhr ein :D
 
MacGyver schrieb:
Ich glaube nicht dass es hier um das Investieren echter Arbeitszeit oder um ein kommerziellen Produkt geht. Wohl eher um einen Lerneffekt zu erzielen.
Den Lerneffekt kann man auch erzielen, indem man bestehende Lösungen zu seinen Zwecken erweitert.
Und permanent bereits bestehende Dinge neu zu verwursten entspricht nicht gerade einem Begriff wie Innovation oder Erfindergeist.
Denkste... Nur durch ständige Erweiterung der Wissensbasis ist Wissensgewinn überhaupt möglich. Das heißt aber auch: Kenne die Basics, nutze bestehendes Wissen. Erst wenn ein Problem gar nicht mit herkömmlichen Mitteln zu lösen ist, ist es sinnvoll, neue Wege zu suchen.
Es ist z.B. effektiver, ein >100 Jahre altes Motorkonzept zu erweitern, statt sich etwas völlig neues zu überlegen. Frag mal Felix Wankel, wie viel Erfolg er mit seiner Entwicklung hatte...
 
Daaron schrieb:
Es ist z.B. effektiver, ein >100 Jahre altes Motorkonzept zu erweitern, statt sich etwas völlig neues zu überlegen.

Ja, und wenn das Erdöl alle ist fahren wir nur noch mit Gas, und wenn das alle ist gehen wir einfach zu Fuß, weil wir nicht weitergedacht haben als von 12 bis Mittag. Wir verbessern den Verbrennungsmotor einfach so lange bis es nichts mehr zum Verbrennen gibt. Wozu also Fortschritt in Form des Elektromotors?
 
Zuletzt bearbeitet:
Zurück
Oben