Konzepte für gemeinsames Arbeiten an einer Datei ohne Server

[Codehunter]

In dem Zusammenhang erinnere ich mich an ein lustiges kleines Programm namens A Smaller Note 99 von vor 20 Jahren. Das konnte das mit dem shared-Read/Write-File erstaunlich gut. Der Datenaustauschordner wurde einfach auf irgendein Netshare gelegt und sämtliche Teilnehmer-Instanzen auf zich Rechnern griffen darauf zu. Das Programm selbst läuft sogar noch heute auf Win 10, nur der Installer nicht. Ich frage mich wie das da intern realisiert wurde. Vermutlich hat man Schreibversuche so lange in einen Warteloop geschickt bis es keinen Write-Lock mehr auf der Datei gibt.

[HolgerX]

Hmm..

Ich denke aber, das 'A Smaller Note 99' einfach in den definierten Ordner immer eine neue Nachricht als neue Datei ablegt und der Empfänger diese liest und löscht..

Somit würde hier nur einer schreiben und einer lesen...

Wenn jedoch auf die gleiche Datei schreibend von verschiedenen PCs zugegriffen werden soll, dann muss hier ein Locking stattfinden.

Dieses könnte durch zusätzliches Ablegen eine 'Lock' Datei des Schreibers erfolgen, oder unter Verwendung von exclusivem öffnen der Datei per Dateisystem.

Bei beidem würde der 2. Schreiber warten, bis das Lock aufgehoben wurde. Dann würde jedoch der 2. Schreiber die Datei 'überschreiben'.
Bei Verwendung der 'Lock'Datei könnte hingegen der 2. Schreiber erstmal die Datei einlesen, Vergleichen und nur seine eigenen Änderungen hinzufügen, selbst wenn die Datei während des Compares nicht mehr geöffnet ist, bleibt das Lock bestehen..

[dummzeuch]

Im Prinzip kann natürlch ein Client auch gleichzeitig Server sein. Dazu dann noch eine automatische Erkennung, welcher Client der Server ist, und schon entfällt die Konfiguration weitestgehend.

Aber der "Server-Client" muss dann natürlich laufen, wenn die anderen Clients funktionieren sollen.

Trotzdem schreckt es vermutlich weniger ab, wenn man sagt: "Der Hauptrechner muss immer laufen." als wenn man von einem Server spricht.

Dann gäbe es noch die Möglichkeit, dass alle Clients lesend auf dieselben Dateien im Netz zugreifen und nur beim Schreiben eine Synchronisation notwendig wird. Da muessten sich dann die Clients dynamisch auf einen "Server" einigen.

Oder man löst es ganz traditionell mittels File-Locking.

All das funktioniert natürlich nur sehr bedingt mit Cloud-Synchronisation, weil da auch kaputte Daten übertragen werden könnten. Außer man legt einen Lock auf die komplette Datei, die könnte dann zumindest nicht kaputt übertragen werden. Was der Sync-Prozess dann allerdings macht, ist ungewiss. Im Schlimmsten Fall schlägt das Öffnen fehl und die Synchronisation löscht deshalb die Datei in der Cloud.

[Harry Stahl]

Zitat von dummzeuch:

Im Prinzip kann natürlch ein Client auch gleichzeitig Server sein. Dazu dann noch eine automatische Erkennung, welcher Client der Server ist, und schon entfällt die Konfiguration weitestgehend.

Aber der "Server-Client" muss dann natürlich laufen, wenn die anderen Clients funktionieren sollen.

Aber auch da habe ich dann eine Netzwerk-Kommunikation. Es soll aber auch funktionieren, wenn ein Anwender mit dem PC auf eine Datei z.B. in der Cloud Zugriff hat und ein anderer mit einem Tablet oder iPhone.

Ich denke für die einfachsten Sachen (Datensatz hinzugefügt, geändert, gelöscht) könnte man einfach prüfen ob das Dateidatum geändert wurde, in diesem Fall die Datei laden, die erkannten Änderungen im Vergleich zum eigenen aktuellen Stand hinzufügen und - falls eigene Änderungen vorgenommen wurden, auch die in einen logischen aktuellen Stand einpflegen und speichern, so dass andere Anwender sich auch die eigenen Änderungen laden können.

Unter Windows kann man ja sehr schön eine Benachrichtigung einrichten, wenn eine Datei geändert wurde, muss mal prüfen, wie das bei den anderen Plattformen ist (sonst zur Not per regelmäßigem Pull).

Danke auch für den Hinweis auf TMS Echo. Könnte eine Lösung sein, aber wahrscheinlich müsste ich alles umstricken. Daher lieber eine Anpassung der eigenen Lösung.

[scrat1979]

Wenn die „Servervariante“ wegfällt würde ich persönlich beim Öffnen der Datei ein Flag in diese schreiben um anderen Clients zu signalisieren, dass die Datei gerade bereits geöffnet ist. Dies setzt voraus, die Datei zunächst lesend zu öffnen, den Flag auszulesen und die Datei - wenn negativ - dann schreibend zu öffnen und den Flag neu zu setzen.

Man müsste sich dann nur Gedanken machen, wie man den Flag zurücksetzt wenn die Anwendung im Betrieb abschmiert... eventuell durch zusätzlichen Timestamp wann der Flag gesetzt wurde.

[jobo]

Ich finde das latent gruselig.

Was bedeutet "..ein Datensatz geändert oder gelöscht.."? Es geht nicht um bspw. Textdateien oder Word, sondern um Datenbankdateien? (Also sqlite vermutlich)?

"Einfach ein Flag schreiben wenn.."
Diese Sachen kennt man als Delphinutzer o.ä. ja von der BDE. Hat immer Spaß gemacht, die Sperrdateien zu löschen. Sprich selbst Server spielen. Wenn keine weiß, was eigentlich die Ursache ist, kann man sich damit noch beliebt machen, weil das System ja wieder läuft.

[Harry Stahl]

Zitat von jobo:

Ich finde das latent gruselig.

Was bedeutet "..ein Datensatz geändert oder gelöscht.."? Es geht nicht um bspw. Textdateien oder Word, sondern um Datenbankdateien? (Also sqlite vermutlich)?

Ja, stimmt schon (latent gruselig). Aber es ist eben nur als zusätzliches Angebot gedacht, für Anwender die nicht im vollen Client-Server Betrieb mit dem Produkt arbeiten wollen. Insofern würde es da auch nicht alle Möglichkeiten geben, das erkennen und Berücksichtigen von Änderungen der Datensätze würde reichen.

Das Datenbankformat ist ein eigenes, da gibt es insofern alle Freiheiten für mich.

Wie gesagt, mir würde da schon etwas einfallen. Aber die Frage war halt, ob es schon bestehende Konzepte

für diesen Problemfall gibt, also eine Art Richtlinie, an der man sich lang angeln könnte, wenn man etwas implementiert ("um nicht wieder alles neu erfinden zu müssen").