Konzepte für gemeinsames Arbeiten an einer Datei ohne Server

[Codehunter]

@Harry: Über diese Dinge haben sich viele kluge Köpfe den selbigen zerbrochen. Vor 20..30 Jahren. Am Anfang (an den ich mch noch erinnern kann) war da sowas wie dBase und Foxpro. Es gab da viele Experimente mit konkurrierenden Zugriffen. Novell hat da viel Geld versenkt bis das bei Netware dann mal halbwegs funktioniert hat. Ich war auch mal an so einem Thema dran, im Zusammenhang mit SQLite. Am Ende stellte sich heraus, dass man sich da noch so viele Gedanken machen kann, das Problem liegt woanders.

Nämlich beim Netshare und dem Betriebssystem, das es anbietet. Wenn das kein Realtime-OS ist sondern immer schön cached und verzögert, kannst du das mit dem Locking gar nicht sicher hinbekommen. Denn selbst wenn Client A zuerst kommt und locken will, Client B aber zufällig am Server auf einem CPU-Core landet der grad weniger zu tun hat und daher schneller am Ziel ist, führt deine Anwendung auf beiden Rechnern den Codepfad aus, der für nicht-gelockte Dateien gilt. Und schon hast du eine geschmeidige Dateikorruption.

Vor 20 Jahren war die Lösung schon die selbe, wie heute auch noch: Ohne eine Softwarekomponente, welche auf der Servermaschine die Zugriffe steuert, geht das vor den Baum. SQL-Server aller Couleur sind da eine Möglichkeit.

Die Frage, ob lokaler Serverdienst oder Clouddienst, das steht auf einem anderen Blatt. Für beides gibt es Pro und Contra, die von Kunde zu Kunde differieren können.

[TigerLilly]

Neben Concurreny ist der Stromausfall dein großer Feind. Und User, die Daten bearbeiten + dann Mittagessen gehen ohne zu speichern.

Müsste ich hier über eine Lösung nachdenken, würde ich in Richtung verteilte Systeme denken. Jeder User hat alle Daten im Zugriff und per Messaging wird im Hintergrund synchronisiert. Da nicht alle Clients immer am Netz sind, wird es wohl eine Art Änderungsprotokoll geben, von dem sich die Clients immer den relevanten Teil holen.

Aber da bist du auch schon sehr nahe an dem, was MSSQL mit Replikation macht. Bzw hab ich ECHO von TMS ja schon mal angesprochen.

[Rollo62]

Ich würde das per kleinem PHP RestService machen, mit Slim, Laravel o.ä.

[pertzschc]

@Harry: Es gab mal Groove, das hatte diese Fragen gelöst.

[Schokohase]

Zitat von pertzschc:

@Harry: Es gab mal Groove, das hatte diese Fragen gelöst.

Nein, hat es nicht ...
Wikipedia: Microsoft Groove - Nachteile

Zitat:

Groove benötigt einen Relay über Groove-Networks-Server, deshalb kein reines P2P.

Also auch hier wird ein Server benötigt.

Und genau darauf wird es immer wieder hinauslaufen. Ein zentrales Element, dass die Oberaufsicht hat.

[freimatz]

<Haarspaltermodus>Nicht immer. Z.B. Bitcoin kann es auch ohne, da geht es dann um Mehrheiten.</Haarspaltermodus> Aber den Aufwand ...

[Schokohase]

Zitat von freimatz:

<Haarspaltermodus>Nicht immer. Z.B. Bitcoin kann es auch ohne, da geht es dann um Mehrheiten.</Haarspaltermodus> Aber den Aufwand ...

Du weisst aber schon wie Bitcoin und Konsorten arbeitet?

Da kannst du auch falsche Sachen reinschreiben und wenn du 50%+ der Mining-Rechner beherrschst, dann kannst du die Wahrheit festlegen, egal wie falsch diese ist.

Dort hast du also sehr viele verteilte Server, und das Mehrheitsergebnis gilt.