text: Das Unterstrichzeichen _ steht innerhalb von Funktionsdeklarationen als Abkürzung für die jeweils verbleibenden Parameter, dies ist stellenweise für die Übersichtlichkeit unabdingbar und notwendig, da die Standardabkürzung … bereits Element der C-Syntax ist.
  Wird eine Methode als Server- oder Clientmethode bezeichnet, ist eine Elementfunktion aus der Schnittstelle der in den Abschnitten 3.3 und 3.6 vorgestellten Objekte gemeint.
  In diesem Abschnitt werden die eingesetzten Kommunikationsarten der Client- und Inter-Proxy-Kommunikation sowie die dafür eingesetzten Protokollheader vorgestellt.
  Bei der Portierung der Engine auf die Proxy-Architektur wurde versucht, die gesamten Kommunikationsabläufe zwischen Server und Client weitgehend zu erhalten, da der originale Netzwerkcode entsprechend den Anforderungen der Applikation entwickelt und vielfach getestet wurde. In der originalen Engine erfolgt die gesamte Kommunikation unzuverlässig (vgl. 2.1.2 ) per UDP. Der Grund dafür ist, das diese Versandart optimal für den Einsatz im Bereich Echtzeit-Simulationen, in denen es auf schnellstmöglichen Transport der Daten zur Synchronisierung der Client- und Serversimulationen ankommt, geeignet ist. Die Nachteile, wie Paketverluste und Verlust der Reihenfolge werden durch die Engine wie in Abschnitt 2.1.2 erläutert ausreichend kompensiert. Der dafür nötige Aufwand ist vergleichsmäßig gering. Paketverluste werden durch die dreifach übertragenen Aktionen[8] kompensiert. Die hierfür zusätzlich verwendete Bandbreite ist aufgrund der Deltakomprimierung der Aktionen gering. Das Sequencing der Pakete erfordert keine zusätzlichen Bestätigungspakete, da ständig bidirektional gesendet wird. Dementsprechend ist auch dieser Aufwand unbedeutend. Aus diesen Gründen wird auch der gesamte Datenverkehr zwischen Proxy und Client über die entsprechenden Schnittstellen der Proxy-API, auf der Clientseite sendUnreliable(_) und auf der Serverseite sendUnreliableClient(_), für unzuverlässige Kommunikation geleitet.
  In den seltenen Fällen, in denen Daten zwischen Client und Proxy zuverlässig übertragen werden müssen, wird ebenfalls das existierende Verfahren über Paketsequenznummern verwendet ( 2.1.2 ). Eine Umstellung dieses Kommunikationsparts auf die von der API zur Verfügung gestellte zuverlässige Übertragung per TCP, hätte keine Vorteile und würde lediglich weitreichende Veränderungen des Quellcodes erfordern.
  Die Inter-Proxy-Kommunikation wurde vollständig neu implementiert und unterscheidet sich in ihrer Art von der Client-Proxy-Kommunikation. Die verschiedenen Arten der verwendeten Kommunikation werden in Abbildung 6 zusammengefasst. Für den Fall, dass Daten selten, Performance unkritisch und damit zuverlässig zwischen den Proxies übertragen werden sollen, werden die Methoden sendReliableProxy(_) und sendReli-ableProxies(_) für zuverlässigen Transport mittels TCP, der Proxy-API verwendet. Anwendungsbeispiele sind das Ändern des Aussehens einer Spielerfigur oder das Wechseln der aktuellen Map.
  Die einzigen Informationen die kontinuierlich und in kurzen Abständen übertragen werden, sind die Zustandsupdates für die Clients und eventuell deren Bestätigungen. In diesem Fall wird abhängig von der Verfügbarkeit einer Multicast-Kommunikation zwischen den Proxyservern die Art der Übertragung wie nachfolgend gewählt. Diese Unterscheidung ist aufgrund der auch für die Zustandsupdates der Inter-Proxy-Kommunikation implementierten Deltakomprimierung ( 2.1.2.2 ) notwendig. Ist kein Multicasting verfügbar, werden die Updates per unzuverlässigen Unicast über die Schnittstelle sendUnreliableProxy(_) der Framework-API übertragen. Die Komprimierungsmethode benötigt dann allerdings pro Client die Nummer des zuletzt empfangenen Updates, um eine Kompensation von Paketverlusten zu gewährleisten. Ein Proxyserver sendet demzufolge am Ende eines Ticks an jeden Proxy ein Bestätigungspaket (Acknowledgment). In diesem sind die Framenummern der zuletzt empfangenen Zustandsupdates der direkt mit diesem jeweiligen Proxy verbundenen Clients enthalten. Für ein Szenario in dem die Proxyserver über ein Netzwerk mit Multicast-Fähigkeit verbunden sind, ist ein zuverlässiger Versand der Updates über die Schnittstelle sendReliableProxies(_) des Frameworks implementiert. In diesem Fall sind keine ACK-Pakete erforderlich, da nicht zugestellte Pakete durch die API mit Hilfe von UDP-Unicast zugestellt werden und die Deltakomprimierung somit stets das letzte Frame referenzieren kann. Eine unzuverlässige Übertragung im Fall von Multicasting ist nur unter Deaktivierung der Deltakomprimierung implementiert, da aufgrund von möglichen Paketverlusten anderenfalls kein generelles Update an alle Proxies gesendet werden könnte. Diese Kommunikationsart ist unter Verwendung von Multicasting ab 4 Proxyservern zu favorisieren. Das liegt daran, dass dann der Nachteil der optimistisch geschätzt 50% größeren Zustandsupdates (vgl. 2.1.2.2 ) durch die Anzahl der Proxyserver kompensiert wird und dass bei steigender Proxyzahl der Kommunikationsaufwand nicht mit wächst. Die Art der Übertragung der Zustandsupdates kann durch die Makros QPA_UNRELIABLE_REMOTE_CLIENT_UPDATES und QPA_MULTICASTING [Codelink18] zur Kompilierzeit an die Laufzeitumgebung des Servers angepasst werden. Standardmäßig ist die Engine für den Unicast-Inter-Proxy-Betrieb, d.h. für unzuverlässige Clientupdates kompiliert.
  Die Engine verwendet entgegen der originalen Version drei verschiedene Paketheader. Der nachrichtenorientierte Paketheader aus 2.1.2 bleibt erhalten. Dieser Header wird für die originale Client/Server-Kommunikation, als auch für die nachrichtenorientierte Inter-Proxy-Kommunikation verwendet. Nachrichtenorientiert bedeutet im letzten Fall, dass der Header vorangestellt wird, wenn kein spezieller Client das Ziel der Transmission darstellt. Informationen demzufolge nur an einen oder an alle Proxyserver gerichtet sind und z.B. zwecks Spielsitzungsverwaltung übertragen werden: