The Jumper's Inn

Find ich ja lustig, dass Du in dem Forum jetzt neue Foren für so lustiges Zeug erstellt hast, Alex, wollte nämlich eh demnächst was in der Art posten.

Aber deswegen, mal gleich zu meinem ersten Sorgenkind. Geht um ein WoW-UI-Addon, das mir etwas Kopfzerbrechen bereitet. Deswegen wollte ich vielleicht mal einfach ein Brainstorming darüber starten, wie man das Ding realisieren könnte. Nunja, beginnen wir mal mit den Spezifikationen.

Das Addon soll folgendes tun: es soll ausgewählte Gegenstände aus dem Inventar eines Charakters in eine Liste schreiben, und diese Liste soll allen angezeigt werden, die dieses Addon auch benutzen. Der Schwerpunkt liegt dabei auf der Synchronisation dieser Liste zwischen allen Nutzern des Addons. Wenn ein Benutzer eine solche Liste hat, sollen alle anderen sie auch von ihm bekommen, wenn 1) die Liste dieses Nutzers neuer ist als die der anderen und 2) unabhängig davon, ob dieser Nutzer der "Besitzer" dieser Liste ist oder nicht - der Besitzer der Liste muss also nicht unbedingt online sein, damit die Liste verbreitet wird.

Was geht?
Zum Synchronisieren steht ein Chat-Channel zur Verfügung, in dem alle momentan eingeloggten Benutzer drin sind, den sie aber nicht sehen können - nur das Addon bekommt davon etwas mit. Dabei gibt es folgende Einschränkungen zu beachten:
1) Es können nur normale, lesbare Zeichen (Buchstaben, Nummern, das "normale" Zeug eben) verschickt werden.
2) Eine Nachricht in diesem Channel hat eine maximale Länge von ca. 250 Zeichen.
3) Zwischen den einzelnen Nachrichten müssen kleinere Pausen gemacht werden (Sekundenbruchteile), um zu verhinden, dass die Nachrichten wegen "Spammings" rausgefiltert werden.
4) Die Daten der Liste lassen sich ohne Probleme in lesbare Zeichen und zurück umwandeln.

Was gibt es sonst noch für Randbedingungen?
1) Die Anzahl der Nachrichten über den Channel sollte möglichst gering sein, um den Channel nicht unnötig zu belasten, weil dieser auch noch von anderen Addons benutzt wird.
2) Es kommen dauernd neue Benutzer dazu oder verlassen den Channel (durch Ein- oder Ausloggen).
3) Durch die Dauer einer Ãœbertragung (Pausen, s.o.), kann es passieren, dass ein Benutzer mitten im Synchronisationsvorgang ausloggt, und zwar beim Senden oder Empfangen.

Najo, ich glaube, das sind für den Anfang mal genug Infos, um sich darüber ein bisschen den Kopf zerbrechen zu können. Bevor ich hier noch irgendwas darüber schreibe, wie es im Moment funktioniert, würde ich gerne sehen, wie jemand anderes das machen würde, nur um mal einen alternativen Lösungsweg zu sehen.

Wäre für Vorschläge und Ideen sehr dankbar.

PS: Wen es weiter interessiert, es geht natürlich um GuildGadgets.

Hmm...das ist in der Tat nicht so ganz trivial. Da ich im Moment aber noch nen leichten Kater hab bin ich da nicht so produktiv. Ich werd aber mal drüber nachdenken und sobald mir was einfällt werd ich es hier kundtun.

Find ich gut, dass du dass du den neuen Forumsbereich nutzt! Da ich mich ja auch mit solchen Sachen beschäftige dachte ich so eine Abteilung wär hier noch ganz praktisch

Im Moment stellt sich mir die Frage wo diese Liste(n) denn vorgehalten werden? Jeweils bei jedem Benutzer oder irgendwo zentral?
Ich gehe mal davon aus dass das bei jedem Nutzer gespeichert wird.

Unabhängig davon muss man sich ja überlegen wann denn überhaupt Synchronisation gebraucht wird. Ich denke mal:

• bei Erstellung einer Liste muss dies den anderen bekannt gemacht werden
• bei einer Änderung an der Liste muss diese propagiert werden
• nach dem Einloggen sollten die vorhandenen Listen auf Aktualität überprüft werden und nach neuen gesucht werden
• Entfernen einer Liste muss wohl auch propagiert werden

Dabei ist meiner Meinung nach der dritte und vierte Punkt das schwierigste, denn hier kann unter Umständen einiges an Datenverkehr auftreten.

Wenn ich davon ausgehe dass die Listen in irgendeiner Form gespeichert werden, denke ich dass drei zusätzliche Pflichtfelder ausreichen sollten: eine eindeutige ID, ein Timestamp und der Besitzer der Liste.

Welche Fälle können also auftreten?

• ein Benutzer legt eine neue Liste an
• ein Benutzer entfernt eine Liste (geht vermutlich nur wenn er auch Besitzer ist)
• ein Benutzer ändert etwas an einer Liste (wohl auch nur bei Besitz)
• ein Benutzer kommt neu hinzu und benötigt Aktualisierung

Die ersten drei Fälle sind denke nicht so schwierig, der letzte Fall braucht Hirnschmalz. Wenn ich mich also neu einlogge und meine Listen aktualisieren möchte kann folgendes auftreten:

• einige meiner (bereits vorhandenen) Listen sind nicht mehr aktuell
• es gibt mittlerweile neue Listen die ich noch gar nicht habe
• bestimmte Listen existieren nicht mehr, die bei mir noch vorhanden sind

Sind bis dahin jetzt Denkfehler oder falsche Annahmen oder ist die Analyse halbwegs korrekt?

Jo, stimmt so weit. Ein paar Punkte dazu:

Jo, die Listen werden Clientseitig gespeichert - zentral ist nicht drin.

Momentan werden Listen nicht gelöscht - wenn jemand alles aus der Liste entfernt, wird eine "leere Liste" vorgehalten.

Der Name des Besitzers ist die eindeutige ID einer Liste - jeder kann nur eine haben und mehrere Charaktere mit gleichem Namen gibt es nicht.

Timestamp gibt es auch - was meinst, reicht ein Timestamp pro Liste, oder braucht man einen Timetamp pro Eintrag in der Liste?

Also wenn man die Aktualitätsprüfung der Liste über den Timestamp machen will, reicht einer denn man muss ja eh alle Einträge durchgehen schätze ich.

Für die Synchronisation braucht man dann ja sowas wie ein Protokoll denke ich, sonst hat man wohl etwas viel Traffic.
Die Frage ist jetzt wie man das Problem löst sich die aktuellste Liste zu holen. Ich könnte mir sowas vorstellen wie: "Benötige Aktualisierung von Liste XXX, mein Timestamp ist blabla". Dann prüft jeder der gerade online ist, ob er diese Liste hat und sein eigener Timestamp neuer ist. Wenn ja: "Ich habe eine neuere Version dieser Liste, und zwar von Timestamp blubb". Derjenige der Aktualisierung braucht, fragt dann denjenigen mit der neuesten Liste nach den Daten.
Ist zugegebenermassen nicht ganz einfach und ich weiß nicht ob sich das so realisieren lässt.
Alternativ könnte man zu jedem Eintrag in der Liste den Timestamp und die ID speichern und dann könnte bei einer Aktualisierungsanfrage jeder, der was neueres hat drauflosspammen. Auf die Art und Weise würde eine Aktualisierungsanfrage die Liste bei allen aktualisieren. Gäbe aber viel Verkehr.
Wichtig für das Problem mit dem während der Aktualisierung ausloggen ist wohl, dass der neue Timestamp immer erst am Ende gesetzt wird.

Okay, so ähnlich hatte ich das anfangs auch. Problem ist, es entsteht wirklich sehr viel Traffic. Vor allem, wenn man von etas größeren Gildenausgeht (also viele User), dann können da sehr unschöne Effekte auftreten:

User A loggt ein, hat veraltete Version von Liste B. Es sind 19 andere User drin, die eine neuere Version von B haben. A fragt an, alle antworten, B fragt nach neuer Version, alle 19 spammen los.

User A ist mit 19 anderen Usern eingeloggt, alle haben die gleichen Daten. A ändert etwas an seiner Liste und gibt über Änderung bescheid. Wenn er jetzt, jedes Mal wenn jemand nach einer neuen Liste fragt, alles durchgibt, dann spammed er die Liste jetzt 19 mal in den Channel.

Es müsste also auch irgendeinen Mechanismus geben, der auf Anfragen/Änderungen entsprechend reagiert, so dass wenn mehrere User die gleichen Daten wollen/haben, nicht alle redundanten Traffic erzeugen.

Das bedeutet es gibt keine Möglichkeit auf Ereignisse im Chat zu reagieren? Also wenn in deinem zweiten Beispiel A seine Änderung postet, dass dann gleichzeitig alle anderen synchronisieren?

Also ich habe mir in der Tat schon öfters mal paar Gedanken zu einem solchen Kommunikationsprotokoll gemacht, kam aber auch nie auf etwas 100%iges. Da es hier ja ein Brainstorming ist, schreibe ich einfach mal nieder, was mir so einfiel. Vielleicht findet sich ja gemeinsam mehr. Ich teile das Ganze mal etwas auf, weil es insgesamt doch sehr komplex ist.

----------------------------------------------------------------------------------------------------
Datenformat:
+ UserID1 - Timestamp1
--+ ItemID1 - Count1
--+ ItemID2 - Count2
--+ ItemID3 - Count3
--+ ItemID4 - Count4
+ UserID2 - Timestamp2
--+ ItemID4 - Count6
--+ ItemID5 - Count7

IDs sind eindeutig. Für den Benutzer benutzt man den Namen, klaro. Bei Gegenständen würde ich auch alle Stapel zusammenzählen, das reduziert die Datenmenge. Ist ja schon so in deiner Version, also sind diese ItemIDs auch eindeutig. Zeitstempel habe ich nun einen pro Benutzer vorgesehen. Weniger geht wohl nicht. Ich dachte zuerst an Zeitstempel für meine letzte Aktualisierung, aber durch Ein- und Ausloggen gibt's da Probleme. Zeitstempel pro Benutzer liegt auch nahe, weil nur der Benutzer selbst die eigene Liste garantiert aktuell hat, drum steht im Timestamp auch immer die Erstellungszeit der Liste. Fremde Listen aktualisiere ich also, sobald mir jemand eine neuere Liste sendet. Wichtig: Bei jeder Liste mit Zeitstempel steht fest, dass der Besitzer diese selbst einmal angelegt hat. Count ist >0, löschen kann ich hoffentlich auf andere Weise realisieren. Die leere Liste von Jan würde ich auch beibehalten, weil der Zeitstempel notwendig ist, also z.B. "UserID1 - Timestamp3" mit leerer Liste.

----------------------------------------------------------------------------------------------------
Kommunikationsprotokoll:
Da der Übertragungskanal zu jeder Zeit von allen Beteiligten im Kanal gehört wird, würde ich die Kommunikation prinzipiell auf diese Weise gestalten: Ein bestimmter Benutzer sammelt erst Daten, wertet sie aus und organisiert dann die Aktualisierung für alle. Beispielsweise sind bereits ein paar Benutzer online, ein neuer kommt hinzu. Letzterer würde dann den gesamten Aktualisierungsvorgang verwalten.

Es stellt sich natürlich die Frage, was ist, wenn die Aktualisierung nicht fertig ist und ein neuer Benutzer hinzu kommt. Hier gibt's mehrere Möglichkeiten, die natürlich alle Nachteile haben. ^^ Ich würde die momentane Aktualisierung abbrechen und den neuen Benutzer neu beginnen lassen. Alternativen sind, dass der Neue nicht alles mitbekommt oder später nochmal neu starten muss, wodurch letztendlich nur mehr Daten übertragen werden müssen.

Kommunikationsbeispiel mit Benutzern A,B,C online:
A requests update
C sends all pairs (UserID - Timestamp)
B sends all pairs (UserID - Timestamp)

B,C ignorieren ihre Nachrichten gegenseitig, weil sie keine Anfrage gestellt haben.
A sammelt die Daten auf, wertet aus, wer jeweils die neueste Liste hat und fordert dann auf, die mitzuteilen.

A sends "B broadcast (B - Timestamp)"
A sends "B broadcast (D - Timestamp)"

A stellte hierbei fest, dass alle den gleichen Timestamp von C,E,F,... haben, also keine Aktualisierung nötig/möglich.

A sends "update (A - Timestamp) (ItemID1 - Count1) (ItemID2 - Count2) ..."
B sends "update (B - Timestamp) (ItemID1 - Count3) (ItemID3 - Count4) ..."
B sends "update (D - Timestamp) (ItemID4 - Count5) (ItemID5 - Count6) ..."

B reagiert natürlich auf die broadcast-Anfrage. Was nun alle drei machen ist, sie schauen bei einer update-Aufforderung, ob sie eine veraltete Liste haben. Wenn ja, übernehmen sie die neue, wenn nicht, ignorieren sie den Rest.

----------------------------------------------------------------------------------------------------
Nachrichtenformat:
Die update-Nachrichten werden lange sein und aufgeteilt werden müssen. Deswegen muss wohl an den Anfang und an das Ende eine MessageID = UserID+Timestamp. Erst wenn der Empfänger das Ende erhalten hat, ändert er seine Liste.

----------------------------------------------------------------------------------------------------
Die interessante Frage ist nun, ob das nun zu viele Ãœbertragungsdaten erzeugt. Wenn ich es richtig verstanden habe, sollte es weniger sein als deine erste Version. Ist es immer noch zu viel, wird man wohl nicht um einen Zeitstempel pro Gegenstand herum kommen. Die Listen sind dann sozusagen (UserID - ItemID - Timestamp). Mehr dazu aber ein anderes Mal dann.

LiMuBei hat geschrieben:Das bedeutet es gibt keine Möglichkeit auf Ereignisse im Chat zu reagieren? Also wenn in deinem zweiten Beispiel A seine Änderung postet, dass dann gleichzeitig alle anderen synchronisieren?

Doch, klar gibt es. Das Problem ist: wenn A seine Liste ändert, dann müsste er sie jedes Mal gleich los schicken. Das hat halt zwei kleine Probleme: 1) Traffic zum Server wenn gar kein anderer User da ist, den das interessieren könnte. 2) Wenn sich gleich wieder was ändert (z.B. User fügt nacheinander mehrere Einträge ein), dann wird jedes Mal synchronisiert?

So ähnlich wie du das beschrieben hast, ist es bisher, Sungi.

Der Unterschied: jeder Client entscheidet für sich selbst, ob er ein Update durchgeben/ausführen soll oder nicht. Wenn ein Client ein Update Request rausgibt, dann schicken alle ihre Daten raus (Listen+Timestamps). Dabei werden Verzögerungen verwendet, um redundante Ausgaben zu vermeiden. Also Beispiel:

A loggt ein, will neue Liste haben, fordert Status an
B und C geben die Timestamps ihrer Listen durch, und warten dann eine Weile
B bemerkt, dass C die gleichen Daten hat, aber ignoriert es, weil B im Alphabet vor C kommt
C bemerkt, dass B die gleichen Daten hat, und weil B im Alphabet vorher kommt, bricht C das Update ab
B schickt die Daten raus
A übernimmt Daten von B

So nebenbei: das ist übrigens auch noch so ein Punkt, den ich oben vergessen habe zu erwähnen: es dauert unter Umständen einige Sekunden (2-3), bis eine Nachricht, die in den Channel gepostet wird, beim Empfänger ankommt. Das kann noch zu weiteren Problemen führen.

Und ist es bisher noch zu spamlastig?

Falls jemand etwas aktualisiert, würde ich tatsächlich nicht sofort die Liste neu posten, sondern einige Sekunden warten. Wenn eine weitere Änderung folgt, wird der timer neu gestartet.

Kann es passieren, dass unnötiger Spam zum Server entsteht? Das AddOn sollte doch überprüfen können, ob andere Gildenmitglieder online sind. Wenn dies der Fall ist, brauchen diese eine Aktualisierung, ohne dass eine Nachfrage nötig ist. (Es sei denn, der erste Benutzer hat es geschafft, Änderungen vorzunehmen, die insgesamt nichts bewirkten.)

Warum sind die 2-3 Sekunden problematisch? Im Grunde ist es doch sehr ähnlich wie Internet-Protokolle, bei denen 1. die Nachricht nicht sofort ankommt, 2. Paket-weise übertragen werden muss, 3. Daten verloren gehen können oder die Verbindung abbricht. Alle potentiellen Empfänger brauchen einen Eingangspuffer und einen Timeout-Mechanismus. Z.B. stellt A eine Anfrage. B ist aber gerade linkdead oder loggt gar aus, niemand sonst da. Nach paar Sek. wird der Antwort erwartende Zustand wieder zurück gesetzt.

Willst du eigentlich vermeiden, lange Listen zu übertragen, oder geht's eher um Bug-Suche? Im zweiten Fall würde ich nämlich in deinen Code gucken wollen, im ersten noch nicht. Wie besprochen denke ich nicht, dass eine Verwaltung auf Item-Ebene den Übertragungsaufwand stark reduziert. Die Kommunikation, um festzustellen, ob etwas aktualisiert werden muss, nähme entsprechend zu. Beispielsweise könnte man ja für jeden Benutzer mehrere "farbige" Listen führen mit jeweils einem Zeitstempel, grau, weiß, grün, blau, violett, orange. Die Zeitstempelübergabe wäre nun sechsfach, aber falls nicht alle Listen übergeben werden müssten, wäre die Datenmenge hierbei geringer. Meine Einschätzung ist, dass Zeitstempel enorm viel öfter übertragen werden als Listen.

Noch etwas: Hatte ich auch schon mal erwähnt, glaube ich. Ich würde den update nicht beim Öffnen der Bank machen, sondern beim Schließen. Wenn die Bank eines Lagerchars geöffnet wird, ist die Wahrscheinlichkeit hoch, dass der Inhalt geändert wird. Somit ist später sowieso noch eine Aktualisierung notwendig. Für Lagerchars kann das AddOn ja als Text ausgeben, dass ein update für die anderen noch gemacht werden muss bei erster Änderung (Initialisierung des oben erwähnten timers) und wenn das update fertig ist. So loggt man nicht unbewusst während der Aktualisierung aus.

Und ist es bisher noch zu spamlastig?

Find schon.

Kann es passieren, dass unnötiger Spam zum Server entsteht? Das AddOn sollte doch überprüfen können, ob andere Gildenmitglieder online sind. Wenn dies der Fall ist, brauchen diese eine Aktualisierung, ohne dass eine Nachfrage nötig ist. (Es sei denn, der erste Benutzer hat es geschafft, Änderungen vorzunehmen, die insgesamt nichts bewirkten.)

Das auch. Überprüfen, ob andere online sind, geht nur, wenn der Benutzer zuvor mal das Gildenfenster geöffnet hat - sonst nicht. Eventuell mal kucken, ob man da vielleicht einen Workaround hinbekommt.

Warum sind die 2-3 Sekunden problematisch? Im Grunde ist es doch sehr ähnlich wie Internet-Protokolle, bei denen 1. die Nachricht nicht sofort ankommt, 2. Paket-weise übertragen werden muss, 3. Daten verloren gehen können oder die Verbindung abbricht. Alle potentiellen Empfänger brauchen einen Eingangspuffer und einen Timeout-Mechanismus. Z.B. stellt A eine Anfrage. B ist aber gerade linkdead oder loggt gar aus, niemand sonst da. Nach paar Sek. wird der Antwort erwartende Zustand wieder zurück gesetzt.

Tja, genau! Im Prinzip will ich ja nur einen verlässlichen Dienst auf einem unverlässlichen Aufbauen - in einer Skriptsprache, die für die UI eines Rollenspiels verwendet wird. Mit einer Latenz von mehreren Sekunden (yummie)!

Willst du eigentlich vermeiden, lange Listen zu übertragen, oder geht's eher um Bug-Suche? Im zweiten Fall würde ich nämlich in deinen Code gucken wollen, im ersten noch nicht.

Beides - wollte vor allem mal sehen, mit was für Ideen andere Leute da kommen. Einfach um zu sehen, ob das überhaupt Sinn macht, was ich da baue. Den Code hast Du auf Deiner Festplatte, im Interface-Verzeichnis deiner WoW-Installation.

Wie besprochen denke ich nicht, dass eine Verwaltung auf Item-Ebene den Übertragungsaufwand stark reduziert. Die Kommunikation, um festzustellen, ob etwas aktualisiert werden muss, nähme entsprechend zu. Beispielsweise könnte man ja für jeden Benutzer mehrere "farbige" Listen führen mit jeweils einem Zeitstempel, grau, weiß, grün, blau, violett, orange. Die Zeitstempelübergabe wäre nun sechsfach, aber falls nicht alle Listen übergeben werden müssten, wäre die Datenmenge hierbei geringer. Meine Einschätzung ist, dass Zeitstempel enorm viel öfter übertragen werden als Listen.

Nein, halte das auch für keine Option, vor allem, weil sich die Listen in den Zwischenschritten verändern können.

Noch etwas: Hatte ich auch schon mal erwähnt, glaube ich. Ich würde den update nicht beim Öffnen der Bank machen, sondern beim Schließen. Wenn die Bank eines Lagerchars geöffnet wird, ist die Wahrscheinlichkeit hoch, dass der Inhalt geändert wird. Somit ist später sowieso noch eine Aktualisierung notwendig. Für Lagerchars kann das AddOn ja als Text ausgeben, dass ein update für die anderen noch gemacht werden muss bei erster Änderung (Initialisierung des oben erwähnten timers) und wenn das update fertig ist. So loggt man nicht unbewusst während der Aktualisierung aus.

Steht in den Patchnotes der vorvorvorletzten Version als Neuerung drin.

Behemoth hat geschrieben:Den Code hast Du auf Deiner Festplatte, im Interface-Verzeichnis deiner WoW-Installation.

Das wusste ich tatsächlich schon. Wäre sonst komisch, dass er ausgeführt wird, wenn ich nicht hätte. Bisher wolltest du halt Ideen anderer hören, und siehe da, so sehr was anderes ist mir auch nicht eingefallen. Da wollte ich aber nicht vorbelastet sein. Wenn dieser Schritt beendet ist, wär's super, wenn der Verdopplungsbug behoben werden könnte - gegebenenfalls mit Hilfe, dachte ich.

Behemoth hat geschrieben:Steht in den Patchnotes der vorvorvorletzten Version als Neuerung drin.

Da sage ich uups.

Gibt es denn wirklich nur die Möglichkeit über diesen Chat-Channel zu kommunizieren? Wäre sehr praktisch in diesem Fall wenn man da auch ein /tell benutzen könnte um direkt und mit nur einem User zu kommunizieren.
Dann könnte man nämlich im Chat ausmachen wer mit wem synchronisiert und die eigentliche Datenübertragung wird dann sozusagen Peer-to-Peer gemacht.

Das ist auch möglich, aber finde ich nicht besonders hübsch, weil man dann eine Funktionalität, die eigentlich nicht für Addons gedacht ist, dafür "misbraucht". Das führt halt dazu, dass man ganz andere Teile des UIs ändern muss, wie z.B. einfach die Chat-Textbox, die die /tells anzeigt. Und da das einige andere Addons auch schon machen, kommen die sich ins Gehege.

Wenn die Lösung dadurch aber wesentlich besser werden würde, könnte man es sich natürlich überlegen, es damit zu probieren.