Datengitter in einem LAN synchron halten

[alzaimar]

Leute, ihr müsst mir mal wieder helfen:

Szenario: Arbeitsplätze mit Grids. Sie zeigen irgendwelche Daten. Sobald ein Anwender in einem Feld des Grids etwas eintippt, müssen alle anderen Grids reagieren und die Zeile sofort sperren. Alle Änderungen müssen zudem (nach dem ENTER) bei allen anderen Grids synchron zu sehen sein.

Wie soll ich das anstellen? Was geht am schnellsten? Was ist am robustesten?

Wie kann ich reagieren, wenn die Anwendung abschmiert? Oder wenn jemand den PC einfach ausschaltet, während er eine Zeile editiert?

Ja ja, ich weiss: Eine Frage pro Thread.

Ehrlich gesagt geht es mir auch nur um die zu verwendende Technik (oder gleich ein fertiges Tool ).

Die optimale Lösung sollte auch in getrennen IP-Kreisen laufen, aber imho ist das nicht so wichtig.

[Chewie]

Konkrete Erfahrungen mit sowas habe ich keine, und ich geh davon aus, dass du meine Anmerkungen sowieso schon angedacht hast, aber ich versuchs trotzdem:

- Wenn die Reaktionszeit kritisch ist, würd ich als einzige Option ein peer-basiertes System sehen. Bei einem (n)-Clients-Server-System kann der Server in kritischen Fällen zum Flaschenhals werden
- Bist du wirklich nur in einem Subnetz, kannst du das vielleicht mit UDP-Broadcasts machen, sonst muss halt jede Anwendung jede andere im Cluster kennen. Ideen, wie man letzteres organisieren kann, solten sich in der Literatur zu Genüge finden lassen.
- Um auf ein Abschmieren zu reagieren, bleibt eigentlich nur eine Möglichkeit: Ein Timeout. Eventuell verbunden mit einer Nachfrage der/des Clients. Was das ganze natürlich wieder kompliziert macht...

[markusj]

P2P mit einem Server, der die IP-Adressen aller Clients verwaltet ... beim Programmstart meldet sich das Programm beim Server an, dieser Teilt ihm die Adressen aller anderen Clients mit. Gleichzeitig sendet der Server allen bekannten Clients die IP-Adresse des "neuen", sodass alle die gleiche Datenbank mit Clients haben.
Bei einer Änderung wird dies direkt an die anderen Clients mitgeteilt, jede Client-Adresse hat einen Timeout, nachdem sie (und alle ihre Sperrungen) verfällt, wenn sie sich nicht gemeldet hat.
Diese Meldung sollte an alle Clients+Server erfolgen, alle XX-Minuten erfolgt eine Neusynchronisierung der Client-Liste mit der vom Server.
Bei Programmende meldet sich der CLient bei allen anderen+Server ab.

mfG

Markus

[alzaimar]

Markus, Du schüttelst das so aus dem Ärmel, hast Du Erfahrungen damit? Es hört sich nämlich durchdacht an.

Auf jeden Fall danke ich Dir für deinen Denkanstoss!

[markusj]

Nö, eigentlich nicht ... war ein sponanter Einfall.
Und noch ne Erweiterung:

(Damit nicht zwei PC's gleichzeitig ein Feld blocken, erfolgt die Blockade und die Aufhebung via TCP.
Jeder Client muss die Blockade bestätigen, bevor weitergemacht wird. Timeout -> Client hängt; Fehlermeldung von der Gegenstelle -> wurde bereits geblockt, dann muss gelost werden, wer denn nun Zugriff hat.
Dann wird allen mitgeteilt, wer den Block wieder aufheben darf.)

Bessere Alternative dazu: geblockt wird über den Server, dieser bestimmt die Berechtigung.
Sprich: Client blockt beim Server, teilt diese Information aber selbst den anderen mit -> keine Überschneidungen, wer zuerst Blockt, kommt zuerst, gleichzeitig nur minimal höherer Traffic beim Server.
Ist das Feld bereits geblockt, erhält der Client vom Server ne Absage, die aufwändige Variante mit dem alle anderen Informieren wer jetzt darf, entfällt.

Und zum Timeout: darf nur beachtet werden, wenn sich der Client nicht gemeldet hat, es könnte ja sein, dass sich jemand nur Zeit lässt.

mfG

Markus

PS: liegt vielleicht auch daran, dass ich einen Netzwerk-Link via Soundkarte plane ... da macht man sich ein paar Gedanken in diese Richtung

EDIT: Bessere Anti-Überschneidungs-Alternative

[alzaimar]

Also doch via zentraler Instanz ...
Wir haben bereits einen Server, der das so ähnlich macht. Wenn ich das aber anwerfe, ist die Handhabung etwas 'klebrig'. Wenn man also z.B. ein Lock bei jedem Zeilenwechsel wirft, reagiert der Cursor nur träge: Ein schnelles Durchscrollen ist nicht möglich und einige Locks werden sogar verschluckt. Wir hatten bisher auf UDP gesetzt, aber das scheint nicht gut zu sein.

Gibt es keine andere Möglichkeit? Mann, ist das ein sch**** Problem. Erschwerend kommt noch hinzu, das man ja mehrere Server hat und die Lockinfo in einer SQL-Datenbank abgelegt wird.

Wie kann man das denn möglichst schnell machen?

[mschaefer]

Also ich würde zunächst mal eine normale Datenbankanwendung aufbauen mit einem Szentralen Server. Desweiteren eine Routine, die auf Pings lauscht. Bei Enter wird ein Ping an die xxx.xxx.255 gesendet, also Broadcast. Auf dieses signal würden die Rechner ein Refresh auf die Datenbank ausführen. Ok so also im Groben.

Grüße // Martin

[markusj]

Vorschlag 1: Lock nur wenn was geändert wird -> Änderung nur möglich, wenn gerade nicht gelockt ist.
Wenn ein PC Lockt, teilt er das der Workstation ja dann mit ... => Serverkontakt nur beim Ändern des Datensatzes.

Vorschlag 2: UDP ist denkbar ungeeignet, wenn man eine Bestätigung braucht, verschlucken wird nämlich nicht gemerkt ... dann lieber gleich TCP.

Man muss ja nicht gleich Locken, sondern erst, wenn man in den Edit-Mode geht. Solange die anderen nicht gemeldet haben, dass sie diese Zelle bearbeiten, kann man ja einfach durchrauschen. Der Server sorgt nur dafür, dass keine Überschneidungen auftreten. Er übernimmt die Mitteilung an die anderen Clients nicht.
Sobald man eine Zelle bearbeiten will, fragt man den Server, ob niemand anderes gerade diese Idee bekommen hat.
Wenn nein, Lockt der Server intern für den Clienten, und dieser Teilt das den anderen mit.
=> Internes Register bei den Clients, welche Zellen gerade gelockt sind. Alle anderen sind prinzipell frei.
Will der User dann was ändern, wird erst beim Server nachgefragt, dann ein Lock gesetzt.
(Das Locken ist ja der einzige zeitkritische Vorgang, bei dem das Serverurteil nötig ist ... bei normaler Betrachtung reicht die Meldung der anderen Clients mit einem Zeitversatz von vielleicht 0,1 Sekunden.

mfG

Markus

EDIT: Bei Unlock sendet der Bearbeiter allen anderen Workstations + Server den neuen Wert. Erst wenn dieser angekommen ist, ist der Unlock vollständig. Dieser Schritt verringert die Serverbelastung und sichert die Datenintegrität.

EDIT: Die Servervariante ist noch deutlich schneller, wie die P2P-Anfrage an alle ... dann muss man nämlich bei jedem Kästchen alle Informieren ... und auf deren Antwort warten. So hat man einen Zeitversatz von einer Ping-Time*X (X=5 oder So), und Transferiert dabei einmal die Information "Möchte Zelle XYZ BLocken" und die Antwort "Belegt/Nicht Belegt".
Wärend man die Zelle dann bearbeitet, kann man die anderen Clients darüber informieren.

EDIT: Die Belastung des Servers/der Server besteht ja nur noch darin, die Locks zu verwalten, sowie die Änderungen an den Daten mitzuprotokollieren/übernehmen.
Die Clientverwaltung erledigt sich fast von alleine, es muss nur eine vollständige Clientliste geführt und bei Bedarf verteilt werden. Jegliche Information aller Clients über den Lockstatus entfällt, (von Neuangemeldeten Clients mal abgesehen), diese Information wird im laufenden Betrieb von den Clients selbst untereinander weitergegeben.
Nur wenn selbst jemand Locken will, wendet er sich an den Server ... den Rest macht er Nebenher.

Dazu kommt noch die Möglichkeit einer Rechteverwaltung: Lock Aufheben darf nur der Ersteller (über IP Identifiziert, oder ein Admin via Server) oder der Server bei einem Time-Out.