SportEventAnalyserPubSub
Das SportEventAnalyserPubSub Projekt bündelt sämtliche Funktionen, die zur Kommunikation mit PubSub (XEP-0060) notwendig sind. Die Kernkomponente stellt die SportEventAnalyserPubSub-Klasse dar. Sie initialisiert den Sendepuffer im Service und den PubSub-Baum im XMPP-Server.
Mit der PubSub (XEP-0060) genannten XMPP-Erweiterung kann eine Publish-Subscribe-Funktionalität umgesetzt werden. Dafür müssen zuerst die Knoten des PubSub-Baums erstellt werden. Anschließend können sogenannte Items veröffentlicht werden. Ein Subscriber kann schließlich Knoten des PubSub-Baums abonnieren und erhält nun an alle Änderungen an diesen Knoten.
Das Projekt ist nicht eigenständig nutzbar und soll ausschließlich die Funktionen um PubSub kapseln. Der PubSub-Mechanismus soll ausschließlich vom Service genutzt werden.
Die Aufgabe des Projektes ist die Umsetzung der PubSub-Spezifikation. Als Grundlage für den Zugriff wird die PubSub-Umsetzung von SmackX genutzt. Sie setzt sowohl PubSub (XEP-0060), als auch die für dieses Projekt sinnvolle PubSub-Erweiterung PubSub Collection Nodes (XEP-0248), um.
Das zentrales Element innerhalb dieses Projektes stellt ein Modell vom PubSub-Baum dar. Dieses Modell wird als eigenes Abbild genutzt und bildet einen Sendepuffer. Alle Änderungen werden daher nicht direkt veröffentlicht, sondern zuerst in dem Modell abgelegt.
Die Ursache für dieses Vorgehen liegt der Annahme zugrunde, dass die statistische Verarbeitung mit etwa "15.000 Hz" (also 15.000 Events/Sekunde) arbeitet. Sollte an dieser Stelle daher keine Kontrolle über eine Sendekontrolle geschehen, könnten eventuell beliebig viele Änderungen/Sekunden veröffentlicht werden. Ein einfaches, aber bereits kritisches Beispiel stellen die Positionsdaten dar.
Sollte beispielsweise bei der Berechnung der Position pro Position kein minimales Sendedelta pro Subjekt eingeführt werden, würden bereits ~15.000 Änderungen/Sekunde veröffentlicht werden. Nämlich genau bei jedem eintreffenden Event eine neue minimal abweichende Position (ohne Send-on-Delta, feste Periode oder weitere Optimierungen).
Obwohl insbesondere ein minimaler Sendezyklus noch relativ einfach umzusetzen ist, müssen auch hier Besonderheiten beachtet werden:
- Sendezyklus pro Subjekt festlegen:
Es genügt nicht eine globale Wartezeit festzulegen, nachdem ein neues Item veröffentlicht werden darf. Dadurch könnten eventuell einige Änderungen an anderen Subjekten nicht mit in die Veröffentlichung einfließen. Beispielsweise wird bei 2 Subjekten mit 1 Hz Abtastfrequenz und Sendefrequenz zu den Zeitpunkten t1 = 0s (Subjekt1) und t2 = 0.1 s (Subjekt2) stets nur Subjekt1 oder nur Subjekt2 veröffentlicht.
- Veröffentlichung als Gruppe:
Zur optimaleren Ausnutzung der verfügbaren Ressourcen im XMPP-Server sollten idealerweise weniger Nachrichten übertragen werden. Daher bietet es sich nicht an jede Änderung direkt und ohne "Bündelung" zu übertragen. Im einfachen Positionsdaten-Beispiel können dadurch bei einer Sendefrequenz von ~30 Hz (für das menschliche Auge ausreichend) und 17 Elementen (16 Spieler, 1 Ball) insgesamt 480 Nachrichten/Sekunde eingespart werden (also 1730 Nachrichten für einen Sendezyklus pro Subjekt und 130 Nachrichten für eine Art "globalen" Sendezyklus.
Die wesentliche Ursache liegt somit in der Kontrolle der Kommunikationslast über den XMPP-Server. Durch den Aufbau des Sendepuffers und damit auch die Verantwortung über den gesamten Sendevorgang kann die Kommunikationslast exakt bestimmt werden. Ein weiterer Vorteil liegt in der Wartbarkeit der Kommunikation. Jegliche Kommunikation muss über eine bestimmte Schnittstelle im Sendepuffer abgelegt werden. Beim Testdurchlauf muss daher nur ein Monitoring über der entsprechenden Schnittstelle durchgeführt werden. Sollte kein Aufruf an dieser Schnittstelle erfolgen, liegt die Ursache an einer fehlerhaften Fremdkomponente.
Durch die Kontrolle des Sendevorgangs können sämtliche Optimierungen während der Kommunikation intern behandelt werden. Es können dabei sowohl Ansätze zur Redundanzvermeidung ohne oder mit semantischem Wissen umgesetzt werden.
Eine generelle Möglichkeit die Anzahl der Nachrichten zu reduzieren bietet die Redundanzvermeidung der Nachrichteninhalte an. Dafür ist kein semantisches Wissen über die Werte notwendig, da lediglich die Belegungen verglichen werden.
Ein in diesem Projekt umgesetzter Ansatz bietet einen zum Group-of-Pictures (aus der Bildübertragung) ähnlichen Ansatz. Dabei werden die Nachrichten in unterschiedliche "Frames" aufgeteilt:
-
I-Frame (Intra-coded-Frame):
Dieser Frame besitzt den gesamten Inhalt der zu übertragenden Nachricht. Er ist bei der Übertragung für einen "Quereinstieg" in die Simulation notwendig. Sollte beispielsweise ein Client zu einem beliebigen Zeitpunkt einsteigen wollen, erhält er spätestens mit dem I-Frame alle aktuellen Informationen. -
P-Frame (Predictive-coded-Frame):
Dieser Frame besitzt lediglich die Differenz zum vorherigen I-Frame. Dadurch wird die Größe der Nachrichten wesentliche verringert.
Wenn neben dem syntaktischen Wissen über den Aufbau der Struktur auch die Bedeutung eines Knotens bekannt ist, können weitere Optimierungen durchgeführt werden. Ein möglicher Ansatz könnte hier eine Umsetzung von Send-on-Delta (eventuell mit Watchdog/Heartbeat) sein (Delta kann aufgrund der Semantik ausgerechnet/bestimmt werden).
Obwohl als Schnittstelle zur Nutzung des Projektes die SportEventAnalyserPubSub-Klasse genutzt werden muss, bildet die StatisticsFacade-Klasse die eigentliche Zugriffsschnittstelle auf die Funktionen.
Die StatisticsFacade bietet alle möglichen Operationen zum direkten Zugriff auf das PubSub-Modell an. Sie wurde dabei so umgesetzt, dass sie zwar den Zugriff blockieren kann, aber stets nur zu minimalen Verzögerungen führt.