|
Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Hallo, ich habe einige Anwendungen im Angebot, die arbeiten mit einem Server im lokalen Netzwerk (oder einem Server im Internet), und deren Clients können dann so eine gemeinsame Datei zur gleichen Zeit bearbeiten. Der Server regelt die Zugangsrechte, das sperren von Datensätzen, die Benachrichtigung der Clients über Änderungen, usw.
Das funktioniert alles Bestens, jedoch stelle ich immer wieder fest, dass es wegen der komplexen Konfiguration von Server und Clients auch einige potentielle Anwender abschreckt. Auch gibt es Anwender, die speichern z.B. eine Datendatei in einer Dropbox und nehmen darauf Zugriff per PC oder Handy bzw. Tablet. Oder eine kleine Firma mit 3-4 Leuten, wo sich keiner mit Netzwerk, IP- Portadressen usw. auskennt. Da erlebe ich es nicht selten, dass die dann lieber 3 Clients bestellen und sich absprechen, wer Daten eingeben darf und wer nur lesen darf. Meine Frage daher, gibt es eigentlich Lösungen ohne Server, wo Modelle nur für Einzelanwendungen (eine Art Protokoll), einen gemeinsamen Zugriff auf eine Datendatei regeln und somit es mehreren Anwendern (über Netzwerk, DropBox, NAS) ermöglicht, gleichzeitig mit einer Datendatei arbeiten zu können, und über gemachte Änderungen informiert werden, bzw. Sperren gesetzt werden, wenn jemand in der Datei zufälligerweise gerade den gleichen Datensatz bearbeiten sollte? Hätte ja was, wenn die Anwender nur Ihre Anwendungen irgendwo installieren müssten und die Anwendungen selber das gemeinsame "intelligente" Management der Datei für Zugriff, Änderungen und Benachrichtigung regeln würden. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Ja, diese Frage hört man öfter: "Wie geht duschen ohne nass zu werden?"
Genau aus diesem Grunde werden viele Anwendungen cloud-basiert angeboten, weil dadurch diese notwendige Server-Infrastruktur einfach da ist. Fazit: Einer muss die Arbeit (Server-Infrastruktur) erledigen, wer ist egal. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Wenn es nur um ein paar Nutzer geht könnte das auch Owncloud / Nextcloud auf eigenem PHP Server.
Die Isolation durch Sperren musst du wahrscheinlich selber drumrum machen. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Ich meine mich zu entsinnen vor einigen Jahren mal von so einer Lösung von einem Konkurrenzprodukt gehört zu haben. Denke also es gibt das schon und sollte auch grundsätzlich machbar sein.
Im Prinzip hätte ich da auch schon selber Ideen, wie man das machen könnte, aber es wäre sicher noch viel Zeit und Aufwand nötig, bis man eine stabile und zuverlässige Lösung entwickelt hätte. Insofern halt meine Frage. Hätte ja sein können, das es da evtl. schon fertige Lösungen gibt (die natürlich auch was Kosten könnten, kein Thema)... |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Von TMS gibt es TMS Echo, das dich da unterstützen könnte.
Ich hab so was ähnliches mal gemacht, in dem ich anstelle einer Datenbank ein verteiltes Versionskontrollsystem genommen habe. Das war auch recht cool. Die Frage ist halt, welchen Aufwand du betreiben musst, um ohne Server auszukommen. Vielleicht kannst du ja einen Client zu einem Server aufbohren? |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
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.. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Zitat:
Da muß man drauf kommen, ein Server ist nur dann ein Server wenn er dediziert ist. Das hab ich schon immer ganz toll gefunden. Gruß K-H |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Zitat:
mDNS eine nützliche Ergänzung? |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Zitat:
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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Zitat:
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"). |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Mmh, aber das wäre dann ja auch nur eine "Verlegenheitslösung" für Anwender, denen Dein "richtiges" Angebot zu kompliziert ist oder? Nicht weil es nicht lizensiert ist?
Frage also, wem tut man in dieser Situation mit dieser Idee einen Gefallen? Oder anders: Kann man die Entwicklungskapazität vielleicht eher in einen smarteres Serversetup stecken? |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Zitat:
|
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Zitat:
|
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Zitat:
Für dein projektspezifisches Backend sollte mit Lazarus und Indy doch relativ schnell was machbar sein. REST-Server oder ein proprietärer Dienst, ganz egal. Für den Raspi gibts sogar ein PoE-Shield. Damit prömpelst du das Ding dann tatsächlich wie einen "Netzwerk-Dongle" mit einem einzigen Kabel an einen PoE-Switch. Das Schöne am Raspi ist, dass du deine "Firmware" einfach per SD-Image verteilen kannst. Das mit Abstand einfachste und eleganteste Kloning-Tool das ich kenne ist Roadkil Disk Image. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
[QUOTE=Codehunter;1427014][QUOTE=Harry Stahl;1426948]
Zitat:
Ein Problem (egal welcher Rechner, der irgendwo am Ethernet hängt): Kann den jeder Client "sehen". mDNS allein hilft da nur sehr lokal oder? kleine Idee zum Thema "Server": Viele haben schon mal eine Webkonferenz gehabt und kennen das, alle rufen den Browser auf, man redet und zeigt sich Dinge im Browser. Wer etwas zeigen möchte, bekommt "die Moderatorkugel" (oder was auch immer, je nach Tool), von dem, der sie gerade besitzt. Der erste Teilnehmer erhält die Moderatorkugel automatisch, auch wenn er nicht Initiator der Konferenz ist. Fazit Eines der Client Programme muss halt immer Server sein. Dafür muss man eine automatische Regelung finden. Dann braucht man keine extra Hardware. (Das Sichtbarkeitsproblem ist damit nicht gelöst) Und noch was ganz anderes: Neulich hat irgendjemand ein Soziales Netzwerk auf Basis von git programmiert (Demonstrator, den man ausprobieren kann). Solange man Daten verwaltet, die textbasiert sind, wäre soetwas vielleicht auch ein Ansatz. (Weiß nicht mehr, wo ich das gelesen hab, wird man aber sicher finden, wenn man danach sucht) Git basierend ist es also ein verteiltes System. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
@Jobo
Mit diesem Minimal-Server reduziert man aber die gesamte Installation im Prinzip auf das Anstecken der Brombeere. 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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Zitat:
- 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 |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
@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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
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 |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
@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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
@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 |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
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? |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
@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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Ich würde das per kleinem PHP RestService machen, mit Slim, Laravel o.ä.
|
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
@Harry: Es gab mal
Groove, das hatte diese Fragen gelöst. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Zitat:
Wikipedia: Microsoft Groove - NachteileZitat:
Und genau darauf wird es immer wieder hinauslaufen. Ein zentrales Element, dass die Oberaufsicht hat. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
<Haarspaltermodus>Nicht immer. Z.B. Bitcoin kann es auch ohne, da geht es dann um Mehrheiten.</Haarspaltermodus> Aber den Aufwand ...
|
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Zitat:
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. |
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
<Es geht auch ohne Server. Verteilte Systeme sind gängige Praxis. Sei es Git oder Blockchains oder Replikation. Es braucht halt ein Protokoll für die Synchronisierung und die Auflösung von Konflikten.
|
AW: Konzepte für gemeinsames Arbeiten an einer Datei ohne Server
Ich habe mir jetzt die ursprüngliche Frage noch mal durchgelesen und bin der Meinung, das wir jetzt arg weit vom Thema abkommen. Denn Harry schrieb ja, dass seine Anwender die Serverkonfiguration scheuen. Heißt, man sollte die Clientel im Auge behalten. Da braucht man wohl über Blockchain nicht wirklich nachdenken...
IMHO dürfte es der einfachste Weg sein, die ja vorhandene "Servier-Software" ein wenig intelligenter zu machen. Windows bringt ja schon einiges mit an Serverdiensten, die man dafür gebrauchen könnte (Heimnetzgruppen u.ä.). Die Clients müssten in der Lage sein, ihren "Kellner" selbst zu finden, ohne händisches Eingeben von IP-Adressen oder Hostnamen. Damit dürfte Harry am besten gedient sein weil er nicht die Hälfte seines Codes neu erfinden müsste. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 18:14 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz