2010-04-28 6 views
6

Ich habe gerade High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System gelesen und ich folgte meistens alles bis Teil 6: globale Konsistenz. Dieser Teil beschreibt, wie das im Beitrag beschriebene System erweitert werden kann, um mehrere mit dem Server verbundene Clients zu unterstützen. Die Erklärung ist jedoch sehr kurz und besagt im Wesentlichen, dass das System funktionieren wird, wenn der zentrale Server lediglich Client-Nachrichten an alle anderen Clients weiterleitet. Ich verstehe nicht wirklich, wie das funktioniert. Welcher Statusvektor würde in der Nachricht gesendet werden, die an alle anderen Clients gesendet wird? Werden auf dem Server für jeden Client separate Statusvektoren verwaltet? Wird eine separate Kopie der Widgets lokal für jeden Client erstellt?Wie funktioniert die Echtzeit-Zusammenarbeit mit mehreren Clients in einem System mithilfe von Operationstransformationen mit einem zentralen Server?

Das einfache Beispiel, das mir einfällt, ist dieses Setup: Stellen Sie sich Client A, Server und Client B mit Client A und Client B vor, die beide mit dem Server verbunden sind. Zu Beginn haben alle drei das Zustandsobjekt "ABCD". Dann sendet Client A die Nachricht "Zeichen F an Position 0 einfügen" zur selben Zeit, zu der Client B die Nachricht "Zeichen G an Position 0 einfügen" an den Server sendet. Es sieht so aus, als würde die Nachricht von Client A an Client B und umgekehrt nicht wirklich mit diesem Fall umgehen. Was genau macht der Server?

Antwort

5

Ich habe tatsächlich herausgefunden, wie das funktionieren würde. In meinem Beispiel behält der Server einen Statusbereich für Client A und Client B. Wenn Server zuerst die Nachricht von Client A erhält, erhält der Server die Nachricht mit Statusvektor (0, 0), fügt F ein und aktualisiert dann seine Zustandsvektoren (1, 0) und (0, 1) für A bzw. B (wobei die erste Zahl die Anzahl der Nachrichten vom Client ist, die verarbeitet wurden, und die zweite die Anzahl der Nachrichten vom Server ist, die es waren verarbeitet). Der Server sendet dann "F an Position 0 einfügen" mit Statusvektor (0, 0) (da dies der Status des Servers im Statusbereich von B war, als die Nachricht vom Server empfangen wurde) und erhält "G an Position 0 einfügen" von B gesendet mit Zustand (0, 0). Da sich der Server im Zustand (0, 1) im Statusraum von B befindet, transformiert er zuerst die Nachricht (und ähnlich, da B in (1, 0) ist, wenn er die Nachricht des Servers empfängt, transformiert er auch die Nachricht von der Server). Weil Transformationen so eingerichtet werden müssen, dass, wenn xform (c, s) = (c ', s'), dann c 'angewendet auf s gleich s' auf c angewendet wird, enden B und der Server im selben Zustand. Dasselbe passiert mit der Nachricht, die der Server von B erhalten hat und dann an A sendet.

+0

Für die Nachwelt, falls dies nicht klar war: Der Server fungiert als "Proxy-Client" zwischen 'A' und' B', übersetzt ein op von 'A' (' a') in 'a'' und * forwards * op' a'' nach 'B' (als ob der Server selbst das op generiert hätte). Der Server verfügt dann über Kopien von Operationswarteschlangen "A" und "B", während "A" und "B" nur eine Kopie der Serveroperationswarteschlange haben. Weitere Informationen finden Sie unter * Concurrency Control in Groupware-Systemen * und * Ein Gegenbeispiel zur verteilten Operational Transformation und einem korrigierten Algorithmus für Punkt-zu-Punkt-Kommunikation *. – mzhang