Konzepte für gemeinsames Arbeiten an einer Datei ohne Server

[Codehunter]

mDNS ist ein UDP Multicast, mit allen damit verbundenen Einschränkungen.

Über den Einsatzzweck wurde ja nicht viel geschrieben. Die Beschreibung der Zielgruppe deutet für mich auf SOHO ohne dedizierten Server hin. Da kommt denn schon mal die Frage auf, ob man einen Rechner durchlaufen lassen will. Ein "Ehda"-Rechner dürfte mit Windows laufen, mit allen damit verbundenen Problemen.

Im Grunde ist ein Raspi ja auch nur ein kleiner PC, wo inzwischen sowohl Linux als auch Windows drauf läuft. Du kannst ggf. deine Software-Lizenz mit der Hardware-ID und/oder der SD-Card-CID des von dir gelieferten Raspi verdongeln.

Die Idee mit dem Raspi ist auch nur eine Möglichkeit von vielen. Kommt aber einer Out-of-the-Box-Lösung schon recht nahe.

[p80286]

Zitat:

Zitat von Schokohase (Beitrag 1427060)

Und hier noch ein paar mehr Nachteile, die man sich einhandelt, wenn der Server auf einem normalen Arbeitsplatz läuft:

- Viren
- Abstürze / Herunterfahren ("Wie, ich bin der Server?")
- Auslastung der Arbeitsstation durch Katzenvideos
- Datenschutz

und das sind nur die, die mir so spontan einfallen.

- Viren ...kann man sich auf jedem Windows-Arbeitsplatz einhandeln
- Datenschutz...wird bei uns natürlich groß geschrieben
- Herunterfahren/Katzenvideos...unsere Miarbeiter sind dizipliniert, da kommt so etwas nicht vor.

Für eine lokale Anwendung spricht:
-die Server unserer IT sind vor allem teuer.
-der bürokratische Aufwand für einen Server ist enorm.
-wir wissen besser was wir benötigen.

Und solange die Zusammenarbeit zwischen IT und Fachabteilung von Besserwisserei und Ignoranz geprägt wird, wird sich an solchen Argumentationen nichts ändern.

Gruß
K-H

[Schokohase]

@p80286

Also mein Beitrag auf den du dich beziehst, ist eine direkte Antwort auf den Beitrag von jobo.

Ich weiß ja nicht wem du jetzt Besserwisserei und/oder Ignoranz vorwerfen möchtest. Mir oder jobo?

Ansonsten kannst du es ja nochmals versuchen es mir so zu erklären, damit ich es auch im Kontext "Raspberry Pi vs. Desktop Rechner" verstehen kann.

[TomyN]

Hi,
wo willst Du denn die Daten speichern? Da muss es ja einen zentralen Ort geben, oder halt lauter lokale Kopien, die sich, sobald eine Netzwerkverbindung vorhanden ist, synchronisieren. Alles nicht ganz so einfach. Evtl. eine Serverinstallation bei der Clientinstallation (muss ja nicht server heißen, könnte man ja DatenCenter o.ä. nennen).

Tomy

[jobo]

@Schokohase
Zu Deinen Einwänden. Ich bin wirklich kein Freund von graswurzeldemokratischen Serververfahren. Ich versuche nur sinnvolle Hinweise für den TE zu geben. Also hier gemäß dem Motto, wenn schon eine Krücke, dann wenigstens verchromt und zum gleichen Preis wie ohne Chrom. Der Vergleich mit Krücke hinkt. Nein, der mit Chrom, es geht ja nicht um Luxus, sondern um funktionale Probleme, Machbarkeit, Robustheit, Aufwand. Also noch mal, wenn schon kein Auto, dann wenigstens ein Zweirad und zwar lieber ein Hooverboard statt eines Tretrollers.

@Besserwisserei
Ich denke, p80286 hat mit seinen Stichpunkten nur im "Zeitraffer" die üblichen Argumente (pro und kontra) aufgeführt. Also wahrscheinlich -abzüglich Sarkasmus- eher sogar gegen mich argumentiert, als gegen Dich, der meine Lösung ja auch zu "unserverig" findet. Aber das kann er selbst sicher am besten ausführen.

[p80286]

@Schokohase
Zunächst Du und alle die sich bisher beteiligt, haben waren nicht gemeint mit der "Besserwisserei". Das und die angeführten Argumente sind das Ergebnis einer längeren BerufsZeit zwischen Fachabteilung und IT-Abteilung. Und Du darfst mir glauben, daß meine Wortwahl noch zurückhaltend war.

@Harry
Überleg Dir gut, ob Du Deinem Kunden wirklich die "lokale" Lösung anbieten willst. Denn abgesehen von dem Reiz des technisch machbaren, eine Fachabteilung zwangsläufig nicht die gleichen Prioritäten wie eine IT-Abteilung (Virenschutz,Updates,USV etc.) und alleine von daher ist ein lokaler Server (oder etwas serverähnliches) ein Sicherheitsrisiko. Für einen Serverdienst auf einem Arbeitsplatzpc gilt das um so mehr.

Die Antiargumente von Schokohase halte ich für durchaus zutreffend. Nur kenne ich leider auch die wohlfeilen Antwoten darauf.

Gruß
K-H

[Harry Stahl]

Ehrlich gesagt war ich weniger interessiert an Gedanken um Viren, pro und contra von lokaler oder Server-Lösung, mir ging es wirklich nur darum, ob da jemand sich schon mal kluge Gedanken gemacht hat um so eine Art technisches Protokoll, bzw. was man zu beachten hat.

Z.B: Öffnet ein User A die Datei, macht es Sinn, dann in die Datei eine Info aufzunehmen, dass er die Datei geöffnet hat, so dass User B darüber unterrichtet wird. Schreibt man es dann in die Datendatei selber oder in eine zusätzliche Datei "ManAtWork.info" ;-)

Ich glaube, eine solche Lösung zusätzlich anzubieten wäre gut. Denn einige Leute (die evtl. nicht so IT-Affin sind) erwarten quasi, dass auch mehrere Anwender zur gleichen Zeit mit einer Datei arbeiten können.

Was mir im Moment so vorschwebt wäre folgendes (sollte noch vorweg schicken, dass die Datei immer vollständig in den Arbeitsspeicher geladen wird, um sie zu bearbeiten):

User A öffnet die Datei und arbeitet an der Datei im "Gruppenmodus" (quasi neue Variante zum "Netzwerkmodus" und "Einzelplatzmodus").

* Im Gruppenmodus wird jede Änderung an der Datei sofort gespeichert.

* Nun öffnet User B die Datei, letztlich im aktuellen Zustand, da ja jede Änderung von User A sofort gespeichert.

* Nun macht User A eine weitere Änderung an der Datei, die direkt gespeichert wird.

* Programm des Users B bekommt das sofort mit, weil es vom System über die Änderung der Datei informiert wird (zumindest unter Windows ja kein Problem).

* Darum lädt User B die geänderte Datei temporär in den Arbeitsspeicher und das Programm vergleicht die einzelnen Datensätze, lokalisiert den geänderten Datensatz (kein Problem, für jede Änderung gibt es einen Timestamp je Datensatz) und übernimmt die Änderung in den eigenen geladenen Datenbestand.

* Wenn User B nun eine Änderung vornimmt, läuft es genau wie zuvor geschrieben, halt nur umgekehrt (User A wird unterrichtet und aktualisiert seinen Datenbestand).

So kann das ja eigentlich Lustig hin und her gehen, der einzige evtl. problematische Fall wäre die Situation, wo beide Anwender zu gleichen Zeit am gleichen Datensatz arbeiten. In der Netzwerklösung lasse ich das nicht zu, da wird die Bearbeitung sofort gesperrt, wenn ein User anfängt einen Datensatz zu bearbeiten.

Es wäre also zu überlegen, ob man sich hier ein ersatzweises Locking ausdenkt oder ob man die Inhalte der Felder automatisch "merged" und nur, wenn die User am gleichen Feld was verändert haben, einen Konfliktlösungsdialog anzeigt (was nicht das Problem wäre, da ich sowieso schon eine Abgleichfunktion im Programm habe, wenn Außendienstmitarbeiter offline eine Datei bearbeiten und Änderungen hinterher wieder ins Netz einspielen wollen).

Hier habe ich halt keine so richtige Idee für ein ersatzweises locking für einen zu bearbeitenden Datensatz und glaube auch letztlich, dass es zuviel Aufwand wäre hier was einzuführen. Denn wenn nur 2-4 Leute in einer kleinen Firma mit einer Adressdatei arbeiten (oder ein einzelner User von verschiedenen Rechnern aus), wie oft wird das schon vorkommen, dass jemand zur gleichen Zeit ausgerechnet am gleichen Feld was ändert?

[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.ä.