SportEventAnalyserClient
Das SportEventAnalyserClient Projekt bündelt sämtliche Funktionen, die zur Kommunikation über das eXtensible Messaging and Presence Protocol (XMPP) mit der Smack Library notwendig sind. Die zentrale Klasse bildet die MobilisConnectionManger-Klasse. Sie ermöglicht den Aufbau einer Verbindung zu einem XMPP-Server und kann sowohl zum Senden, als auch Empfangen von XMPPBeans genutzt werden. Zudem bietet sie eine Schnittstelle zur Nutzung von Jingle an.
Die Kommunikation mit einem Mobilis Service erfolgt über einen zentralen XMPP-Server. Somit ist es notwendig eine Schnittstelle zu diesem XMPP-Server aufzusetzen, die es einem ermöglicht XMPPBeans auszutauschen.
Das Projekt ist nicht eigenständig nutzbar und soll ausschließlich die Funktionen um die XMPP-Verbindung kapseln. Innerhalb dieses Projektes ist der SportEventAnalyserClient ausschließlich für die Kommunikation des Traffic-Generators zuständig.
Die Aufgabe des Projektes ist die Kommunikation über das eXtensible Messaging and Presence Protocol (XMPP) mit einem XMPP-Server. Zusätzlich beinhaltet das Projekt den aus der MSDL generierten Client-Stub. Dadurch ist es möglich über Mobilis Beans mit dem Mobilis Service zu kommunizieren. Zusätzlich soll das Projekt eine Schnittstelle zur Nutzung von Jingle anbieten.
Der wesentliche Schwerpunkt in diesem Projekt liegt in der Übertragung der Sensorevents an den Server. Da insgesamt etwa 15.000 Events/Sekunde übertragen werden müssen, ist hier eine genauere Betrachtung sinnvoll. Im Zuge dieses Praktikums wurden daher verschiedene Ansätze ausprobiert und auf ihre Verwendbarkeit getestet.
Der naive Ansatz zur Übertragung eines Events erfolgt über eine unverarbeitete Übertragung einzelner Events als XMPPBean. Dieser Ansatz ist sehr einfach umzusetzen und sollte vor allem die generellen Möglichkeiten zeigen.
Insgesamt konnten auf dem Testrechner über diesen Ansatz etwa 7.000 Events/Sekunde übertragen werden. Es ist somit keine Übertragung in Spielzeit über diesen Ansatz möglich. Der Ansatz hat jedoch gezeigt, dass der XMPP-Server ein Bottleneck darstellt. Die Auslastung auf dem Testrechner stieg auf 100% auf dem Core vom XMPP-Server. Ein Wechsel des XMPP-Servers führte jedoch zu keinen besseren Ergebnissen, da auch bei anderen Servern diese Anzahl von Nachrichten/Sekunde zu Engpässen führt.
Als praktische Grenze beim naiven Ansatz stellte sich vor allem die Anzahl der Nachrichten/Sekunde heraus. In diesem Ansatz sollte daher die Möglichkeit getestet werden, ob das Bündeln von mehreren Events in einem XMPPBean zu höheren Übertragungsraten führt.
Auf dem Testrechner konnten über diesen Ansatz maximal etwa 18.000 Events/Sekunde übertragen werden. Eine Übertragung in Spielzeit ist dennoch nur bedingt möglich, da kurze Stöße mit mehr Events nicht abgefangen werden können und zu Verzögerungen führen. Die Verzögerungen können jedoch akzeptiert werden, da diese bereits nach einer kurzen Zeit (max. halbe Sekunde) abgefangen werden können. Die Auslastung des Cores vom XMPP-Server im Testrechner bei einer Spielsimulation (~15.000 Events/Sekunde) stieg auf etwa 92%.
Als endgültige Übertragungstechnik bietet sich dieser Ansatz aber nicht an, da das System bereits durch die Übertragung eine zu hohe Auslastung aufweist. Sollte das System auf mehrere Rechner verteilt werden, muss das Netzwerk Übertragungsraten von etwa 8.2 MByte/s = 65.6 MBit/s übertragen können.
Eine weitere Alternative stellt eine direkt Peer-to-Peer-Verbindung dar. Die Jingle (XEP-0166) genannte XMPP-Erweiterung bietet hierfür die notwendige Grundlage an. Die Übertragung erfolgt somit nicht mehr über die Standard-XMPPBeans, sondern über ein eigenes Format. Ausschließlich die für das Jingle-Signalling notwendigen Nachrichten werden über die XMPP-Verbindung ausgetauscht.
Mit etwa 1.000.000 Events/Sekunde im Testrechner stellt dieser Ansatz die beste Lösung für das gegebene Problem dar. Sogar bei maximaler Übertragungsrate kann keine wesentliche Auslastung beobachtet werden. Die Anbindung von Jingle erfolgt über das SportEventAnalyserJingle Projekt.
Die Schnittstelle für das Projekt stellt die MobilisConnectionManager-Klasse dar. Sie besitzt sämtliche Methoden, die zum Aufbau und Behandlung einer Verbindung notwendig sind. Der Ablauf zum Aufbau einer Verbindung gestaltet sich dabei stets gleich.
Zuerst muss eine Verbindung mit dem XMPP-Server aufgebaut werden. Dafür ist die connect(String server, int port, String service)-Methode vorgesehen. Die benötigten Parameter könnten für einen lokalen XMPP-Server wie folgt aussehen:
Server: 127.0.0.1
Port: 5222 (Standard-Port nach RFC 6120)
Service: localhost
Bevor mit dem Mobilis Service kommuniziert werden kann, muss ein Login erfolgen. Die Methode performLogin(String username, String password, String ressource, String toJID) bietet hierfür die notwendige Schnittstelle an. Der Nutzer muss dem XMPP-Server bekannt sein. Die benötigten Parameter ergeben sich wie folgt:
Username: YOUR_USERNAME
Password: USER_PASSWORD
Ressource: YOUR_RESSOURCE_NAME (z.B. JavaClient => Wird als Ressource an die BareJid angehängt)
ToJID: Full-Jid des Mobilis Service (z.B. mobilis@***/YOUR_SERVICE_NAME)
Zuletzt bietet der SportEventAnalyserClient eine Schnittstelle zum SportEventAnalyserJingle Projekt an. Mithilfe der Methode establishJingleConnection(String toJID) kann die Verbindung zu einem Mobilis Service aufgebaut werden. Der Service muss dafür die Jingle-Verbindung annehmen können. Der toJID-Parameter ist notwendig, um den Service identifizieren zu können (z.B. mobilis@sea/SEA).
Obwohl das SportEventAnalyserJingle Projekt theoretisch auch genutzt werden kann um Nachrichten zu empfangen, unterstützt der Client bisher nur eine Sendefunktion. Um Jingle-Kommunikationsobjekte zu übertragen, gibt die establishJingleConnection()-Methode eine LinkedBlockingQueue zurück. Sollen neue Objekte übertragen werden, müssen diese einfach an die Queue angehängt werden
(Wichtig: queue.put(Raw) nutzen). Sobald eine Verbindung zum Service aufgebaut wurde, werden die Objekte aus der Queue an den Service übertragen.