konsistenz in verteilten kollaborativen konstruktions mr...

MasterarbeitMalte Eckho

Konsistenz in verteilten kollaborativen KonstruktionsMR-Anwendungen

Fakultät Technik und InformatikStudiendepartment Informatik

Faculty of Engineering and Computer ScienceDepartment of Computer Science

Malte Eckho

Konsistenz in verteilten kollaborativen KonstruktionsMR-Anwendungen

Masterarbeit eingereicht im Rahmen der Masterprüfung

im Studiengang Master of Science Informatik

am Department Informatik

der Fakultät Technik und Informatik

der Hochschule für Angewandte Wissenschaften Hamburg

Betreuender Prüfer: Prof. Dr. Birgit Wendholt

Zweitgutachter: Prof. Dr. Martin Becke

Eingereicht am: 16. Januar 2017

Malte Eckho

Thema der ArbeitKonsistenz in verteilten kollaborativen Konstruktions MR-Anwendungen

StichworteMixed Reality, verteilte kollaborative Konstruktion

KurzzusammenfassungDieses Dokument stellt eine Lösung für die Sicherung der globalen Konsistenz in verteil-

ten kollaborativen Mixed Reality Konstruktions Anwendungen vor. Es wird ein generischer

Mechanismus für die Auösung von Konikten und die Synchronisation verteilter Physik-

Simulationen vorgestellt. Zu diesem Zweck wurde eine Netzwerk-Middleware entwickelt, die

eine objektorientierte, typsichere und latenzarme nachrichtenbasierte Kommunikation über

das Netzwerk ermöglicht.

Malte Eckho

Title of the paperConsistency in distributed collaborative MR-Applications

Keywordsmixed Reality, distributed collaborative constrution

AbstractThis document proposes a solution for global consistency in distributed collaborative mixed

reality construction applications. It proposes a generic mechanism for the resolution of conicts

and the synchronisation of distributed physics simulations. For this purpose a network-

middleware has been developed that implemeents a object oriented, type safe and low latency

message based communication over the network.

Inhaltsverzeichnis

1 Einführung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Vergleichbare Arbeiten 62.1 Kollaborative VR und AR-Anwendungen in der Industrie . . . . . . . . . . . . 6

2.2 Verteilte kollaborative VR/MR-Anwendungen in der aktuellen Forschung . . . 8

2.3 Verteilte kollaborative VR/MR-Anwendungen in Spielen . . . . . . . . . . . . 11

2.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Anforderungsanalyse 143.1 Mögliche Konikte in kollaborativen verteilten MR Konstruktionsanwendungen 16

3.2 Orientierung im dreidimensionalen Raum . . . . . . . . . . . . . . . . . . . . . 18

3.3 Direkte Interaktion mit virtuellen Objekten . . . . . . . . . . . . . . . . . . . . 18

3.4 Nachrichtenübertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19


4 Entwurf 224.1 Komponenten Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Externe Systeme und Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Autoritiativer Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 Action Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.5 Netzwerk Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34


5 Implementierung 375.1 Implementation Netzwerk Middleware . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1 Netzwerk Middleware Komponenten . . . . . . . . . . . . . . . . . . . 39

5.1.2 Nachrichten IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.3 Netzwerk Middleware Protokoll . . . . . . . . . . . . . . . . . . . . . . 42

5.1.4 Netzwerk Middleware API . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.5 Vorhandene Netzwerk Middleware Lösungen . . . . . . . . . . . . . . 45

5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50


iv

Inhaltsverzeichnis

6 Untersuchung 536.1 Koniktauösung Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.2 Netzwerk Middleware Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2.1 Netzwerk Middleware - Theoretischer Daten-Durchsatz . . . . . . . . 55

6.2.2 Netzwerk Middleware - Daten-Durchsatz im Netzwerk . . . . . . . . . 57

6.2.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7 Fazit 61

Appendices 63

v

Listings

5.1 Identier für Netzwerk-Nachrichten in einer CSV-Datei. . . . . . . . . . . . . 41

5.2 Protobuf Standard Network Message. . . . . . . . . . . . . . . . . . . . . . . . 42

5.3 Einfache Test Nachricht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Minimaler Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.5 Minimaler Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.6 Senden einer Nachricht die eine Antwort benötigt. . . . . . . . . . . . . . . . . 45

5.7 Registrierung eigener Datentypen in Photon. . . . . . . . . . . . . . . . . . . . 49

1 Netzwerk Middleware performance Test. . . . . . . . . . . . . . . . . . . . . . 67

2 Netzwerk Middleware performance Test Netzwerk Nachricht Generierung. . . 70

3 Netzwerk Middleware performance Test Netzwerk Nachricht. . . . . . . . . . 71

vi

1 Einführung

1.1 Motivation

Mit dem verfügbar werden neuer Virtual Reality (VR) und Augmented Reality (AR) Hardware

haben sich neue Möglichkeiten für verteilte kollaborative Anwendungen ergeben. VR-Spiele,

wie AnyLand (siehe Abbildung 2.9) und SculptrVR (siehe Abbildung 2.10), bieten gemeinsame

virtuelle Welten, die nach den Wünschen der Spieler frei gestaltet werden können. Auch For-

schungsprojekte wie Mirage Table [Benko u. a. (2012)] oder Physical Telepresence [Leithinger

u. a. (2014)] beschäftigen sich mit der Entwicklung verteilter MR-Anwendungen.

Die Vision, zu der diese Master-Arbeit beitragen soll, ist eine verteilte MR-Anwendung,

in der mehrere Benutzer, an unterschiedlichen Standorten, kollaborativ ein Konstrukt aus

Bauteilen zusammen setzen (siehe Abbildung 1.2). Der Begri Konstrukt wird im folgenden

für die Menge der Bauteile verwendet, die von den Benutzern zusammengesetzt wurden. Die

Benutzer haben mehrere Möglichkeiten diese Bauteile zu manipulieren. Die erste Möglichkeit

ist das direkte Anfassen, Aufheben und Verschieben. Die Bauteile reagieren dabei physikalisch

korrekt auf einwirkende Kräfte und Kollisionen. Die zweite Möglichkeit der Manipulation

ist die Verwendung von realen Objekten als Werkzeuge. Jedem Werkzeug ist dabei genau

eine Operation (bpsw. Bauteil bewegen) zugeordnet. Als letzte Option können die abstrakten

Eigenschaften von Bauteilen, wie die Skalierung, durch Gesten verändert werden. Die Ausgabe

erfolgt auf VR-/AR-Brillen, sodass die Benutzer die virtuelle Umgebung aus beliebigen Blick-

winkeln betrachten können. Entfernte Benutzer werden als dreidimensionale Repräsentation

in die virtuelle Umgebung eingefügt, um eine möglichst natürliche Interaktion zu ermöglichen

(siehe Abbildung 1.2).

Um diese Vision zu realisieren, müssen mehrere Teilprobleme gelöst werden. Die Konstruk-

tionslogik, Hand und Benutzer Tracking, Gestenerkennung, Ausgabe auf VR-/AR-Brillen und

Sicherung der globalen Konsistenz (siehe Abbildung 1.1).

1

1 Einführung

Abbildung 1.1: Alle Komponenten die für die Um-

setzung der Vision benötigt werden. Die in die-

ser Master-Arbeit umgesetzten Komponenten sind

grün hinterlegt.

Abbildung 1.2: Benutzer setzen kollaborativ ein

Konstrukt aus Bauteilen zusammen. Quelle: Mit

freundlicher Genehmigung von Iwer Petersen

Die Master-Arbeit konzentriert sich auf die Sicherung der globalen Konsistenz. Das Ziel ist,

dass alle Benutzer zu jedem Zeitpunkt den gleichen Zustand der virtuellen Welt sehen, damit

sie Entscheidungen auf der gleichen Grundlage treen können.

Jeder Benutzer arbeitet an einer eigenen Instanz der Anwendung. Jede dieser Instanzen be-

sitzt einen eigenen lokalen Zustand, der von der Konstruktionslogik verwaltet wird. Der lokale

Zustand setzt sich aus den Zuständen der Bauteile und Hände der Benutzer zusammen. Der

Zustand eines Bauteils oder eine Hand umfasst unter anderem Position, Rotation, Skalierung,

3D-Modell (inkl. Texturen), Masse, Kollisionsgeometrie, Geschwindigkeit etc. Diese Informa-

tionen werden für das Rendern der Szene (durch die Visualisierung) und die Physik-Simulation

benötigt. Die Konstruktionslogik besitzt eine Physik-Simulation, die dafür sorgt, dass sich die

Bauteile und Hände physikalisch korrekt verhalten (einwirkende Kräfte, Kollisionserkennung,

Gravitation etc.)1.

Die Globale Konsistenz Sicherung synchronisiert den lokalen Zustand fortlaufend mit al-

len anderen Instanzen, leitet die Aktionen des lokalen Benutzers an die anderen Instanzen

weiter und repliziert die Aktionen anderer Benutzer im lokalen Zustand. Kommt es dabei zu

Konikten, werden diese durch die Globale Konsistenz Sicherung aufgelöst. Ein Beispiel für

eine Benutzer Aktion ist das verschieben eines Bauteils mit der Hand. Die Aktion selbst und

die veränderten Zustände der Hand und des Bauteils müssen dabei mit allen verbundenen

1

Für Rendering und Physik-Simulation bietet sich die Verwendung einer Spiele Engine (bspw. Unity, UE4 oder

Xenko) an.

2

1 Einführung

Instanzen synchronisiert werden.

Die Globale Konsistenz Sicherung wird durch drei Komponenten implementiert: Der autori-

tative Server Synchronisiert in Zusammenarbeit mit der Action Logic die lokalen Zustände der

Instanzen und löst die Konikte auf. Die Netzwerk Middleware überträgt die Zustandsände-

rungen und Aktionen über das Netzwerk.

Für Multiplayer Spiele ist dies ein gut verstandenes und bereits gelöstes Problem [SourceLa-

gReduction]. Das Ziel der Master Arbeit ist es, auf Basis dieser vorhandenen Technologien

und Konzepte, eine generische Lösung für die globale Konsistenz in verteilten kollaborativen

MR Konstruktionsanwendungen umzusetzen.

1.2 Zielsetzung

Das Ziel der Master Arbeit ist die Entwicklung einer verteilten Konstruktions Anwendung, in

der mehrere Benutzer kollaborativ in einem gemeinsamen virtuellen Raum ein Konstrukt aus

virtuellen Bauteilen zusammen setzen. Die Bauteile verhalten sich physikalisch korrekt und

können von den Benutzern direkt angefasst und verschoben werden.

Um dieses Ziel zu erreichen muss die Anwendung die Hände der Benutzer tracken, die Bewe-

gungen der Bauteile durch eine Physik-Simulation steuern und den Zustand der verteilten

Instanzen synchron halten. D.h. es wird eine Anbindung an einen Hand-Tracking-Sensor, eine

3D-Engine mit Physik-Engine und eine Netzwerk-Middleware benötigt.

Die Synchronisierung der verteilten Instanzen ist der Hauptaspekt der Master-Arbeit. Die

Synchronisation muss dabei so schnell erfolgen, dass diese von den Benutzern nicht wahrge-

nommen wird.

Die Lösungen der Arbeit sollen in einem Szenario mit unterschiedlichen Aufgaben für die

Benutzer validiert werden. Zwei bis vier Benutzer sollen kooperativ aus Bausteinen ( ) ein

gegebenes zweidimensionales (X-,Y-Richtung) Konstrukt ( ) im dreidimensionalen (X,Y,Z)

Raum nachbauen (siehe Abbildung 6.1a). Die Vorgabe für das zu erstellende Konstrukt erfolgt

dabei als Bild (siehe Abbildungen 6.1b und 6.1c).

Zur Laufzeit können von den Benutzern neue Blöcke instantiiert und vorhandene Blöcke

gelöscht werden. Die Blöcke können in X,Y und Z Richtung bewegt werden und auf einer

statischen Arbeitsäche ( ) abgestellt werden. Die Bausteine untereinander und die Platte

3

1 Einführung

ziehen sich durch simulierte Magnetkräfte gegenseitig an. Dies soll das Zusammensetzen des

Konstrukts erleichtern.

Die Anwendung stellt sicher, dass der globale verteilte Zustand konsistent bleibt. D.h. alle

Benutzer sehen zu jedem Zeitpunkt einen äquivalenten Zustand des gemeinsamen virtuellen

Arbeitsbereichs. Die Benutzer möchten die Bauteile manipulieren, nicht die Hände der anderen

Benutzer. Aus diesem Grund kollidieren die Hände der Benutzer untereinander nicht. Damit

können folgende Konikte auftreten, die die Konsistenz des globalen Zustands gefährden:

• Konikte durch gleichzeitige Manipulation eines Bauteils durch zwei Benutzer- Zwei Benutzer manipulieren gleichzeitig ein Bauteil. Wenn sich diese Manipulatio-

nen widersprechen, muss eine Entscheidung getroen werden, welche Manipulation

angewendet und welche verworfen wird.

• Koniktemit realen Objekt Referenzen - Die Hände der Benutzer werden getracked

und sind als virtuelle Repräsentationen in der Physik-Simulation eingebunden. Bei der

Koniktauösung können die virtuellen, aber nicht die realen Hände verändert werden.

Ein Konikt tritt genau dann auf, wenn die Positionen der virtuellen und realen Hand

asynchron werden. Das kann bspw. dann passieren, wenn zwei Benutzer von entgegen

gesetzten Seiten gleichzeitig gegen ein virtuelles Bauteil drücken. Die virtuellen Hände

werden von dem virtuellen Bauteil aufgehalten, die realen nicht.

• Konikte durch Latenzen - Ein Benutzer führt eine Aktion auf Grundlage veralteter

Informationen aus. In der Zwischenzeit hat sich aber der Zustand der Simulation so

verändert, das die Aktion nicht mehr ausgeführt werden kann.

Ein Ziel der Arbeit ist eine generische Lösung für diese Konikte in verteilten kollaborativen

MR-Konstruktions-Anwendungen.

Die Benutzer sollten durch das korrekte physikalische Verhalten aller Elemente in der La-

ge sein, sich mit den anderen Benutzern intuitiv zu koordinieren und Konikte intuitiv zu

vermeiden oder aufzulösen. Das funktioniert nur, wenn alle Benutzer zu jedem Zeitpunkt

Entscheidungen auf Grundlage der gleichen Informationen treen. Voraussetzung dafür ist ein

konsistenter globaler Zustand, sodass alle Benutzer qualitativ das Gleiche sehen.

Aus Performancegründen werden in typischen Ansätzen für kollaborative Anwendungen

eigene Physik-Simulationen für alle verteilten Instanzen verwendet. Bei verteilten Physik-

4

1 Einführung

Simulationen ergibt sich das Problem, dass diese über die Zeit, durch additive Berechnungsfeh-

ler, asynchron werden. Damit die Simulationen synchron bleiben, müssen diese in regelmäßigen

Abständen synchronisiert werden. In welchen Abständen diese Synchronisation erfolgen muss,

hängt von der Komplexität der Physik-Simulation ab.

Ein Ziel der Arbeit ist es, die gefühlte Latenz für die Benutzer zu minimieren. Ein weiteres

Ziel ist es, nur zu synchronisieren, wenn dies notwendig ist. Jede Instanz soll dabei die Mög-

lichkeit haben, eine Synchronisation anzufordern. Wenn notwendig, soll es aber auch möglich

sein, die Synchronisation zu erzwingen.

Zusammengefasst sind die Ziele der Master-Arbeit die Synchronisation verteilter Physik-

Simulationen und die Auösung direkter Konikte im Kontext kollaborativer verteilter MR

Konstruktionsanwendungen. Diese Master-Arbeit bietet für diese Probleme generische Lösun-

gen an.

1.3 Gliederung

In Kapitel 2 werden vergleichbare Arbeiten in Industrie, Forschung und Spielen vorgestellt.

Es wird aufgezeigt welche vorhandenen Lösungen für die Lösung der Zielsetzung der Master-

Arbeit verwendet und erweitert werden können.

Im Kapitel 3 werden konkrete Anforderungen aus der Zielsetzung abgeleitet deren Umset-

zung in den folgenden Kapiteln 4 und 5 besprochen wird. Es wird aufgezeigt, welche Konikte

die globale Konsistenz gefährden und wie diese aufgelöst werden können.

Die Implementierung der Sicherstellung des globalen Zustands wird in Kapitel 6 evaluiert.

Die Qualität der Sicherstellung der globalen Konsistenz wird durch eine Benutzer Umfrage

evaluiert. Für die Verteilung wird der Datendurchsatz über das Netzwerk gemessen und mit

den Anforderungen der Koniktauösung und Mesh-Rekonstruktion verglichen.

5

2 Vergleichbare Arbeiten

Dieses Kapitel gibt eine Übersicht über die aktuellen Anwendungen von VR- und MR-Anwendungen

in Industrie und Forschung und ordnet die Master-Arbeit in diesem Kontext ein. Kollaborative

verteilte VR- und AR-Anwendungen werden in der Industrie für die Unterstützung von Ferti-

gungsprozessen verwendet. In Abschnitt 2.1 werden verschiedene Lösungen vorgestellt und

nach Grad der Kollaboration klassiziert.

In Abschnitt 2.2 werden aktuelle Forschungsvorhaben im Bereich kollaborative verteilte

AR/MR-Anwendungen beschrieben. Es wird deutlich, dass bereits viel in Richtung kolla-

borativer Anwendungen geforscht wird, das Problem der globalen Konsistenz in verteilten

MR-Anwendungen aber noch nicht ausreichend behandelt wurde.

Abschnitt 2.3 stellt die aktuellen Entwicklungen im Bereich der Spieleindustrie im Bereich kolla-

borativer verteilter Anwendungen vor. Grundsätzlich werden in den vorgestellten Spielen viele

Probleme gelöst, die für die verteilte Kollaboration benötigt werden und für die Master-Arbeit

adaptiert werden sollen.

2.1 Kollaborative VR und AR-Anwendungen in der Industrie

Kollaborative VR und AR Anwendungen werden in der Industrie im Normalfall für die Unter-

stützung des Design-Prozesses genutzt. Der Design-Prozess teilt sich in zwei Phasen auf, die

abwechselnd durchlaufen werden [Ben Rajeb und Leclercq (2015)].

In Kooperations-Phasen arbeiten die Mitarbeiter eines Projekts eigenständig ohne Kommunika-

tion am Design-Prozess. Kollaborations-Phasen nden in Meetings statt, in denen gemeinsame

Entscheidungen über das Projekt, die Organisation der Projektgruppe oder das gemeinsame

Projektziel getroen werden. Diese Phasen dienen primär der Klärung gemeinsamer Fra-

gen und der Synchronisation des gemeinsamen Verständnisses für das aktuelle Design. In

Kooperations-Phasen werden meistens AR- oder VR-Anwendungen zur Unterstützung der

Meetings eingesetzt.

Kollaborative AR-Anwendungen in der Industrie lassen sich, anhand des Grads der Kollabo-

ration, in drei Klassen einteilen. Die erste Klasse bilden Anwendungen, in denen genau ein

6


Abbildung 2.1: ViewAR:

Möbel Visualisierung im

Raum. Quelle: ViewAR

Abbildung 2.2: Improov3:

Online Design-Review

mit replizierten An-

notationen Quelle:

improov

Abbildung 2.3: Marker ba-

sierte Produkt Visualisie-

rung in Autodesk Aug-

ment. Quelle: Autodes-

kAugment

Abbildung 2.4: Darstel-

lung und Manipulation

komplexer CAD-Modelle

in Autodesk Augment.

Quelle: AutodeskAug-

ment

Benutzer, dem Präsentator, Informationen und 3D Inhalte mit einer Gruppe teilt. Die dargestell-

ten Inhalte werden dabei exklusiv vom Präsentator bestimmt. Beispiele sind ViewAR [ViewAR]

und Autodesk Augment [AutodeskAugment]. Der Präsentator präsentiert der Gruppe Produkte,

die mit Hilfe eines Tablets im Raum dargestellt werden (siehe Abbildungen 2.1, 2.3 und 2.4).

Diese Klasse von Anwendungen bietet den geringsten Grad an Kollaboration.

Die zweite Klasse von kollaborativen AR-Anwendungen in der Industrie sind Anwendungen,

die einen gleichberechtigten Zugri auf die Informationen gestatten. Die partizipierenden

Benutzer haben jeweils eigene Ausgabegeräte und können so die gemeinsamen Inhalte un-

abhängig voneinander explorieren. Ein Beispiel ist Visionary Render von Virtalis [virtalis-

visionary-render]. Diese Anwendung erlaubt das kollaborative verteilte Design-Review von

CAD-Inhalten. Zusätzlich bietet das Unternehmen Lösungen für die Architekturvisualisierung

auf Powerwalls, Prozessunterstützung in der Produktion und Training und Ausbildung an

[virtalis].

Die dritte Klasse von kollaborativen AR-Anwendungen hat alle Interaktionsmöglichkeiten

der zweiten Klasse und bietet zusätzlich die konkurrierende Modikation der gemeinsamen

Inhalte. Diese Klasse von Anwendungen bietet den höchsten Grad an Kollaboration.

Ein Beispiel ist die Anwendung Improov3

die ein kollaboratives verteiltes Design-Review

implementiert. Die Bauteile, die einem Review unterzogen werden sollen, können aus verschie-

denen CAD und 3D-Modell Formaten importiert werden. Die Benutzer haben die Möglichkeit,

Annotationen an den Bauteilen der importierten Modelle anzubringen und diese im Raum zu

verschieben. Diese Annotationen und Verschiebe-Operationen werden auf allen verbundenen

Instanzen repliziert (siehe Abbildung 2.2). Ein weiteres Beispiel ist die Verwendung des Spiels

7


Abbildung 2.5: Physical

Telepresence unterstützt

physische Manipulation

realer Objekte aus der

Ferne durch Computerge-

stützte Teleoperation.

Abbildung 2.6: Physical

Telepresence: Kolabora-

tives 3D-Modelling von

zwei verbundenen Land-

schafts 3D-Modellen.

Abbildung 2.7: Mirage Ta-

ble Telekonferenz Szena-

rio für genau zwei Benut-

zer.

Abbildung 2.8: T(ether)

unterstützt die Generie-

rung und Manipulation

virtueller Objekte durch

Gesten.

Second Life für Online Meetings der Firma Mikado [Ben Rajeb und Leclercq (2015)]. Das

Spiel wird aber nur als Unterstützung für Telefonkonferenzen verwendet. Die beschränkten

Möglichkeiten zur 3D-Modellierung behindern aber deutlich die Ezienz und Eektivität der

Kommunikation.

Die Anwendung, die im Kontext der Master-Arbeit entwickelt werden soll, ist ein Element der

dritten Kategorie. Die gemeinsamen Inhalte sollen unabhängig exploriert und konkurrierend

verändert werden können.

2.2 Verteilte kollaborative VR/MR-Anwendungen in deraktuellen Forschung

Für verteilte kollaborative CAD-Anwendungen stellt Cheng u. a. (2014) einen Lösungsansatz

für das rückgängig machen von Benutzer Aktionen vor. Mit diesem Ansatz können rein virtu-

elle Konikte durch das rückgängig machen einer verursachenden Benutzer Aktion aufgelöst

werden. Die Arbeit verwendet Lamport Zeitstempel, um eine globale Ordnung über allen

kausal abhängigen Benutzer-Aktionen herzustellen. Damit ist es beim rückgängig machen

der letzten Aktion eines Benutzers möglich, alle Aktionen anderer Benutzer zu identizieren,

die auf dieser Aktion aufbauen. Diese werden dann ebenfalls rückgängig gemacht, damit der

Zustand der virtuellen Welt konsistent bleibt.

Für die Master-Arbeit wird ebenfalls ein Mechanismus benötigt, um die Aktionen von Benut-

zern rückgängig zu machen. Dieser wird in der Koniktauösung verwendet und in Kapitel 4

vorgestellt. In Abgrenzung zu Cheng u. a. (2014) wird ein zentralisierter Ansatz genutzt. Der

8


Haupt-Vorteil liegt in einem deutlich geringeren Verwaltungsaufwand.

Die Arbeit Mirage Table [Benko u. a. (2012)]implementiert eine kollaborative MR-Anwendung

für zwei Benutzer. Mirage Table nutzt als Ausgabemedium einen gekrümmten Schirm, auf

den virtuelle Objekte perspektivisch korrekt projiziert werden. Die Arbeit konzentriert sich

unter anderem auf die physikalische Interaktion mit virtuellen Objekten. Virtuelle Objekte

können verschoben und angehoben werden. Um das zu erreichen, wird die reale Geometrie

im Arbeitsbereich (inklusive der Hände der Benutzer) mit einer Tiefenbildkamera eingele-

sen und als Menge dicht gepackter virtueller Kugeln in einer Physik-Engine repräsentiert.

Bewegungen der echten Geometrie werden auf die virtuellen Kugeln übertragen. Virtuelle

Objekte kollidieren mit den Kugeln und werden so durch die reale Geometrie beeinusst.

Bpsw. kann ein Benutzer damit einen virtuellen Ball zur Seite schieben oder aufnehmen. In der

Master-Arbeit ndet ebenfalls eine verteilte Physik-Simulation Verwendung und stellt eine ge-

nerischen Ansatz für die Synchronisation dieser Simulationen mit beliebig vielen Benutzern vor.

T(ether) [Olwal u. a. (2014)] implementiert eine kollaborative 3D-Modelling AR-Anwendung

mit Hilfe von Tablets und Sensor-Handschuhen. Die Benutzer können sich frei im Raum be-

wegen und benutzen die Tablets als Fenster in die virtuelle Welt. Virtuelle Objekte können

mit Gesten erstellt und manipuliert werden (siehe Abbildung 2.8). Die Arbeit konzentriert sich

auf die Verwendung des Tablets als Eingabegerät. Gesten, die hinter dem Tablet (also in der

virtuellen Szene) ausgeführt werden, manipulieren die dargestellten 3D-Modelle direkt. Gesten

über dem Tablet steuern globale Parameter. Zusätzlich wird auf dem Tablet ein GUI angezeigt,

das normal durch touch Eingaben bedient wird. Bei der Evaluierung hatten die Benutzer die

Aufgaben, mehrere virtuelle Bauteile nach Größe zu sortieren, mehrere Bauteile aufeinander

zu stapeln und mehrere Bauteile nach einer Vorgabe im Raum zu platzieren. Diese Aufgaben

wurden kollaborativ erledigt. Die Master-Arbeit erweitert den Aspekt der kollaborativen Kon-

struktion um eine verteilte Physik-Simulation, die es möglich macht, das virtuelle Objekte

korrekt auf einwirkende Kräfte reagieren.

Das Arvida Projekt [Arvida2015] hat die Entwicklung einer dienst-orientierten Referenzarchi-

tektur für AR-Anwendungen zum Ziel. Anwendungen in dieser Architektur sollen unabhängig

von proprietären Standards, modularer und skalierbarer als vorhandene Lösungen werden.

Arvida setzt dabei stark auf eine Service orientierte Struktur auf Basis von Web-Technologien

1.

1

REST, RDF, OWL, LinkedData

9


Da der Anwendungsfall der Master-Arbeit sehr kommunikationsintensiv ist, soll der Overhead

von Web-Technologien bei der Kommunikation vermieden werden (protobufspeed). Es wird

eine eigens entwickelte Netzwerk Middleware auf Basis von Google Protobuf (protobuf) zur

Kommunikation verwendet.

Leithinger u. a. (2014) stellt eine Lösung für eine verteilte kollaborative Arbeit mit realen

Objekten vor. Die entfernte Geometrie wird erfasst, übertragen und durch eine Menge höhen-

verstellbarer Stäbe (siehe Abbildung 2.5) reproduziert. Dies erlaubt ein kollaboratives Arbeiten

durch Telepräsenz.

Ein spezisches Beispiel für einen Telepräsenz Arbeitsbereich mit einem gemeinsamen digita-

len Modell ist kollaboratives 3D-Modelling (siehe Abbildung 2.6). Benutzer können das Modell,

durch drücken der Stäbe, deformieren. Die Änderungen werden auf dem entfernten Modell

repliziert.

Wenn zwei Benutzer das Modell gleichzeitig an der gleichen Stelle manipulieren wollen, üben

diese gleichzeitig auf ihren entsprechenden Stab Kraft aus. Es entsteht ein Konikt, weil das

Modell nicht gleichzeitig von zwei Benutzern an der selben Stelle geändert werden kann.

Das Problem wird durch ein Turn-Taking Protokoll gelöst. Sobald das System eine Deformation

des Modells feststellt, wird die Kontrolle über die betroenen Stäbe dem Benutzer übergeben,

der diese Deformation durchführt. Die Kontrolle kann dabei alternativ auch für das gesamte

Modell übergeben werden.

Krafteinwirkungen des anderen Benutzers werden solange ignoriert, bis der erste Benutzer die

Deformation abgeschlossen hat. D.h. die Deformationen werden mechanisch repliziert, egal ob

der andere Benutzer Kraft auf die Stäbe ausübt oder nicht.

Der Ansatz, der in der Master-Arbeit vorgestellt wird, erlaubt die gleichzeitige Manipulation

von virtuellen Objekten. Es werden keine Locks verwendet. Das verwendete Protokoll agiert

optimistisch und löst Konikte im Bedarfsfall auf, ohne die Manipulation des Objektes durch

den Benutzer zu unterbrechen. Durch die mechanische Repräsentation löst diese Arbeit das

Problem der Konikte mit realen Objekt Referenzen. Dieses Problem wird in Abschnitt 3.1

genauer behandelt. Im Prinzip geht es darum, dass die Hände der Benutzer bei der Koniktauf-

lösung nicht virtuell beeinusst werden können. Durch eine mechanische Repräsentation wird

aber genau das möglich. In der Master-Arbeit soll diese Art von Konikt durch Feedback an

den Benutzer aufgelöst werden. Die Auösung durch Feedback wird in Kapitel 4 besprochen.

10


Abbildung 2.9: AnyLand: Ein VR-Multiplayer-

Sandbox Spiel. Alle Inhalte werden von den Benut-

zern zur runtime selbst generiert. Quelle: AnyLand

Abbildung 2.10: SculptVR: Die Spieler malen ge-

meinsam eine Voxel basierte Landschaft. Quelle:

SculptrVR

2.3 Verteilte kollaborative VR/MR-Anwendungen in Spielen

Aktuelle Spiele, die mit der Master-Arbeit vergleichbar sind, sind AnyLand [AnyLand] und

SculptVR [SculptrVR]. In AnyLand generieren Spieler über die Komposition von geometrischen

Primitives neue Objekte (bspw. Stühle, Tische, Bäume etc.). Das Verhalten der neuen Objekte

wird über selbstgeschriebene Scripts implementiert. Die Spieler haben damit die Möglichkeit,

eigene Spielregeln zu denieren.

In SculptrVR generieren mehrere Spieler gemeinsam eine Welt aus Voxeln, die sie im dreidi-

mensionalen Raum zeichnen. Die Spieler können dabei ihre Größe beliebig ändern, um grobe

oder feine Details zu gestalten.

Um die verteilte Kollaboration in diesen Spielewelten zu lösen, muss der Zustand der Spiel-

welt zwischen den Spielern synchronisiert werden. Zudem müssen in Konikt zwischen den

Aktionen der Spieler so aufgelöst werden, dass diese möglichst wenig in ihrer Aktivität gestört

werden.

Um das zu erreichen, wird in Spielen das Konzept des autoritativen Servers angewendet. Es

handelt sich um eine verteilte kollaborative Client-Server-Anwendung. Aktionen der Clients,

die den globalen Zustand beeinussen, müssen zuerst von dem Server bestätigt werden, bevor

diese angewendet werden. Wenn ein Konikt auftritt, wird der World-State des Clients mit

dem des Servers überschrieben.

Für die Auösung von virtuellen Konikten in Spielen gibt es das Konzept des autoritativen

Servers. Es handelt sich um eine verteilte kollaborative Client-Server-Anwendung. Auf allen

11


verteilten Instanzen läuft jeweils eine eigene Instanz des Spiels mit einem eigenen lokalen

Spiel-Zustand. Der Spiel-Zustand umfasst nur die für die Kollaboration relevanten Informatio-

nen über die Elemente des Spiels. Im Fall des Master-Szenarios wären das die Position, Rotation

und Geschwindigkeit der Bausteine und Hände der Benutzer.

Die Aktionen von Spielern auf Client-Instanzen werden erst lokal, auf Grundlage des Spiel-

Zustands, validiert und dann an den Server geschickt. Erst wenn dieser die Aktion ebenfalls,

auf der Grundlage seines Spiel-Zustands, validiert, wird die Aktion auf dem Server und allen

Client Instanzen repliziert.

Wird die Aktion auf dem Server nicht validiert, ist ein Konikt aufgetreten. Der Spiel-Zustand

des Servers und des Clients sind asynchron. Um dieses Problem zu beheben wird der Spiel-

Zustand des Clients mit dem vom Server überschrieben. D.h. für den Fall der Master-Arbeit

müssten die Positionen aller Bauteile und Hände angepasst werden. Im Gegensatz zu den

Bauteilen sind die virtuellen Hände Repräsentationen realer Objekte. Ihre Position kann damit

nicht geändert werden. Das Konzept des autoritativen Servers kann aber erweitert werden, um

dieses Problem zu behandeln.

Ein weiteres Konzept, was ebenfalls in der Master-Arbeit Anwendung nden soll ist die

Client-Side-Predition [SourceLagReduction]. Bei diesem Verfahren wird die gefühlte Latenz

für den Benutzer minimiert, indem Aktionen ohne Bestätigung durch den Server sofort lokal

ausgeführt werden und nur im bei Bedarf Rückgängig gemacht werden. Das funktioniert nur,

wenn zu erwarten ist, dass der größte Teil der Benutzer-Aktionen nicht rückgängig gemacht

werden muss. Im Szenario der Master-Arbeit soll dieses Konzept für die Bewegung der Hände,

für die eine niedrige Reaktionszeit wichtig ist, angewendet werden.

Die Anforderungen für Erweiterungen und die Verwendung der Client-Side Prediction für

die Hände werden in Kapitel 3 deniert. Die Umsetzung wird in Kapitel 4 erläutert.

2.4 Zusammenfassung

Die Anwendung, die in der Master-Arbeit implementiert wird, soll den höchsten Grad an Kolla-

boration bieten. Mehrere Benutzer sollen gleichzeitig die virtuelle Umgebung explorieren und

verändern können. Verteilte AR- und MR-Anwendungen nden in der Industrie hauptsächlich

für das Design-Review Verwendung. In der Forschung sind verteilte MR-Anwendungen ein

aktuelles Thema. Es gibt Ansätze für verteilte Physik-Simulationen. Das Problem der Auösung

12


von Konikten mit realen Objekt Referenzen wurde von Leithinger u. a. (2014) mit einer mecha-

nischen Lösung umgesetzt, die aber für diese Arbeit nicht praktikabel ist. In der Spieleindustrie

gibt es das Konzept des autoritativen Servers, was für die Lösung der Master-Arbeit verwendet

und erweitert werden kann.

13

3 Anforderungsanalyse

Aus denen in Abschnitt 1.2 vorgestellten Zielvorgaben sollen im folgenden die Anforderungen

für die Implementation der Master-Arbeit abgeleitet werden.

A 1 Die Anwendung trackt die Hände des Benutzers und überträgt diese auf virtuelle Reprä-

sentationen.

A 2 Die Bauteile reagieren korrekt auf einwirkende Kräfte. Diese Kräfte werden entweder

durch die virtuellen Repräsentationen der Hände der Benutzer (siehe A 1) ausgeübt oder

durch die Kollision mit anderen Bauteilen.

A 3 Die Anwendung stellt sicher, dass der globale Zustand konsistent bleibt. D.h. alle Benut-

zer sehen zu jedem Zeitpunkt einen äquivalenten Zustand des gemeinsamen virtuellen

Arbeitsbereichs, um Entscheidungen auf Grundlage der gleichen Informationen zu tref-

fen. Der Zustand der virtuellen Welt, den die Benutzer sehen, muss, in allen für die

Entscheidung relevanten Aspekten, gleich sein. Für den Fall, dass die Benutzer bspw.

Bauteile verschieben wollen, müssen alle Bauteile und Hände an gleicher Position und

Rotation angezeigt werden. Somit ist es den Benutzern möglich, Kollisionen zu vermei-

den oder bewusst herbei zu führen. Bspw. kann ein Benutzer das Konstrukt xieren,

während ein anderer Benutzer ein Bauteil anfügt.

A 4 Die Anwendung löst alle in Abschnitt 1.2 aufgeführten Konikte (Konikte durch gleich-

zeitige Manipulation eines Bauteils durch zwei Benutzer, Konikte mit realen Objekt

Referenzen und Konikte durch Latenzen) auf. Die Auösung dieser Konikte ist not-

wendig, um die Konsistenz des globalen Zustands zu sichern (siehe A 3). Diese Konikte

werden in Abschnitt 3.1 näher erläutert.

A 5 Die Anwendung synchronisiert für jede Anwendungs-Instanz den lokalen Zustand mit

dem globalen Zustand. - Damit alle Benutzer, wie in A 3 beschrieben, den gleichen

Zustand sehen, müssen die lokalen Zustände der Anwendungs-Instanzen untereinander

synchronisiert werden.

14


A 6 Jede Anwendungs-Instanz führt eine lokale Simulation aus. - Um die Latenzen für die

Benutzer zu minimieren, wird auf jeder Instanz eine lokale Simulation ausgeführt, die

die Eingaben der Benutzer direkt auswertet und anzeigt. D.h. wenn der Benutzer ein

Bauteil mit seiner Hand verschiebt, werden ihm die Bewegungen der Hand und des

Bauteils direkt angezeigt. Daraus ergeben sich folgende weitere Anforderungen:

A 6.1 Jede Anwendungs-Instanz führt eine eigene Physik-Simulation aus. - Um die Ein-

gaben des lokalen Benutzers direkt auswerten zu können, wird eine lokale Physik-

Simulation benötigt (siehe A 2).

A 6.2 Die Anwendung synchronisiert den Zustand der lokalen Physik-Simulation mit

dem globalen Zustand. - Da der Zustand der lokalen Physik-Simulation (siehe A 2)

Teil des lokalen Zustand ist, folgt aus A 5, dass der Zustand der lokalen Physik-

Simulation mit den Zuständen aller anderen Physik-Simulationen synchronisiert

werden muss.

A 6.3 Jede Anwendungs-Instanz führt eine eigene Rendering-Lösung aus. Diese rendered

den lokalen Zustand aus der Perspektive des lokalen Benutzers, um die Ergebnisse

der Eingaben des Benutzers anzuzeigen.

A 7 Die Physik-Simulationen der Anwendungs-Instanzen sind entsprechend parametrisiert,

um ein intuitives Arbeiten mit den virtuellen Bauteilen zu ermöglichen. Die Bauteile

sollen möglichst realistisch auf einwirkende Kräfte reagieren, um die Erfahrung der

Benutzer mit der Manipulation realer Objekte zu nutzen. Die genauen Anforderungen

für diese Parametrisierung werden in Abschnitt 3.3 besprochen.

A 8 Die Anwendung stellt sicher, dass alle Aktionen der Benutzer auf allen Instanzen in der

gleichen Reihenfolge ausgeführt werden. - Die Ausführungsreihenfolge von Aktionen

ist nicht kommutativ. Bspw. ist es nicht egal, ob ein Bauteil zuerst instantiiert und dann

bewegt oder erst bewegt und dann instantiiert wird. Im letzteren Fall würde das Bauteil,

was bewegt werden soll, noch nicht existieren, was zu Fehlern führen würde.

Wenn jede Anwendungs-Instanz eine lokale Simulation ausführt (A 6) und diese syn-

chronisiert werden muss (A 5), folgt daraus, dass auch die Ausführungsreihenfolge der

Aktionen auf allen Instanzen synchronisiert werden muss. Abschnitt 3.4 deniert die

Anforderungen an die Nachrichtenübertragung, die sich aus dieser Anforderung ergeben.

Eine globale Ordnung für die Ausführung aller Aktionen erfordert das Zusammenspiel

mehrerer Komponenten und wird in Abschnitt 4 behandelt.

A 9 Die Anwendung erlaubt die gleichzeitige Manipulation eines Bauteils.

15


A 10 Die Anwendung erlaubt das hinzufügen von Bauteilen zur Laufzeit. - Wie in Abschnitt

1.2 beschrieben, haben die Benutzer die Möglichkeit, neue Bauteile zur Laufzeit zu

instantiieren und vorhandene Bauteile zu löschen. Diese Änderungen betreen den

lokalen Zustand und müssen damit synchronisiert werden (siehe A 5).

A 11 Die Anwendung erlaubt den Benutzern die Orientierung im virtuellen Raum. - Für die

gezielte Interaktion mit den virtuellen Bauteilen muss die Anwendung den Benutzern

eine Orientierung im virtuellen Raum ermöglichen. D.h. die Benutzer müssen erkennen

können, wo sich ihre Hände in Relation zu den Bauteilen benden, um diese gezielt

zu manipulieren. Zusätzlich müssen sich die Bauteile bei der Manipulation so real

wie möglich verhalten. Diese Anforderung wird in den Abschnitten 3.2 und 3.3 weiter

erläutert.

A 12 Die von der Anwendung verwendete Nachrichtenübertragung bietet mindestens einen

Durchsatz von 54,9 MB pro Sekunde. - Für die Realisierung der in Abschnitt 1.1 vor-

gestellten Vision wird für die Echtzeit Rekonstruktion die Übertragung von Benutzer

Meshes benötigt. Damit das funktioniert muss sichergestellt werden, dass der Durchsatz

der Nachrichtenübertragung groß genug ist, um mindestens 30 Meshes mit der kleinsten

Auösung zu übertragen. Dafür werden mindestens 54,9 MB pro Sekunde benötigt (siehe

Tabelle 6.2).

A 13 Die von der Anwendung verwendete Lösung zur Nachrichtenübertragung ist spra-

chunabhängig und portierbar. - In der Forschungsgruppe werden viele verschiedene

Programmiersprachen verwendet. Für die Realisierung der in Abschnitt 1.1 vorgestellten

Vision ist es wichtig, dass die Anwendung mit den anderen Systemen kommunizieren

kann (bspw. ist die Benutzer Mesh Rekonstruktion in C++ geschrieben). Konkret werden

Implementationen für C++, C#, Python und Java benötigt.

3.1 Mögliche Konflikte in kollaborativen verteilten MRKonstruktionsanwendungen

Konikte können grundsätzlich nur dann entstehen, wenn der globale Zustand inkonsistent

wird. Dafür kann es mehrere Ursachen geben.

Die erste Ursache für Konikte sind Latenzen bei der Übertragung. Es tritt ein Konikt auf,

wenn mehrere Benutzer gleichzeitig oder kurz nacheinander Aktionen ausführen, die sich

16


gegenseitig widersprechen. Die Instanzen wissen aufgrund der Übertragungslatenzen noch

nichts von den jeweiligen anderen Aktionen. Da sich die Aktionen gegenseitig widersprechen,

kann nur eine der Aktionen global ausgeführt werden. Es kommt zum Konikt.

Es muss entschieden werden, welche Aktion global ausgeführt wird. Die anderen, in Konikt

stehenden, Aktionen werden verworfen. Dafür wird ein Mechanismus benötigt, der eine global

eindeutige Reihenfolge für die Aktionen der Benutzer deniert. Die, nach dieser Reihenfolge,

erste Aktion wird ausgeführt, alle anderen werden verworfen. Die Reihenfolge soll der realen

chronologischen Reihenfolge der Aktionen entsprechen. Diese Konikte werden als Koniktedurch Latenzen bezeichnet.

Die zweite Ursache für Inkonsistenzen entsteht nur dann, wenn die Ausführung mindestens

einer möglichen Aktion nicht deterministisch ist. Deterministische Aktionen überführen den

synchronen globalen Zustand bei der Ausführung in einen anderen synchronen globalen

Zustand. Es ist dabei keine weitere Kommunikation, außer dem Befehl zur Ausführung der

Aktion, notwendig. D.h. die gleiche Aktion liefert auf allen Anwendungs-Instanzen bei gleichen

lokalen Zuständen das gleiche Ergebnis.

Ist die Ausführung einer Aktion nicht deterministisch, kann diese bei der Ausführung mit

gleichen lokalen Zuständen unterschiedliche Ergebnisse liefern. Außer der Kommunikation

zur Ausführung der Aktion, ist zusätzlich eine Synchronisation des globalen Zustände nach

der Aktion notwendig.

Im schwierigsten Fall reicht diese zusätzliche Synchronisation nicht aus. In bestimmten Fällen

kann es sein, dass der globale Zustand auch ohne die Ausführung von Aktionen asynchron

wird. In diesem Fall muss der Zustand fortlaufend synchronisiert werden. Diese Konikte

werden als Konikte durch nicht deterministische Aktionen bezeichnet.

Dies ist bspw. bei der Verwendung von Physik-Simulationen zur Steuerung des Verhaltens

der Objekte der lokalen Zustände der Fall. Sobald die Objekte sich bewegen oder kollidieren

werden die lokalen Simulationen durch Floating-Point-Fehler bei der Physik-Berechnung di-

vergieren. Diese Fehler sind additiv.

Bei steigender Anzahl interagierender (bspw. kollidierender) Physik-Objekte in der Simulation

werden diese Inkonsistenzen schneller sichtbar. D.h die Frequenz der fortlaufenden Synchroni-

sierung muss an die Komplexität der Simulation angepasst werden.

Eine zusätzliche Schwierigkeit, die sich für die Auösung dieser Konikte ergibt, sind Re-ferenzen auf reale Objekte. Im Fall des Szenarios der Master-Arbeit handelt es sich um die

17


Hände der Benutzer, die in Abgrenzung zu virtuellen Objekten (wie den Bauteilen) direkt

manipuliert werden können.

Bei einem Konikt zwischen virtuellen Objekten kann deren Zustand von den Anwendungs-

Instanzen direkt überschrieben werden. Bei realen Objekten ist das nicht möglich. Die Anwendungs-

Instanzen müssen in diesem Fall den globalen Zustand konsistent halten und den Benutzern

gleichzeitig Feedback geben um das Problem aufzulösen.

3.2 Orientierung im dreidimensionalen Raum

Ein 3D-Interface muss so konzipiert sein, dass es drei kognitive Vorgänge ermöglicht: Ori-

entierung (wie in Hildebrandt und Others (1993) deniert), Navigation und Exploration. Die

Orientierung in einer virtuellen Welt funktioniert dann, wenn der Benutzer genug Informatio-

nen hat, seinen aktuellen Standpunkt richtig einzuordnen. Im Kontext dieser Arbeit muss der

Benutzer also zu jedem Zeitpunkt genug Informationen haben, um die Position seines Kopfes

und besonders seiner Hände genau zu bestimmen.

Navigation setzt sich aus waynding und travelling zusammen Bowman u. a. (2004). Der Be-

nutzer muss genug Informationen haben, eine Route zu planen. Für diese Arbeit bedeutet

das, dass der Benutzer genug Informationen und Feedback haben muss, Positionsänderungen

für Kopf und Hände zu planen und auszuführen. Ein Beispiel ist die Bewegung einer Hand

zwischen zwei Punkten ohne mit einem virtuellen Objekt zu kollidieren.

Für die Exploration von Daten ist es wichtig, die virtuellen Daten iterativ erkunden zu können.

Methoden sind dabei bspw. die Rotation oder der Zoom der Darstellung. Für die Umsetzung

dieser Arbeit ist es also wichtig, dass der Benutzer das zu untersuchende Objekt von mehreren

Seiten betrachten, auseinandernehmen und drehen kann.

3.3 Direkte Interaktion mit virtuellen Objekten

Die Arbeit The PHANTOM Haptic Interface : A Device for Probing Virtual Objects Massie

und Salisbury (1994) beschäftigt sich mit der Entwicklung eines haptischen mechanischen

Interfaces für AR-Anwendungen. In dieser Arbeit gibt es kein mechanisches Interface. Die

vorgestellten Anforderungen lassen sich aber auf das Verhalten der virtuellen Hände und

Objekte anwenden. In diesem Fall ist das Feedback nicht haptisch sondern visuell.

Reaktion von Objekten auf einwirkende Kräfte - Virtuelle Objekte müssen korrekt auf

einwirkende Kräfte reagieren. Wenn ein Benutzer ein Objekt verschiebt, kann er durch die

18


Reaktion Rückschlüsse auf die Geometrie (Form, Position), Attribute (Bewegungseinschrän-

kungen, Massenträgheit, Reibung) und Ereignisse (Kollision, Bewegungseinschränkungen)

ziehen. Das ist bspw. dann wichtig, wenn die Benutzer eine Menge von Bauteilen zusammen

schieben, um diese auszurichten.

Ein freier Raum muss sich frei anfühlen - Die Latenz der Bewegung der virtuellen

Repräsentationen der Arme und Hände des Benutzers muss minimiert werden. Durch eine zu

große Trägheit wird sonst ein gefühlter Widerstand beim Benutzer erzeugt.

Solide virtuelle Objekte müssen sich starr anfühlen - Es muss verhindert werden, dass

die virtuellen Hände des Benutzers die Oberäche eines virtuellen Objektes durchbrechen. D.h.

die virtuellen Hände des Benutzers dürfen auch dann nicht in ein virtuelles Bauteil eindringen,

wenn dieser es zwischen seinen Händen einquetscht.

"There is nothing as disturbing as leaning against a wall and falling through it." -

Virtuelle Objekte müssen sich auch bei einer kraftvollen Manipulation physikalisch korrekt

Verhalten. Es wurde beobachtet, dass Benutzer dazu tendieren, Bauteile mit einer schnellen

Wisch Geste aus dem Arbeitsbereich zu entfernen. Die Bauteile müssen in diesem Fall physika-

lisch korrekt mit der Hand kollidieren und entsprechend beschleunigt werden. D.h. die Hand

des Benutzers darf in keinem Fall ohne Eekt durch die Bauteile hindurch bewegt werden

können.

3.4 Nachrichtenübertragung

Die Verteilung muss eine Nachrichtenübertragung bereit stellen, die den Latenz- und Konsistenz-

Anforderungen der Anwendung genügt. Die Latenz ist genau dann akzeptabel, wenn diese die

Bedienung der Anwendung nicht signikant behindert.

Wie in Abschnitt 3 beschrieben, ist die Ausführung von Aktionen in den meisten Fällen nicht

kommutativ. D.h. es muss sichergestellt werden, dass alle Aktionen überall in der gleichen

Reihenfolge ausgeführt werden. Bspw. ist es nicht egal, ob eine Hand erst instantiiert und

danach bewegt oder erst bewegt und dann instantiiert wird.

Die globale Ordnung von Nachrichten erfordert das Zusammenspiel mehrerer Komponenten.

Die Sicherstellung der folgenden Kriterien für die Nachrichtenübertragung ist Teil davon (mehr

dazu in Kapitel 4). Es muss sichergestellt werden, dass Nachrichten:

1. ... nicht verloren gehen.

19


2. ... in der Reihenfolge ankommen, in der sie abgeschickt wurden.

3. ... intakt übertragen werden.

4. ... auf dem Weg nicht verändert werden.

5. ... von einer authentizierten Anwendungs-Instanz stammen.

6. ... , falls erforderlich, verschlüsselt übertragen werden können.

Jede dieser Anforderungen erhöht den Verwaltungsaufwand und in den meisten Fällen die

Nachrichtengröße. Bspw. müssen für die Sicherstellung der Reihenfolge von Nachrichten Se-

quenznummern vergeben werden. Diese müssen sowohl mit der Nachricht übertragen werden,

als auch beim Sender und Empfänger verwaltet werden.

Ein höherer Verwaltungsaufwand und größere Nachrichten wirken sich negativ auf die Latenz

aus. Größere Nachrichten benötigen länger um übertragen zu werden. Verwaltungsaufgaben

erhöhen die Zeit für die Verarbeitung der Nachrichten beim Empfang und Versand. D.h. je

mehr Konsistenzanforderungen erfüllt sein müssen, desto schlechter wird die Latenz.

Die Latenz bestimmt im Szenario der Master-Arbeit, die Reaktionszeit der Anwendung auf

die Eingaben des Benutzers. Da es sich um eine interaktive Anwendung handelt, muss diese

minimiert werden. Es ist daher wünschenswert, Nachrichten mit nur genau den Konsistenzan-

forderungen zu verschicken, die von dieser speziellen Art von Nachricht benötigt werden.

Für das Szenario der Master-Arbeit reicht es zwischen drei Nachrichten Konsistenz Klassen

zu unterscheiden.

Zuverlässige Nachrichten erfüllen alle genannten Konsistenz Anforderungen. Es handelt

sich dabei bspw. um Aktionen von Benutzern. Diese müssen immer in der richtigen Reihenfolge

ankommen und dürfen nicht verloren gehen.

Zuverlässige verschlüsselte Nachrichten erfüllen alle genannten Konsistenz Anforderun-

gen und sind vollständig verschlüsselt. Für die Verschlüsselung soll eine synchrone Verschlüs-

selung mittels eines Shared Secrets verwendet werden, weil diese schneller als eine asynchrone

Verschlüsselung ist. Der initiale Austausch des Shared Secrets kann asynchron verschlüsselt

erfolgen. Diese Art von Nachrichten wird momentan nicht genutzt, ist aber für zukünftige

Ausbaustufen wichtig. Bspw. wäre eine mögliche Anforderung virtuelle Räume mit einem

Passwort zu schützen, was verschlüsselt übertragen werden muss. Auch sind verschlüsselte

Verbindungen dann sinnvoll, wenn die Inhalte des virtuellen Raums vor dem ausspähen durch

dritte geschützt werden sollen.

20


Unzuverlässige Nachrichten erfüllen keine Konsistenz Anforderungen. Es handelt sich meis-

tens um Nachrichten, deren Relevanz zeitlich stark begrenzt ist. Ein Beispiel sind absolute

Positionsinformationen von virtuellen Objekten. Diese können getaktet abgeschickt werden.

Der Verlust einer Nachricht ist, bei einer genügend hohen Taktung, vernachlässigbar. Das

Objekt bewegt sich in diesem Fall kurzzeitig nicht und wird beim eintreen der nächsten

Nachricht an die aktuelle Position gesetzt. Das zu späte Eintreen ist nicht vernachlässigbar.

Das Objekt würde dann an eine veraltete Position gesetzt werden.

3.5 Zusammenfassung

Die Lösung der Master-Arbeit soll die verteilte kollaborative Zusammenarbeit ermöglichen.

Die Benutzer sollen gemeinsam ein Konstrukt aus Bauteilen zusammen bauen. Die Hände der

Benutzer werden von den Anwendungs-Instanzen getracked, sodass die Benutzer die Bauteile

anfassen, verschieben und aufheben können. Dabei entstehende Konikte und Inkonsistenzen

werden möglichst so aufgelöst, dass die Benutzer dies nicht bemerken. Dafür müssen die

verteilten Physik-Simulationen entsprechend parametrisiert und synchronisiert werden.

21

4 Entwurf

Im diesem Kapitel wird erläutert, wie die Anforderungen aus Kapitel 3 umgesetzt werden. Für

die Anforderungen A 1 (Hand Tracking), A 2 (Physik Simulation), A 7 (Physik Simulation

Parametrisierung), A 13 (Multiplattform Nachrichtenübertragung), A 6.3 (Rendering-Lösung)

und A 11 (Orientierung im Raum) werden externe Bibliotheken genutzt, die in Abschnitt 4.2

vorgestellt werden. Die Anforderungen für die Synchronisierung (A 3 bis A 9) werden im

folgenden behandelt.

Um Bandbreite zu sparen ist es von Vorteil, nur die Entitäten und deren Eigenschaften

zwischen den Anwendungs-Instanzen zu synchronisieren, die für alle Benutzer relevant sind

und sich zur Laufzeit ändern. Bspw. müssen die Positionen und Geschwindigkeiten der Bauteile

synchronisiert werden. Die Position der Arbeitsäche ist zwar für alle Benutzer relevant, ändert

sich aber nicht und muss daher auch nicht synchronisiert werden.

Zur Sicherung der Konsistenz des globalen Zustands (A 3) kommt das Konzept des autorita-

tiven Servers zum Einsatz. Es handelt sich um eine verteilte Client-Server Anwendung. Jede

Instanz besitzt eine Kopie der zu synchronisierenden Informationen. Diese wird als lokalerZustand bezeichnet.

Der lokale Zustand des Servers dient dabei gleichzeitig als globaler Zustand. Treten Inkonsis-

tenzen zwischen dem lokalen Zustand eines Clients und dem des Servers auf, wird der lokale

Zustand des Clients mit dem vom Server überschrieben (A 5).

Das Problem der globalen Ordnung über allen Aktionen (A 8) wird ebenfalls mit dem Kon-

zept des autoritativen Servers gelöst. Die globale Reihenfolge in der die Aktionen der Benutzer

ausgeführt werden entspricht der Reihenfolge, in der diese auf dem Server eintreen. Diese

Reihenfolge muss nicht immer der realen chronologischen Reihenfolge entsprechen. Warum

diese Lösung trotzdem gewählt wurde wird in Abschnitt 4.3 erklärt.

22

4 Entwurf

Für die direkte Auswertung der Benutzer Eingaben (A 6) läuft auf jeder Instanz eine eigene

Simulation. Alle Simulationen benutzen die gleiche Logik für die Auswertung der Benutzer

Aktionen. Im Fall der Master-Arbeit umfasst diese Simulation eine Physik-Simulation (A 6.1).

Für die Synchronisation der Physik-Simulation (A 6.2) bildet der autoritative Server in

regelmäßigen Abständen eine Checksumme seines lokalen Zustandes und schickt diese an die

Clients. Die Clients bilden beim Empfang der Checksumme des Servers eine eigene Checks-

umme ihres lokalen Zustands. Dierieren diese beiden Checksummen ist der lokale Zustand

des Clients mit dem globalen Zustand inkonsistent. Der Client fordert den aktuellen globa-

len Zustand vom Server an. Nachdem der globale Zustand vom Server empfangen wurde,

überschreibt der Client seinen lokalen Zustand mit diesem. Der lokale Zustand des Clients ist

wieder mit dem globalen Zustand synchron.

Das Hinzufügen/Entfernen von Entitäten zum globalen Zustand (A 10), oder das ändern

von Eigenschaften von Entitäten des globalen Zustands, wird als Aktion deniert. Jede Aktion

besitzt eine Menge von Vorbedingungen die erfüllt sein müssen, damit diese ausgeführt

werden kann. Vorbedingungen beziehen sich ausschließlich auf Entitäten und Eigenschaften

des globalen Zustands. Bspw. muss für das Verschieben eines Bauteils von Position A nach B

dieses existieren und sich an Position A benden. Jede Aktion muss vor der Ausführung auf

Grundlage dieser Vorbedingungen validiert werden.

Da eine Aktion den globalen Zustand verändert, muss diese auf alle lokalen Zustände an-

gewendet werden. Damit das funktioniert, wird die Aktion zuerst im lokalen und dann im

globalen Zustand validiert. Sind beide Validierungen erfolgreich wird der globale Zustand

durch die Aktion verändert.

Kann die Aktion im lokalen Zustand nicht erfolgreich validiert werden, wird diese verworfen.

Wird die Aktion im lokalen aber nicht im globalen Zustand erfolgreich validiert, kommt es zu

einem Konikt. Der lokale Zustand des Clients ist asynchron mit dem globalen Zustand. Der

Server verwirft die Aktion und informiert den Client. Dieser hat nun die Möglichkeit auf die

fehlgeschlagene Validierung zu reagieren.

Diese Reaktion kann in einem Zurücksetzen der Aktion (Rollback) und/oder dem Feedback an

den Benutzer bestehen (siehe Abschnitt 4.4). Der Server schickt danach den globalen Zustand

an den Client, der seinen lokalen Zustand überschreibt. Mit diesem Konzept lassen sich die in

A 4 beschriebenen Konikte lösen.

23

4 Entwurf

Konikte durch die gleichzeitige Manipulation eines Bauteils durch mehrere Benutzer (A 9)

werden durch die Synchronisation der Physik-Engine gelöst. Ein Bauteil, das von mehreren

Benutzern gleichzeitig bewegt wird, hat durch diese Synchronisation auf allen Instanzen die

gleiche Position, Rotation und Geschwindigkeit.

Konikte mit realen Objekt Referenzen lassen sich durch die Feedback Funktionalität auösen.

Wenn die virtuelle Hand des Benutzers durch die Koniktauösung zurück gesetzt wird, sind

die Positionen der realen und virtuellen Hand asynchron. Die Feedback Funktionalität erlaubt

es der Anwendung, dem Benutzer diesen Konikt anzuzeigen. Eine Möglichkeit ist es, dem

Benutzer anzuzeigen, wo sich seine reale Hand in Relation zur virtuellen Repräsentation ben-

det. Der Benutzer muss die reale Hand an die Position der virtuellen Hand bewegen, um diese

wieder zu synchronisieren. Die Feedback Funktionalitäten sind nur für den lokalen Benutzer

relevant und müssen daher nicht synchronisiert werden. Der Benutzer hat beliebig viel Zeit

die Inkonsistenz aufzulösen.

Konikte durch Latenzen treten dann auf, wenn eine Aktion im lokalen aber nicht im globalen

Zustand validiert werden kann. Der lokale Zustand ist veraltet und kann durch Überschreiben

des lokalen mit dem globalen Zustand aufgelöst werden.

Für einige Aktionen der Benutzer, die eine minimale Latenz erfordern (bspw. die Bewegung

der Hände), kann nicht auf das Ergebnis der Validierung im globalen Zustand gewartet werden

(A 6). Es wird von der optimistischen Annahme ausgegangen, dass die Validierung dieser

Aktionen im globalen Zustand nur in Ausnahmefällen fehlschlägt. Diese Aktionen werden

zuerst lokal ausgeführt. Erst danach erfolgt eine Verikation im globalen Zustand. Bei einem

Fehlschlagen der Verikation im globalen Zustand werden diese, wie normale Aktionen, rück-

gängig gemacht. Dieses Konzept wird als Client Side Prediction bezeichnet.

4.1 Komponenten Übersicht

Die Sicherstellung der globalen Konsistenz wird in zwei Komponenten implementiert. Der

Authorative Server Abstraction Layer (auch Authorative Server genannt) implementiert das

Konzept des autoritativen Servers. Die Action Logic implementiert ein Transaktionssystem

für Benutzer Aktionen, Unterstützung für die Auösung von Konikten mit realen Objekt

Referenzen und Client Side Prediction (siehe Abbildung 4.1).

24

4 Entwurf

Die Aktionen werden von der Action Logic implementiert, während der Authorative Ser-

ver die restlichen Funktionalitäten übernimmt. Die Funktionsweise des Authorative Servers

und der Action Logic werden den Abschnitten 4.3 und 4.4 behandelt. Für die Übertragung

der Aktionen und Synchronisationsdaten wird eine eigene Netzwerk Middleware verwendet

(BeardWire). Diese wird in Abschnitt 4.5 besprochen.

Abbildung 4.1: Level 0 Komponentenübersicht.

Die Konstruktionslogik, Physiksimulation

und das Rendering werden in der Xenko

Spiele-Engine implementiert (MasterBeard).

4.2 ExterneSysteme und Bibliotheken

Für das Tracken der Hände (A 1) wird die

LEAP Motion verwendet. Diese erlaubt das

Tracken der Bewegungen der Hände des

Benutzers. Die Software gibt, mit Meta In-

formationen angereicherte, Skelettmodelle

der Hände der Benutzer zurück. Diese ent-

halten bspw. Geschwindigkeit der jeweili-

gen Handknochen. Die Metadaten enthal-

ten auch Informationen über eine Anzahl

an Gesten, die von der Software erkannt

wurden (circle, swipe, key tap, screen tap

1).

Für die Ausgabe (A 6.3 und A 11) und

Physik-Simulation (A 2) wird Xenko2

in der

Version 1.8 verwendet. Diese verwendet die Bullet-Physics-Engine3

und C# 6.0 (in der Master-

Arbeit wurde .Net in der Version 4.6.1 verwendet). Die Parametrisierung der Physik-Engine

erfolgt über die Xenko Editor Anwendung (A 7). Die Vorteile von Xenko gegenüber vergleich-

baren Engines (wie bspw. Unity) sind die Verwendung eines aktuellen .Net Frameworks und

1

https://developer.leapmotion.com/documentation/csharp/devguide/Leap_Gestures.html

2

http://xenko.com/

3

http://bulletphysics.org/wordpress/

25

4 Entwurf

die Auslegung auf Multi Threading.

Für die Kommunikation zwischen mehreren Plattformen und Programmiersprachen ist die

Serialisierungslösung für Netzwerk-Nachrichten der wichtigste Bestandteil. In der Master-

Arbeit wurde sich für Google Protobuf (Version 2) entschieden. Protobuf ist für alle in der

Forschungsgruppe verwendeten Programmiersprachen und Plattformen verfügbar und deutlich

schneller und kompakter als vergleichbare Lösungen wie XML oder JSON. Ein Vergleich mit

anderen Serialisierungslösungen ndet sich in Abschnitt 5.1.5.

4.3 Autoritiativer Server

Der lokale Spiel-Zustand wird durch den World-State repräsentiert. Dieser umfasst alle In-

formationen des lokalen Zustands, die sich zur Laufzeit ändern können. Jeder World-State

implementiert ein Interface das die Generierung einer Checksumme erlaubt. Zusätzlich bietet

das Interface Methoden zur Aktualisierung und zum ersetzen des lokalen World-States an.

Unter Verwendung dieses Interfaces kann der Server von dem konkreten Anwendungsfall

abstrahieren.

Für das Szenario der Master-Arbeit enthält der World-State konkret die Positionen, Rotationen

und Geschwindigkeiten, der Hände sowie alle Bauteile die zur Laufzeit instantiiert wurden.

Jedes Objekt, das vom World-State verwaltet wird, hat eine eindeutige ID. Diese ID ist auf

allen Instanzen gleich. Damit kann das gleiche Objekt auf allen Instanzen eindeutig identiziert

und ggf. aktualisiert werden.

Aus denen im World-State vorhandenen Informationen lässt sich damit ein kompletter

lokaler Zustand generieren. Diese Eigenschaft ist wichtig, um neu verbundene Client Instan-

zen initial zu synchronisieren, den globalen Zustand zwischen allen Instanzen forlaufend zu

synchronisieren und den lokalen Zustands im Koniktfall zurück zu setzen.

Um zu bestimmen ob zwei World-States gleich sind, werden Checksummen verwendet. Das

zurück setzen des lokalen Zustands im Koniktfall ist Teil der Koniktauösung und wird von

der Action Logic implementiert (siehe Abschnitt 4.4).

Der World-State enthält nur Informationen des lokalen Zustands, die sich zur Laufzeit

ändern können. Alle anderen, für die Kollaboration relevanten, Informationen werden nicht

zu Laufzeit übertragen sondern liegen bereits auf allen Instanzen vor. Da der World-State oft

26

4 Entwurf

synchronisiert werden muss, lässt sich dadurch Verwaltungsaufwand und Bandbreite sparen,

was in verringerten Latenzen resultiert.

Bspw. ändern sich die 3D-Modelle, die für die Darstellung der Hände und Bauteile benötigt

werden, zur Laufzeit nicht. Es genügen Informationen über die Position und Rotation des

Bauteils, um dieses korrekt darzustellen. Analog benötigt die Physik-Engine nur Informationen

über die Geschwindigkeit des Bauteils, weil Masse, Kollisionsgeometrie etc. lokal vorhanden

sind.

Das setzt voraus, dass die Informationen auf allen Instanzen identisch sind. Zusätzlich muss die

Logik, die diese Informationen verarbeitet, ebenfalls identisch sein. Sind Informationen oder

Logik unterschiedlich, können die verschiedenen Instanzen bei der Ausführung der gleichen

Aktion zu komplett unterschiedlichen Ergebnissen kommen.

Wenn sich bspw. der Reibungskoezient (Materialeigenschaft in der Physik-Engine) der Hände

auf zwei Instanzen unterscheiden, kann der Benutzer auf einer Instanz ein Bauteil anfassen

und aufheben, während die Finger in der anderen Instanz abrutschen und das Bauteil liegen

bleibt.

Um den globalen Zustand konsistent zu halten, wird der lokale World-State des Servers als

äquivalent mit dem globalen Zustand betrachtet. D.h. wenn eine Inkonsistenz zwischen dem

lokalen World-State des Servers und dem eines Clients auftritt, wird immer der Zustand des

Clients überschrieben. Dies wird für die Synchronisierung der World-States und die Konik-

tauösung mit Hilfe von Actions wichtig. Diese werden im Folgenden beschrieben.

Grundsätzlich umfasst der World-State nur die Informationen, die für die initiale und fort-

laufende Synchronisierung benötigt werden. Alle Informationen, die nicht fortlaufend syn-

chronisiert werden müssen, werden über Actions kommuniziert. Bei Actions handelt es sich

im Prinzip um Ereignisse, die den World-State verändern. Im Szenario der Master Arbeit sind

das bspw. unter anderem die Bewegungen der Hände, der Benutzer oder die Instantiierung

neuer Bauteile.

Jede Action implementiert ein Interface, dass Funktionalitäten für für Validierung, Ausführung,

Feedback und Rollback anbietet. Zusätzlich umfasst jede Action alle Parameter, die für dessen

Ausführung benötigt werden. Der autoritative Server implementiert unter Verwendung dieser

Funktionalitäten eine generische Koniktauösung. D.h. der autoritative Server kann von

dem spezischen Anwendungsfall abstrahieren. Das Wissen über die Spezika des jeweiligen

Anwendungsfalls wird nur in den Actions benötigt. Die genaue Funktionsweise einer Action

27

4 Entwurf

wird in Abschnitt 4.4 besprochen.

Abbildung 4.2: Validierung der Aktion eines Benut-

zers im autoritativen Server Konzept.

Für die Inbetriebnahme wird als erstes die

Server-Instanz gestartet. Diese initialisiert

und startet die lokale Simulation und initia-

lisiert den lokalen World-State. Nach dieser

Initialisierung können sich Client-Instanzen

mit dem Server verbinden. Beim Verbinden

holt sich der Client den World-State vom Ser-

ver. Dieser wird danach in regelmäßigen Ab-

ständen mit dem Server synchronisiert.

Um Bandbreite bei der Synchronisierung zu

sparen, bildet der Server in regelmäßigen

Abständen eine Checksumme seines World-

States und schickt diese an die Clients. Die

Clients bilden beim Empfang eine Checksum-

me des lokalen World-States und vergleichen diese mit der empfangenen. Stellt ein Client fest,

dass die Checksumme seines lokalen Zustandes von der des Servers abweicht, wird der aktuelle

World-State vom Server angefordert. Beim Empfang des World-States vom Server ersetzt

dieser den lokalen World-State. Mit dieser Vorgehensweise wird der komplette World-State

nur verschickt, wenn es notwendig ist.

Über diese Checksummen lassen sich auch Toleranzen implementieren. Die Werte, die in der

Checksumme verwendet werden, müssen dafür auf die gewünschte Toleranz gerundet werden.

Bspw. werden im Szenario der Master-Arbeit alle Zahlenwerte der Positionsinformationen,

Rotationen und Geschwindigkeiten auf drei Stellen nach dem Komma gerundet. Damit wird

erst ein Synchronisationsvorgang ausgeführt, wenn die Inkonsistenzen die Toleranzen über-

schritten haben.

Soll eine Action aufgeführt werden, wird diese als im lokalen World-State validiert. Ist diese

Validierung erfolgreich, wird die Aktion an den Server weitergeschickt, wo sie im lokalen

World-State des Servers (also dem globalen Zustand) validiert wird. Ist auch diese Validierung

erfolgreich, wird die Aktion auf dem Server ausgeführt. Die Ausführung verändert den lokalen

World-State des Servers (also den globalen Zustand). Die Aktion wird dann an die Clients weiter

geschickt und dort ebenfalls validiert und ausgeführt. In Abbildung 4.2 ist dieser Vorgang

nochmal als Sequenz-Diagramm einzusehen. Ein Konikt tritt genau dann auf, wenn eine

28

4 Entwurf

dieser Validierung, ausgenommen der ersten lokalen, fehlschlägt.

Schlägt die Validierung auf dem Server fehl, ist der lokale World-State des Clients, der die

Aktion an den Server geschickt hat, asynchron. Dem Client wird der Fehlschlag mitgeteilt.

Dieser führt nun, wenn notwendig, das Rollback oder Feedback der Aktion aus (mehr dazu in

Abschnitt 4.4) und fordert den aktuellen World-State vom Server an. Sobald dieser eintrit,

wird der lokale World-State mit dem vom Server überschrieben. Damit ist der globale Zustand

wieder synchron.

Schlägt die Validierung auf einem Client fehl, der die Action vom Server erhalten hat, ist der

lokale World-State des Clients asynchron. Dieser fordert den World-State des Servers an. Beim

Empfang des World-States vom Server wird der lokale World-State mit diesem ersetzt. Eine

erneute Ausführung der Aktion ist nicht notwendig, weil der World-State vom Server bereits

von der Action modiziert wurde. Der globale Zustand ist nun wieder synchron.

Die globale Reihenfolge, in der die Actions ausgeführt werden, wird vom Server bestimmt.

Alle Clients senden ihre Actions direkt an den Server, wo diese nach Empfangszeitpunkt

geordnet und dann (bei erfolgreicher Validierung) an die Clients verteilt werden. Eine direkte

Kommunikation zwischen den Clients ndet nicht statt.

Die global eindeutige Ordnung der Ausführung der Actions wird also durch den Empfangs-

zeitpunkt der Actions beim Server bestimmt. Mehrere Actions von mehreren Clients, die sich

gegenseitig ausschließen, können damit aufgelöst werden. Nachrichten, die als erstes emp-

fangen wurden, werden als erstes ausgeführt. Diese invalidieren durch die Änderungen des

World-States ggf. später empfangene Nachrichten. Die Validierung der später empfangenen

Nachrichten schlägt dann auf dem Server fehl und der Konikt wird wie bereits beschrieben

aufgelöst.

Actions werden über Netzwerk-Nachrichten kommuniziert. Diese Netzwerk-Nachrichten

werden immer jeweils zwischen genau zwei Instanzen ausgetauscht. Entweder werden Nach-

richten von einem Client zum Server oder vom Server zu einem Client geschickt. Jeder Client

hat dabei genau eine Verbindung zum Server, während der Server jeweils genau eine Verbin-

dung zu jedem Client unterhält.

Um diese globale Ordnung über Actions zu ermöglichen muss sichergestellt werden, dass die

Nachrichten zwischen zwei Instanzen zuverlässig und in der richtigen Reihenfolge übertragen

werden. D.h. die Nachrichten gehen nicht verloren, bleiben intakt und kommen in der Reihen-

29

4 Entwurf

folge beim Empfänger an in der sie versendet wurden. Diese Problematik wird in Abschnitt 4.5

behandelt.

Der große Vorteil der globalen Ordnung über Actions, die vom Autoritiativen Server im-

plementiert wird, ist Ezienz. Die globale Reihenfolge der Nachrichten ist äquivalent mit der

Reihenfolge in der die Actions vom Server empfangen wurden.

Die Verbindungen zu den verschiedenen Clients sind unabhängig voneinander. Damit ist es

möglich, dass Action A vor Action B ausgeführt wurde, B aber vor A auf dem Server empfangen

wird. Damit ist die globale Reihenfolge der Actions zwar eindeutig, entspricht aber nicht der

realen Reihenfolge in der die Actions wirklich ausgeführt wurden.

Solange die Nachrichtenübertragung deutlich schneller als die Reaktionszeit der Benutzer

ist, ergeben sich im Normalfall keine Probleme. Die durchschnittliche Reaktionszeit eines

Menschen liegt bei 0,2s (200 ms) [Tesser und Schwarz (1994)]. D.h. die Ausführung einer

Nachricht sollte in auf dem Client in unter 100 ms sichtbar werden, um auch Menschen mit

überdurchschnittlich schnellen Reaktionszeiten abzudecken.

Damit sich in diesem Fall die reale und globale Reihenfolge der Nachrichten unterscheiden,

müssen zwei Bedingungen zutreen. Erstens müssen mindestens zwei Benutzer quasi gleich-

zeitig (wenige Millisekunden Dierenz) eine Aktion ausführen. Zweitens muss die Nachricht

der späteren Action als erstes beim Server eintreen. Selbst dann ist es unwahrscheinlich,

dass die Dierenz der realen und globalen Ausführungsreihenfolge, aufgrund der niedrigen

Latenzen, von den Benutzern bemerkt wird.

Das gilt natürlich nur, wenn die Latenzen entsprechend gering gehalten werden. Für deutlich

höhere Latenzen als 200 ms funktioniert das Konzept nicht mehr. Theoretisch ist es technisch

möglich eine zuverlässige Ordnung über allen kausal abhängigen Aktionen der Benutzer her-

zustellen (bspw. Lamport Zeitstempel). Dies verursacht aber einen deutlich höheren Overhead.

Aufgrund der Interaktivität der Anwendung sind geringe Latenzen also einer zuverlässigen

globalen Ordnung der Actions vorzuziehen.

Für nicht deterministische Aktionen reicht es in den meisten Fällen aus, den World-State

fortlaufend zu synchronisieren. Sollte das nicht reichen gibt es die Möglichkeit, direkt nach

der Ausführung jeder Aktion die Checksummen der World-States zu vergleichen und ggf. eine

Synchronisierung vorzunehmen.

Die Klassen, die die Kern-Funktionalität des autoritativen Servers implementieren, sind

der AuthorativeClient und AuthorativeServer. AuthorativeClients verbinden sich mit einem

30

4 Entwurf

Abbildung 4.3: Authorative Server Level 1 Klassendiagramm.

AuthorativeServer (siehe Abbildung 4.3). Beide implementieren das IAuthorativeRemote und

IActionExecutor Interface. Das IActionExecutor Interface bietet Aktionen für die Validierung

und Ausführung von Aktionen an. Je nachdem, ob es sich um einen AuthorativeClient oder

AuthorativeServer handelt, unterscheidet sich die Implementation der Ausführung der Aktio-

nen. Der AuthorativeClient validiert die Aktion lokal, sendet diese an den Server und wartet

dann auf eine Antwort. Der AuthorativeServer validiert die Aktion, führt diese aus und sendet

diese dann weiter an die Clients.

Abbildung 4.4: Zwei Clients die mit einem Server verbunden sind. Die für die Ausführung verwendeten

Instanzen unterscheiden sich nur in der Implementation des IAuthorativeRemotes. Beim Server handelt

es sich um einen IAuthorativeServer. Beim Client um einen IAuthorativeClient.

31

4 Entwurf

Von außerhalb der Komponente wird nur das IAuthorativeRemote Interface referenziert.

Damit kann der Rest der Anwendung davon abstrahieren, ob die Anwendung in der Rolle eines

Clients oder Servers agiert (siehe Abbildung 4.4).

IAuthorativeClient und IAuthorativeServer Instanzen werden über die AuthorativeRemo-

teFactory bezogen, die die NetworkMessageRegistration nutzt, um die intern verwendeten

Netzwerk Nachrichten zu registrieren.

4.4 Action Logic

Abbildung 4.5: Action Logic Level 1 Klassendiagramm.

Alle Actions implementieren das IAction Interface, welches vier Methoden anbietet: Vali-

dierung, Ausführung, Feedback und Rollback. Alle Methoden arbeiten auf Grundlage eines

IWorldState, der als Parameter übergeben wird. Im Fall der Ausführung und des Rollbacks

wird dieser destruktiv verändert. Validierung und Feedback erfordern nur lesenden Zugri

und verändern den gegebenen IWorldState nicht.

Abbildung 4.6: Interfaces der action logic.

32

4 Entwurf

Alle Klassen, die Aktionen ausführen (bspw. AuthorativeClient), implementieren das IActio-

nExecutor Interface. Dieses bietet die Möglichkeit, Aktionen auszuführen und gibt als Ergebnis

der Ausführung ein IActionExecutionRequestResponse Objekt zurück. Dieses enthält Infor-

mationen darüber, ob die Ausführung erfolgreich war, bereits ausgeführt wurde und ob ein

Rollback notwendig ist.

Die konkrete Implementation aller Interfaces erfolgt durch den Anwendungsfall. IActions

sind generisch und werden immer für eine bestimmte IWorldState Klasse implementiert (siehe

Abbildung 4.6). Die Implementierung der IActions und IWorldStates erfolgt durch den Anwen-

dungsfall.

Das IActionExecutor Interface ist ebenfalls generisch. Es werden aber keine eigenen Imple-

mentierungen für jeden IWorldState benötigt. Der IActionExecutor verwendet nur die von

IWorldState und IAction angebotenen Methoden. Bei der Initialisierung eines neuen IActio-

nExecutors reicht es den jeweiligen IWorldState Typ als generischen Parameter zu übergeben.

Alle generischen Parameter sind so konguriert, dass sie nur Klassen zulassen die von IWorld-

State bzw. IAction erben.

Für IAuthorativeServer und IAuthorative Instanzen gilt das gleiche. Es wird keine spezische

Implementation für den Anwendungsfall benötigt. Bei der Initialisierung über die Factory

muss nur der gewünschte IWorldState als generischer Parameter angegeben werden. Die

ActionLogic und der AuthorativeServer können damit von dem eigentlichen Anwendungsfall

abstrahieren.

Zur Validierung implementiert eine Action ein Prädikat, welches wahr ist, wenn die Action

im übergebenen World-State ausgeführt werden kann. Bspw. wird im Prädikat einer Action,

die ein neues Bauteil instantiiert, überprüft, ob es bereits ein Bauteil mit dieser ID gibt. Wenn

das nicht der Fall ist, ist das Prädikat wahr und die Action im gegebenen World-State valide.

Die Ausführung implementiert Anweisungen, wie der übergebene World-State verändert

werden soll. Jede Action enthält Parameter für die Ausführung. Wenn die Action bspw. ein

neues Bauteil instantiiert, enthalten die Parameter Informationen über ID, Typ, Position, Rota-

tion und Skalierung des Bauteils.

Die Ausführung der Action verändert den übergebenen World-State destruktiv, weil Eigenschaf-

ten von Objekten im World-State verändert werden oder neue Objekte hinzugefügt werden.

Das Feedback implementiert Anweisungen, um dem Benutzer bei Konikten mit realen

Objekt Referenzen eine Hilfestellung für die Auösung zu geben. Bspw. kann es sein, dass die

33

4 Entwurf

Position der realen Hand und dessen virtueller Repräsentation divergieren. Das ist bspw. dann

der Fall, wenn die Hand in ein Bauteil eindringen würde. Dem Benutzer kann in diesem Fall

eine weitere virtuelle Repräsentation seiner realen Hand angezeigt werden, um den Unter-

schied der Positionen zu visualisieren. Diese zusätzliche virtuelle Repräsentation kollidiert

nicht mit Bauteilen. Das Ziel ist es, die Virtualität mit der Realität durch geeignetes Feedback

zu synchronisieren.

Das Feedback wird immer nur dem jeweiligen lokalen Benutzer angezeigt. Der übergebene

World-State wird nur dazu verwendet, das Feedback zu generieren. Der World-State umfasst

nur Informationen, die für alle Benutzer relevant sind. Da das Feedback nur für den lokalen

Benutzer Relevanz hat, wird der World-State nicht verändert.

Die Rollback Funktionalität macht alle Änderungen der Aktion rückgängig. Wenn die Aktion

bspw. ein neues Bauteil instantiiert hat, würde das Rollback dieses löschen.

Jeder Anwendungsfall hat eine Menge von Actions, die die möglichen Aktionen in diesem

Anwendungsfall repräsentieren. Jede dieser Actions implementiert die vier Methoden: Validie-

rung, Ausführung, Feedback und Rollback für den jeweiligen Anwendungsfall. Validierung,

Ausführung und Rollback ermöglichen im Zusammenspiel mit dem autoritativen Server ein

generisches Transaktionssystem für Actions, weil der Autoritative Server kein Wissen über

den Anwendungsfall haben muss.

Durch das Feedback lassen sich Konikte mit realen Objekt Referenzen durch Synchronisierung

der Virtualität mit der Realität generisch auösen.

4.5 Netzwerk Middleware

Wie in Abschnitt 4.3 erläutert, kann der Autoritative Server eine globale Ordnung über allen

Actions herstellen, wenn die Übertragung von Nachrichten zwischen zwei Instanzen zuverläs-

sig und in der richtigen Reihenfolge erfolgt. D.h. die Nachrichten gehen nicht verloren, bleiben

intakt und kommen in der Reihenfolge beim Empfänger an in der sie versendet wurden.

Außerdem ist die Minimierung der Latenzen ein primäres Ziel. Da die gesamte Kommunikation

zwischen den Instanzen der Anwendung über die Netzwerk-Middleware läuft, werden die

Funktionalitäten zur Nachrichtenordnung entsprechend oft aufgerufen. Durch die hohe Anzahl

an Aufrufen können die Latenzen an dieser Stelle besonders mit Optimierungen reduziert

34

4 Entwurf

werden.

Um die Anforderungen für die Nachrichtenordnung von zuverlässigen und zuverlässigen

verschlüsselten Nachrichten (siehe Abschnitt 3.4) zu erfüllen, bietet sich das TCP-Protokoll

an. Dieses ist bereits im Betriebssystem integriert und hoch optimiert. Eine Alternative ist der

Nachbau spezischer TCP-Mechanismen auf Anwendungsebene mit UDP. Das ist lohnt sich

aber nur dann, wenn nur ein Teil der Konsistenz-Anforderungen des TCP-Protokolls benötigt

werden.

UDP bietet sich für den Versand unzuverlässiger Nachrichten an, die keine Konsistenzanforde-

rungen erfüllen müssen.

Für das Verschicken der Nachrichten über das Netzwerk werden diese in ein Byte-Array

serialisert. Beim Empfangen werden die Byte-Arrays zurück in Nachrichten deserialisiert. Für

die Serialisierung und Deserialisierung wird Google Protobuf verwendet.

Die API der Netzwerk Middleware bietet Methoden für die Verbindung zu anderen Instan-

zen und dem Versenden von allen in Abschnitt 3.4 geforderten Nachrichtentypen. Listener

schreiben sich auf die für sie relevanten Nachrichtentypen ein und werden beim Empfang

benachrichtigt. Außerdem bietet die API Events für neu geönete und geschlossene Verbin-

dungen an.

Alle Nachrichten sind nur für einen sehr begrenzten Zeitraum relevant. Eine Persistierung

der Nachrichten wie bei Queue-Anwendungen (bspw. Rabbit MQ4) wird nicht benötigt. Da

die Minimierung der Latenzen entscheidende Bedeutung hat, wird bewusst auf eine dedizierte

Software-Infrastruktur zur Nachrichtenübermittlung (wie Queues) verzichtet. Diese würde

einen Umweg für die Nachrichten bedeuten und damit die Latenz erhöhen. Eine Übersicht der

genauen Funktionsweise folgt in Kapitel 5.

4.6 Zusammenfassung

Für das Hand-Tracking, Rendering und die Physik-Simulation werden die LEAP Motion und

Xenko verwendet. Für die Sicherung der globalen Konsistenz wird eine Erweiterung des Kon-

zepts des autoritativen Servers aus der Spieleentwicklung verwendet. Diese wird durch den

Authorative Server und die Action Logic implementiert. Diese implementieren in Kombinati-

4

https://www.rabbitmq.com/

35

4 Entwurf

on eine generische Koniktauösung und Synchronisation für verteilte MR-Konstruktions-

Anwendungen. Für Benutzer Aktionen wird ein Transaktionssystem implementiert, welches

das Zurücksetzen von Aktionen im Koniktfall und Feedback an den Benutzer ermöglicht.

36

5 Implementierung

Im Folgenden wird die genaue Umsetzung der in Abschnitt 4.5 vorgestellten Netzwerk Middle-

ware besprochen. Abschnitt 5.1 beschreibt die technische Umsetzung der Netzwerk-Middleware.

Unter anderem wird aufgezeigt, warum Protobuf als Serialisierungslösung verwendet wurde,

welches Protokoll verwendet wird und wie die API der Middleware verwendet wird.

5.1 Implementation Netzwerk Middleware

Metrik Wert

Total Lines of Code 5557

Average maintainability index 86,34352159

Average cyclomatic complexity 6,118272425

Average Class coupling 4,429900332

Average Depth of inheritance 1,3

Jetbrains Dot Cover Test Coverage 70%

Tabelle 5.1: Visual Studio Code Metriken für die Netzwerk-Middleware (siehe VisualStudioCodeMetrics).

Die Netzwerk Middleware wurde entwickelt, um objektorientiert, sprachübergreifend und

performant alle Systeme der Forschungsgruppe i2e über das Netzwerk zu verbinden. Um diese

Ziele zu erreichen, wurde Protobuf als unterliegende Serialisierungslösung gewählt. Protobuf

ist für alle in der Forschungsgruppe verwendeten Programmiersprachen (C++, C#, Java, Python)

verfügbar (protobuf) und deutlich schneller und kompakter als vergleichbare Lösungen (siehe

Abbildung 5.1, 3-10 mal kleiner und 20 bis 100 mal schneller als XML (protobufspeed) und

deutlich schneller und kleiner als JSON (siehe Abbildung 5.4)). Es existieren Implementationen

der Middleware für Java1, C++

2und C#.

1

implementiert von Raimund Wege

2

implementiert von Iwer Petersen

37

5 Implementierung

Abbildung 5.1: Testergebnisse für die Serialiserung von verschiedenen Binary Serialisierungs Biblio-

theken in C# (Test-Hardware siehe Tabelle 6.1). HandCoded dient als Referenz für eine von Hand

programmierte Klassen spezische Serialisierung. Für den Test wurde der BinarySerializersSpeedTest

von SimpleSpeedTester verwendet.

Bevor eine Nachricht mit der Middleware verschickt oder empfangen werden kann benötigt

diese eine ID, die auf allen anderen Instanzen, an die die Nachricht verschickt werden soll,

gleich ist. Dies Registrierung der Nachrichten kann einzeln als Methodenaufruf, per CSV-Datei

oder per Marker-Interface erfolgen. Im letzten Fall werden alle Assemblies nach Klassen durch-

sucht die das Marker-Interface implementieren. Diese werden aufsteigend nach ihrem voll

qualizierten Type-Namen sortiert und bekommen in dieser Reihenfolge aufsteigende IDs

zugewiesen. Eine gleiche Implementation vorausgesetzt ist damit sichergestellt, dass die IDs

auf allen Instanzen gleich sind. Die genaue Implementierung der Nachrichten IDs wird in

Abschnitt 5.1.2 erklärt.

Um zur Laufzeit zu überprüfen, ob die Nachrichten IDs auf allen verbundenen Instanzen

gleich sind, kann eine MD5-Checksumme über allen registrierten Nachrichten generiert werden.

Diese Checksumme wird dann bei der Verbindung mit einer neuen Instanz verglichen. Stim-

38

5 Implementierung

men die Checksummen nicht überein, wird die Verbindung abgebrochen und ein Fehler geloggt.

Abschnitt 5.1.1 gibt eine Übersicht der Komponenten der Middleware. Abschnitt 5.1.5 gibt

eine Übersicht über vorhandene Netzwerk Middleware Lösungen und erklärt, warum diese

nicht verwendet wurden.

Abschnitt 5.2 zeigt Verbesserungsmöglichkeiten für zukünftige Arbeiten auf. Es gibt unter

anderem neue Serialisierungs-Formate, die ezienter als die derzeit verwendeten sein könnten.

5.1.1 Netzwerk Middleware Komponenten

Abbildung 5.2: Netzwerk Middleware Level 1 Klassendiagramm.

Die Netzwerk Middleware setzt sich aus mehreren Assemblies zusammen (siehe Abbildung

5.2). BeardWire implementiert alle Funktionalitäten für die Übertragung von Nachrichten über

TCP und UDP. Der CongFileReader liest Nachrichten und IDs aus einer gegebenen Datei aus

39

5 Implementierung

und registriert diese in der Middleware (siehe Abschnitt 5.1.2). BeardLogger implementiert

mehrere Logging Mechanismen für alle anderen Komponenten. Im BeardUtilities Assembly

sind generische Utility Klassen für verschiedenste Aufgaben zusammen gefasst. Beispiele sind

Methoden, die alle Klassen in allen geladenen Assemblies zurückgeben, die ein bestimmtes

Interface implementieren oder Extension Methoden für Strings, Tasks und Sockets.

Die INetworkAdapter Instanz dient als Fassade der Middleware und verwaltet alle anderen

Komponenten. Grundlegende Netzwerk-Operationen, wie das Verbinden mit Gegenstellen und

der Versand von Byte-Arrays über TCP und UDP, werden vom SocketAdapter implementiert.

Die Komponente verwaltet oene Ports und aktive Verbindungen und stellt Events für neue

Verbindungen, eintreende Byte-Arrays und Verbindungsabbrüche bereit.

Nachrichten werden von der IMessageSerialization für den Versand in Byte-Arrays serialisiert

und beim Empfang in Objekte deserialisiert. Die IDs der einzelnen Nachrichten werden von

der IMessageTypeSerialization verwaltet. Um die Ver- und Entschlüsselung der Nachrichten

auf Byte-Array Ebene kümmert sich die IMessageEncryption.

Die Middleware bietet die Möglichkeit, eine Nachricht zu schicken und danach auf eine Antwort

zu warten. Die Verwaltung der oenen Nachrichten, ohne Antworten und die Beantwortung

der Nachrichten, wird von IResponseMessageHandling übernommen.

IMessageSubscription verwaltet alle Listener, die auf bestimmte Nachrichtentypen eingeschrie-

ben sind. Die NetworkAdapterFactory referenziert alle Interfaces um INetworkAdapterInstan-

zen per IOC-Container zusammen zu bauen. Alle Komponenten werden nur über Interfaces

referenziert um einfach austauschbar zu sein.

Beim Versand einer TCP Nachricht (mittels INetworkAdapter) werden die Nachricht selbst

und die Ziel-Adresse und Port übergeben. Es wird geprüft, unter welcher ID die Nachricht

registriert ist (IMessageTypeIdentication) und ob eine aktive Verbindung zum Ziel besteht

(ISocketAdapter).

Im nächsten Schritt wird die Nachricht serialisiert (IMessageSerialization), ggf. verschlüsselt

(IMessageEncryption) und unter Angabe der Nachrichten ID (die mit verschlüsselt wird) an

das Ziel geschickt (ISocketAdapter).

Beim Empfang der Nachricht (ISocketAdapter) wird die Nachricht ggf. entschlüsselt (IMes-

sageEncryption) und die ID ausgelesen, um den Typ der Nachricht zu bestimmen (IMessa-

geTypeIdentication). Mit dem Typ kann die empfangene Nachricht deserialisiert werden

(IMessageSerialization). Mit der fertigen Nachricht werden nun die Listener benachrichtigt

40

5 Implementierung

1 0,ErrorOnProcessingMessage2 1,NetworkMessage3 2,ObjectLost4 3,ObjectNew5 4,PositionChanged6 5,RotationChanged

Listing 5.1: Identier für Netzwerk-Nachrichten in

einer CSV-Datei.

Test Protobuf 2 BSON

Serialisierung+

Deserialisierung [ms] 168,8475 326,7599

Größe [byte] 274 362

Abbildung 5.3: Serialisierungsergebnisse einer ein-

fachen C# Klasse in Protobuf 2 (Protobuf.net) und

BSON (MongoDB BSON). Zum Testen wurde die

Klasse jeweils 10000 mal serialisiert und deseriali-

siert.

(IMessageSubscription).

Alle Komponenten der Middleware implementieren ein eigenes Interface und werden nur

über dieses von außerhalb der Komponenten referenziert. Die Factory bietet die Möglichkeit,

einen IOC-Container mit modizierten Implementationen für diese Interfaces zu übergeben.

Damit kann von außen die Implementierung innerer Komponenten überschrieben werden.

Dies erlaubt es bspw. die Serialisierungslösung auszutauschen, ohne den Programmcode der

Middleware anzupassen.

Da der Logging-Adapter je nach Anwendungsfall oft ausgetauscht wird, kann dieser über einen

eigenen Parameter übergeben werden. Dies ist einfach nur ein Shortcut, der den Adapter im

IOC-Container registriert. Von Haus aus bietet die Middleware einen File-Logger in synchroner

und asynchroner Variante und einen Konsolen-Logger an.

5.1.2 Nachrichten IDs

Die Implementation einer Nachricht muss auf allen kommunizierenden Instanzen bekannt

sein. Bevor eine Nachricht versendet werden kann muss diese mit einer eindeutigen ID (int32)

registriert werden. Diese IDs müssen auf allen Instanzen gleich sein. So muss später bei der

Übertragung nur noch die ID der Nachricht und nicht der voll qualizierte Name geschickt

werden.

Um gleiche IDs auf allen Instanzen sicherzustellen gibt es mehrere Möglichkeiten:

• Congure by Code - RegisterMessageType Methode im INetworkAdapter

• CSV-Datei - siehe Listing 5.1

41

5 Implementierung

5.1.3 Netzwerk Middleware Protokoll

Die Netzwerk Middleware unterstützt TCP und UDP für die Nachrichtenübertragung. Für die

Herstellung von Verbindungen wird der TCP Standard verwendet. Es sind keine Funktionalitä-

ten vorgesehen, um UDP-Nachrichten verlässlicher zu machen.

Alle serialisierten Nachrichten werden in einer NetworkMessage (siehe Listing 5.2) gekap-

selt, die Meta-Informationen für die Nachricht bereitstellt. Das Format der Nachricht benutzt

Protobuf 2. Das Wire-Format für UDP Nachrichten enthält genau die NetworkMessage als

Byte-Array. Nachrichten, die über TCP Verbindungen verschickt werden, bestehen aus einer

int32, die die Nachrichtenlänge angibt, und der NetworkMessage als Byte-Array.

1 // Default message used for network communication. Provides meta-information for an arbitrary payload message.2 package NetworkMessages;3

4 message NetworkMessage5 6 // Reserve field numbers 100 to 199 for extensions.7 extensions 100 to 199;8

9 // Determines if the message needs a response. All messages that need a response will also need to have aunique transactionId.

10 optional bool requiresAnswer = 1 [default = false];11

12 // A globally unique identifier for a transaction. The response to this message will be sent using thisid. This field will only be used, if the message needs an answer.

13 optional bytes transactionId = 2;14

15 // Identifies the type of the payload message. This ID is unique for each type of message.16 required int32 messageTypeId = 3;17

18 // The payload message. This message is serialized using the Google protobuf wire format. No specialfeatures of language specific protobuf implementations may be used! The message must be wirecompatible to the Google Protobuf 2 standard!

19 required bytes payloadMessage = 4;20

Listing 5.2: Protobuf Standard Network Message.

5.1.4 Netzwerk Middleware API

Um einen Überblick über die Funktionsweise der API zu bekommen, wird im Folgenden ein

einfaches Server-Client Beispiel vorgestellt. Um das Beispiel so einfach wie möglich zu halten,

laufen Client und Server auf localhost und alle Parameter sind hart kodiert. Aus diesem Grund

wird auch die Fehlerbehandlung komplett ignoriert.

Bei der Instantiierung des Servers und Clients wird eine einfache Test Nachricht (siehe Listing

5.3) mit der gleichen ID registriert. Server und Client initialisieren außerdem jeweils eine

INetworkAdapter Instanz mit Default-Werten. Nach dem Aufruf von StartHosting() (siehe

Listing 5.5), können Clients sich mit der Methode ConnectToServer() mit dem Server verbinden.

Nachdem Server und Client verbunden sind, kann der Client mit SendTestMessageToServer()

42

5 Implementierung

Nachrichten an den Server senden. Am Ende schließt der Client die Verbindung mit Dis-

connect() und der Server schließt alle oenen Ports und Verbindungen mit StopHosting().

Verbindungs Aufbauten und Abbrüche können über die Events TCPConnectionEstablished

und TCPConnectionClosed registriert werden. Da eine Verbindung zu jedem Zeitpunkt abbre-

chen kann, bietet die Middleware eine Reihe von Exceptions, die die Ausnahmebehandlung

erleichtern sollen. Alle Methoden der API werfen eine genau denierte Menge an Exceptions

(siehe Namespace BeardWire/Interface/Exceptions). Die verursachenden Exceptions werden

dabei im Member InnerException gekapselt - die wieder eine InnerException haben kann.

Dadurch wird die Fehlerbehandlung vereinfacht und verhindert, dass das Programm durch

unerwartete Exceptions abbricht (C# hat keine checked Exceptions).

Bspw. lösen alle Fehler beim Nachrichtenversand eine FailedToSendMessageException aus. Die

InnerException gibt dabei den genauen Grund an, warum die Nachricht nicht versendet werden

kann. Ist die InnerException vom Typ NotConnectedException, besteht keine TCP-Verbindung

zum Addressaten, oder die Verbindung ist vor dem Senden abgebrochen. Im Fall von UDP

sagt eine UnsupportedMessageSizeException, dass die Nachricht zu groß für den Versand

in einem UDP-Paket ist. Im Fall, das die Nachricht nicht serialisiert werden kann, weil ein

Programmierfehler vorliegt, ist die entsprechende Exception in der InnerException zu nden.

1 [ProtoContract] // Annotation for protobuf-net https://github.com/mgravell/protobuf-net2 public class TestMessage : IExtensible /* The TestMessage inherits from the IExtensible Interface (of protobuf

net) that denotes types that can be serialized by protobuf. */3 4 private IExtension extensionObject; // protobuf-net internal5

6 protected TestMessage()7 8 9

10 public TestMessage(int testIntValue, string testStringValue)11 12 this.TestIntValue = testIntValue;13 this.TestStringValue = testStringValue;14 15

16 // Each member of the class that should be serialized, needs an integer to identify it. Members without anannotation will not get serialized. Picking integers below 10 is most efficient.

17 [ProtoMember(1)]18 public int TestIntValue get; private set; 19

20 [ProtoMember(2)]21 public string TestStringValue get; private set; 22

23 // Internal protobuf-net magic for more customization. In most cases this isn’t needed and the standardimplementation shown below can be used.

24 public IExtension GetExtensionObject(bool createIfMissing)25 26 return Extensible.GetExtensionObject(ref this.extensionObject, createIfMissing);27 28

43

5 Implementierung

Listing 5.3: Einfache Test Nachricht.

1 public class TestClient2 3 private INetworkAdapter client;4

5 public TestClient()6 7 // Get a INetworkAdapter instance with the default settings.8 this.client = NetworkAdapterFactory.GetNewNetworkAdapter();9

10 // Before sending or receiving messages, we first need to register the message with the sameidentifier on all remotes.

11 this.client.RegisterMessageType<TestMessage>(0);12 13

14 public void ConnectToServer()15 16 // Connect to the TestServer. For this minimal example the server is running on localhost on a

fixed port.17 this.client.ConnectToTCPRemote(IPAddress.Parse("127.0.0.1"), 30000);18 19

20 public void Disconnect()21 22 // Close all open connections.23 this.client.Shutdown();24 25

26 public void SendTestMessageToServer()27 28 // Create a new instance of our simple TestMessage with some fixed values.29 var testMessage = new TestMessage(42, "Hello Dave...");30

31 // Send the message to the server over TCP. For this to work, you will need to callConnectToServer() first. Otherwise you will get a NotConnectedException.

32 this.client.SendMessageOverTCP(testMessage, IPAddress.Parse("127.0.0.1"), 30000)33 34

Listing 5.4: Minimaler Client.

1 public class TestServer2 3 private INetworkAdapter server;4

5 public TestServer()6 7 // Get a INetworkAdapter instance with the default settings.8 this.server = NetworkAdapterFactory.GetNewNetworkAdapter();9

10 // Before sending or receiving messages, we first need to register the message with the sameidentifier on all remotes.

11 this.server.RegisterMessageType<TestMessage>(0);12

13 // Register a simple listener for TestMessage instances that just prints the contents of themessage to the console. You can define an arbitrary amount of listeners for a message type.

14 this.server.SubscribeToMessagesOfType<TestMessage>(15 (message, remoteIPEndpoint, localEndpoint, transactionId) =>16 Console.WriteLine("Received a message with the following values " +

message.TestIntValue + ", " + message.TestStringValue));17 18

44

5 Implementierung

19 public void StartHosting()20 21 // Start to listen for connection requests on the specified port.22 this.server.StartAcceptingConnectionsOnTCPPort(30000);23 24

25 public void StopHosting()26 27 // Stop listening for connection requests on all open ports and close all connections.28 this.server.Shutdown();29 30

Listing 5.5: Minimaler Server.

Eine Kernfunktionalität, die für den autoritativen Server gebraucht wird, ist der Versand

von Nachrichten, die eine Antwort benötigen. Der Hauptanwendungsfall sind die Anfragen

für die Ausführung von Aktionen. Diese müssen vom Server bestätigt werden, bevor diese in

Kraft treten können. Diese Methode benutzt die Möglichkeiten für asynchrone Aufrufe in C#

4.6 (siehe Listing 5.6).

1 // Send a message to the server that needs a response.2 var testMessage = TestMessageFactory.GetTestMessage();3 var responseTask = networkAdapter.SendMessageOverTCPThatRequiresAnAnswerAsync<TestMessage, TestMessageResponse>(4 testMessage,5 serverAddress,6 serverPort);7

8 // ... do something else while waiting for the response to arrive ...9

10 // Get the response from the server if it has arrived, otherwise block until it arrives.11 var response = responseTask.Result;12

13 // We could also await the response without blocking...14 var nonBlockingResponse = await responseTask;

Listing 5.6: Senden einer Nachricht die eine Antwort benötigt.

5.1.5 Vorhandene Netzwerk Middleware Lösungen

Im folgenden werden die verbreitetsten Netzwerk Middleware Lösungen vorgestellt und deren

Vor- und Nachteile gegenüber der Netzwerk-Middleware besprochen. Eine erschöpfende

Evaluierung aller Alternativen ist aufgrund der Vielzahl der Middleware Lösungen3

nicht

möglich.

REST Webservices

Bei einem Webservice handelt es sich um einen Dienst, der über eine URI erreichbar ist, in

den meisten Fällen HTTP als Kommunikationsprotokoll verwendet und XML oder JSON zur

3

Einige Beispiele für andere Netzwerk Middleware Lösungen: NetworkComms.Net, CaptainsMess, DarkRift,

SuperSocket, ULink, Forge Networking, Play Fab, Tnet, Bolt, MassiveNet und Smart Fox Server.

45

5 Implementierung

Abbildung 5.4: Testergebnisse für die Serialiserung von verschiedenen JSON Bibliotheken in C# (Test-

Hardware siehe Tabelle 6.1). Jil ist zwar in der Deserialisierung schneller als Protobuf, produziert dabei

aber mehr als doppelt so große Nachrichten und ist langsamer in der Serialisierung. Für den Test wurde

der JsonSerializersSpeedTest von SimpleSpeedTester verwendet.

Serialisierung nutzt. Die Beschreibung der Schnittstelle erfolgt in XML (meistens WSDL).

Protobuf ist 3-10 mal kleiner und 20 bis 100 mal schneller als XML (protobufspeed. In Perfor-

mance Tests (Test-Hardware siehe Tabelle 6.1) liefert Protobuf deutlich bessere Ergebnisse als

JSON (siehe Abbildung 5.4). Da Performance eine der Hauptanforderungen an die Middleware

ist, wird von der Verwendung von JSON und Webservices abgesehen.

eues

Eine Queue ist eine nachrichtenorientierte Middleware, die eine synchrone oder asynchrone

Kommunikation bereitstellt. Das Format für Nachrichten ist zwar nicht formal festgelegt, in

der Praxis wird aber meistens XML oder JSON verwendet.

Die Kommunikation erfolgt über einen dedizierten Server - dem Message Broker - an dem

sich alle an der Kommunikation beteiligten Systeme angemeldet haben. Alle Nachrichten

46

5 Implementierung

werden an diesen Server gesendet und von dort aus an alle Adressaten verteilt. Beliebte

Implementierungen für Queues sind RabbitMQ und ZeroMQ.

Diese Architektur hat folgende Vorteile4:

• Asynchrone sowie synchrone Kommunikation möglich

• Server/Dienst muss nicht sofort verfügbar sein

• Message-Warteschlangen

• Lose Kopplung von Server/Clients

• Mehr Toleranz für Änderungen der bestehenden Funktionen

• Verbesserte Verfügbarkeit der Systeme

• Parallele Verarbeitung von Nachrichten möglich

Die Vorteile einer Message Queue werden im Kontext dieser Arbeit nicht genutzt. Da es

sich um eine interaktive Anwendung handelt, sind die Zeitspannen, in der die Nachrichten

Relevanz haben, sehr gering. Wenn der Adressat einer Nachricht nicht verfügbar ist, nützt eine

Persistierung und spätere Zustellung der Nachricht nichts.

Für die Lösung der Master-Arbeit ist es wichtig, dass die Implementationen auf allen Instanzen

gleich sind. Bspw. ist es wichtig, dass die Implementation für die Ausführung von Aktionen

auf allen Instanzen gleich ist, um die gleichen Ergebnisse bei der Ausführung zu erhalten. Der

Vorteil einer losen Kopplung (und damit der Resistenz gegen Änderungen) würde damit in der

Master-Arbeit nicht genutzt werden.

Latenzen sind für interaktive Anwendungen von entscheidender Bedeutung. Der Umweg über

den zentralen Server, der die Nachrichten nur weiter schickt, bringt zusätzliche Latenzen, die

vermieden werden sollten.

Wenn sich genug Nachrichten in einer Warteschlange angehäuft haben, um eine dedizierte

Infrastruktur zu rechtfertigen, ist davon auszugehen, dass der Adressat mit der Verarbeitung

der Nachrichten überfordert ist. In diesem Fall nützt die große Kapazität und Verlässlich-

keit der Nachrichten Warteschlange nichts, weil die Anwendung nicht mehr benutzbar ist.

Message Queues sind aus diesen Gründen für den Anwendungsfall dieser Arbeit nicht geeignet.

4

Quelle: https://de.wikipedia.org/wiki/Message_Oriented_Middleware

47

5 Implementierung

WCF - Windows Communication Foundation

Windows Communication Foundation ist eine dienstorientierte Lösung für die Netzwerk Kom-

munikation in Microsoft Windows und ist seit .Net 3.0 fester Bestandteil des .Net Frameworks.

WCF ist mit Java Webservices interoperabel und kann von anderen Programmiersprachen, die

REST Schnittstellen ansprechen können, verwendet werden.

WCF teilt das Prinzip des Endpunktes in Address, Binding und Contract (ABC-Prinzip) auf.

Die Address ist eine URI, die beschreibt wo der Dienst erreichbar ist. Das Binding beschreibt

welche Kodierung (binär, SOAP, eigenes Format) und welches Protokoll (HTTP, TCP, UDP

etc.) zur Kommunikation genutzt wird. Der Contract ist die Dienst Denition, die primär die

verfügbaren Methoden deniert.

Um alle geforderten Programmiersprachen abzudecken, kommt nur eine Kommunikation

über REST-Schnittstellen in Frage, die die Anforderungen nicht erfüllt (siehe Abschnitt 5.1.5).

Lidgren

Lidgren ist eine C# Netzwerk Middleware für die Nachrichten basierte Kommunikation über

UDP. Lidgren implementiert Verbindungs-orientierte Features, die auch aus TCP bekannt sind,

auf Basis von UDP:

• Paket Duplikat Erkennung - Erkennen und verwerfen von Paket Duplikaten

• Paketordnung - Pakete werden in der Reihenfolge ausgeliefert, in der sie versendet

wurden

• Zuverlässige Übertragung von Paketen - Verlorene Pakete werden erneut gesendet

• Nachrichten Fragmentierung - Große Nachrichten werden ggf. transparent in mehrere

Pakete aufgeteilt und versandt

Zusätzliche unterstützt Lidgren Nachrichten Verschlüsselung, NAT traversal, local server dis-

covery über einen Broadcast an ein Subnetz und die Zusammenfassung mehrerer Nachrichten

in einem Paket. Nachrichten können mit verschiedenen Graden der Verlässlichkeit verschickt

werden.

Für Nachrichten, die mit der Versandoption Unreliable verschickt werden, werden keine

Konsistenz-Anforderungen sichergestellt. UnreliableSequenced schützt gegen Duplikate und

verwirft alle Nachrichten, die älter als bereits empfangene sind. ReliableUnordered stellt sicher,

48

5 Implementierung

dass alle Nachrichten, die versendet wurden, auch ankommen. Eine Ordnung der Nachrichten

wird nicht sicher gestellt.

ReliableSequenced ähnelt UnreliableSequenced mit dem Unterschied, dass sichergestellt wird,

dass immer wenigstens eine Nachricht empfangen wird. ReliableOrdered stellt sicher, dass alle

Nachrichten in genau der Reihenfolge empfangen werden, in der sie versendet wurden.

Während die Features viele der gestellten Anforderungen erfüllen, ist Lidgren nur für C#

verfügbar (erfüllt A 13 nicht). Unschön ist, dass Nachrichten per polling abgeholt werden

müssen, was unnötig Rechenzeit verbraucht (eine Event basierte Lösung wäre besser).

RakNet

RakNet ist eine in C++ geschriebene Netzwerk-Middleware speziell für Multiplayer Spiele,

die unter anderem in Unity verwendet wird. Ähnlich zu Lidgren basiert RakNet auf UDP und

implementiert verschiedene Stufen für die Verlässlichkeit und die Ordnung von Nachrichten.

Wie in Lidgren werden eingegangene Nachrichten durch polling abgeholt (siehe Listing ??).RakNet ist nur für C++ und C# verfügbar und erfüllt damit Anforderung A 13 nicht.

Photon

Photon ist eine kommerzielle Gesamtlösung für Cross-Plattform Multiplayer Spiele. Die Midd-

leware skaliert von klassischen bis zu Massive Multiplayer Online Spielen. Die verschiedenen

angebotenen Lösungen reichen vom hosten eigener Server bis zum hosten in der Cloud des

Unternehmens. Photon unterstützt reliable UDP (auf Basis von ENet), TCP, Web Sockets und

HTTP.

Von Haus aus unterstützt Photon primitive Datentypen und ausgewählte Collections (Arrays,

generische Dictionaries und Hashtables5). Für den Versand von eigenen Datentypen müssen

diese registriert werden (siehe Listing 5.7). Bei der Registrierung müssen Delegates für die

Serialisierung des Typs in ein Byte Array und zurück angegeben werden.

1 PhotonPeer.RegisterType(Type customType, byte code, SerializeMethod serializeMethod, DeserializeMethodconstructor)

Listing 5.7: Registrierung eigener Datentypen in Photon.

Photon erfüllt viele der gestellten Anforderungen, ist aber nicht für Java und Python verfüg-

bar (erfüllt A:MultilangSerialisation nicht) und nur über ein monatliches Abo-Modell erhältlich

6.

5

https://doc.photonengine.com/en/realtime/current/reference/serialization-in-photon

6

https://www.photonengine.com/en-US/OnPremise/Pricing

49

5 Implementierung

5.2 Future Work

In Zukunft soll untersucht werden, ob sich die Performance der Middleware verbessern lässt,

indem die unterliegende Serialisierungslösung ausgetauscht wird. Es reicht im IOC Contai-

ner, eine neue Implementierung von IMessageSerialization für die gewünschte Lösung zu

registrieren (siehe Abbildung .3). Momentan ist Protobuf 2 in Verwendung. Es gibt aber viel

versprechende Alternativen:

Protobuf 3Mit der Version 3 der Protocol Buer von Google kommt eine ozielle Implementation für

C#. Für Protobuf 2 wird in der Implementierung aktuell protobuf-net verwendet. Protobuf 3

führt viele Verbesserungen für das Schreiben von Proto Dateien (bspw. bessere Default-Werte)

ein und bietet neue vordenierte Datentypen (wie Datumsangaben). Außerdem können Proto-

buf Nachrichten nun in JSON transformiert werden7.

Cap’n Proto (capnproto)Protobuf benötigt einen Encodierungs- und Decodierungsschritt um die Nachrichten von

Objekten (in memory representation) in Byte-Arrays (wire format/data interchange format)

und wieder zurück zu transformieren. In Cap’n Proto entfällt dieser Schritt, weil die Repre-

sentation im Speicher und das Wire Format identisch sind. D.h. Nachrichten können ohne

Encodierung verschickt und ohne Decodierung empfangen werden.

Integers mit fester Länge, nicht initialisierte optionale Felder und Padding verbrauchen Platz

auf der Leitung. Jedoch sind alle diese extra Bits Nullen, die mit einer Cap’n Proto spezischen

Kompression eliminiert werden können.

Neue Felder werden am Ende der Nachricht eingefügt, sodass die Nachrichten Abwärtskompa-

tibel sind. Ein Äquivalent zu "required"Feldern in protobuf, also Felder die gesetzt sein müssen,

gibt es nicht. Die Entwickler beschreiben die Verwendung von required Feldern als Fehler,

der beim Entfernen von required Feldern zu unerwarteten Problemen führt. Nachrichten Bus

Systeme (deren Aufgabe das verteilen von Nachrichten ist) die nicht mit den geänderten Nach-

richten Denitionen versorgt wurden, stürzen beim Versuch, die Nachrichten zu parsen, ab,

weil das required Feld fehlt8.

FlatBuers (FlatBuers)

7

https://developers.google.com/protocol-buers/docs/reference/csharp/class/google/protobuf/json-formatter

8

https://capnproto.org/faq.html

50

5 Implementierung

FlatBuers ist eine von Google speziell für Spiele und andere Performance kritische An-

wendungen entwickelte Serialisierungs Lösung. Flatbuers repräsentiert hierarchische Daten-

strukturen in einer achen Byte Datenstruktur. Die Inhalte können direkt ohne Parsen oder

Entpacken gelesen werden. Außerdem wird gleichzeitig das Hinzufügen und Entfernen von

Feldern weiter unterstützt (siehe FlatBuersInternals).

Das Format ist auf die Minimierung von Speicher Operationen ausgelegt. Um auf die Daten

zuzugreifen, werden keine weiteren Speicher Allokationen (außer dem Buer selbst) benötigt

(in C++). Der Zugri auf die Felder ist nahezu so schnell wie der Zugri auf ein Struct (für

Performance siehe Tabelle 5.2). Wie protobuf und Cap’n Proto unterstützt auch FlatBuers

optionale Felder. Zusätzlich bietet FlatBuers einen ezienten JSON Parser.

FlatBuers (binary) Protocol Buers LITE Rapid JSON FlatBuers (JSON) pugixml Raw structs

Decode + Traverse + Dealloc (1 million times, seconds) 0.08 302 583 105 196 0.02

Decode / Traverse / Dealloc (breakdown) 0 / 0.08 / 0 220 / 0.15 / 81 294 / 0.9 / 287 70 / 0.08 / 35 41 / 3.9 / 150 0 / 0.02 / 0

Encode (1 million times, seconds) 3.2 185 650 169 273 0.15

Wire format size (normal / zlib, bytes) 344 / 220 228 / 174 1475 / 322 1029 / 298 1137 / 341 312 / 187

Memory needed to store decoded wire (bytes / blocks) 0 / 0 760 / 20 65689 / 4 328 / 1 34194 / 3 0 / 0

Transient memory allocated during decode (KB) 0 1 131 4 34 0

Generated source code size (KB) 4 61 0 4 0 0

Field access in handwritten traversal code typed accessors typed accessors manual error checking typed accessors manual error checking typed but no safety

Library source code (KB) 15 some subset of 3800 87 43 327 0

Tabelle 5.2: FlatBuers Benchmark Quelle: https://google.github.io/atbuers/atbuers_benchmarks.html

BSON (Binary JSON bson)BSON ist ein von MongoDB entwickeltes Format zur Speicherung und Netzwerk Versand

von Daten. BSON dient zur binär encodierten Repräsentation von JSON ähnlichen Strukturen

und unterstützt die gesamte JSON Spezikation und erweitert diese um zusätzliche Datentypen.

Die C# Library von BSON9

benötigt keine Annotationen oder sonstige Anpassungen an den

versendeten Datentypen. Auch hat sich BSON als sehr robust gegenüber Vererbungsstrukturen

und Interfaces herausgestellt. Auch wenn BSON in Tests langsamer als Protobuf ist (siehe

Tabelle 5.3), können diese Vorteile die Nachteile, je nach Anwendungsfall, aufheben.

5.3 Zusammenfassung

Die Netzwerk-Middleware Implementierung erlaubt eine objektorientierte, typsichere und

eziente Nachrichten basierte Kommunikation über das Netzwerk. Für den Versand und den

Empfang von Nachrichten muss sichergestellt werden, dass auf allen Instanzen alle Nachrich-

ten mit den gleichen IDs registriert werden. Diese Registrierung kann per Code oder über

ein CSV-File erfolgen. Es wurde gezeigt, dass Protobuf eine der ezientesten verfügbaren

9

https://docs.mongodb.com/ecosystem/drivers/csharp/

51

5 Implementierung

Serialisierungslösungen ist und das vorhandene verbreitete Netzwerk Middlewares nicht die

Anforderungen des Anwendungsfalls der Master-Arbeit erfüllen.

52

6 Untersuchung

Die Evaluierung der Koniktauösung ist durch eine Benutzer Befragung erfolgt. Die Haupt-

Fragestellung ist, wie gut die kollaborative Zusammenarbeit funktioniert. Im besten Fall

nehmen die Teilnehmer die Synchronisation und Koniktauösung nicht wahr (A 3, A 4, A6, A 7 und A 9) und wird damit nicht in seiner Arbeit gestört. Im schlimmsten Fall macht

die Synchronisation und Koniktauösung die Arbeit unmöglich. Die Umfrage besitzt mit 11

Teilnehmern keine statistische Relevanz. Das genaue Evaluations-Szenario und die Ergebnisse

der Umfrage werden in Abschnitt 6.1 besprochen.

Die Evaluierung der Netwerk-Middleware erfolgte durch Performance Messungen der Im-

plementierung und dem Datendurchsatz im Netzwerk. Die Fragestellungen waren, wie viele

gleichzeitig aktive Netzwerk Middleware Instanzen praktikabel sind, welchen Daten Durchsatz

diese theoretisch erbringen können und wie der echte Daten Durchsatz in einem 1GB Ethernet

ist. Die Messergebnisse und Messmethoden werden in Abschnitt 6.2 vorgestellt.

6.1 Konfliktauflösung Evaluation

Es standen zwei Computer mit jeweils einer LEAP Motion zur Verfügung, die über einen

1GB Ethernet verbunden waren. Die Ausgabe erfolgte jeweils auf einem Monitor. Im Kontext

der in Abschnitt 1.2 vorgestellten Anwendung wurde die Aufgabe gestellt kollaborativ zwei

vorgegebene Konstrukte zu bauen (siehe Abbildungen 6.1b und 6.1c). Die Teilnehmer bauten

jeweils zu zweit die gegebenen Konstrukte zusammen und nahmen danach an einer Befragung

teil.

Die benötigten Bauteile werden aus einer Vorrats-Zone gezogen, die sich über der Arbeits-

äche bendet. Bendet sich kein Block mehr in der Vorrats-Zone wird ein neuer instantiiert.

Es werden maximal nur so viele Bauteile instantiiert, wie für das aktuelle Konstrukt benötigt

werden (siehe Abbildung 6.1a).

53

6 Untersuchung

(a) Szenario Übersicht. (b) Szenario 1 und 2. (c) Szenario 3 und 4.

Abbildung 6.1: Übersicht der Szenarien für die Evaluierung (6.1b und 6.1c) und deren grundlegender

Aufbau (6.1a).

Alle Bauteile sind schwerelos und werden durch die Magnetkräfte und die Kraft-Einwirkung

der Benutzer beschleunigt. Alle Bauteile haben einen hohen Luftwiderstand, der die Positio-

nierung im Raum erleichtert. Die Benutzer können damit Bauteile im freien Raum platzieren,

ohne das diese weg schweben. Für das zusammen setzen des Konstrukts ist ein bestimmter

Arbeitsbereich über der Arbeitsplatte vorgesehen. Verlassen Bauteile diesen Bereich, werden

diese durch Krafteinwirkung wieder in den Arbeitsbereich verschoben. Damit können keine

Bauteile verloren gehen.

Die genauen Ergebnisse der Umfrage können im Anhang eingesehen werden. An der Umfra-

ge nahmen 11 Benutzer teil. Damit sind die Ergebnisse nicht statistisch relevant. Die Erfahrung

der Teilnehmer mit Augmented Reality Anwendungen war relativ gleichmäßig verteilt. Die

Benutzung des Systems wurde durchweg als intuitiv und einfach wahrgenommen. Die Unter-

stützung einer technisch versierten Person bei der Verwendung der Anwendung empfanden

die meisten Benutzer als nicht notwendig.

Diese Ergebnisse deuten darauf hin, dass die Benutzer von der Koniktauösung und Synchro-

nisation nicht behindert wurden oder diese nicht wahrgenommen haben. Die Anwendung

hat zum Ziel, die Reaktionen der Bauteile auf Kräfte möglichst realitätsnah nachzubilden (A7). Die Bauteile verhielten sich bei der Interaktion anscheinend gemäß der Erwartungen der

Benutzer.

Probleme mit der Koniktauösung und Synchronisation hätten zu unerwartetem Verhalten

von Bauteilen und virtuellen Händen geführt. Bspw. hätte es die Benutzer vermutlich verwirrt,

wenn ein Bauteil plötzlich auf eine vorherige Position zurückgesetzt worden wäre.

54

6 Untersuchung

6.2 Netzwerk Middleware Evaluation

Abschnitt 6.2.1 beschäftigt sich mit dem theoretischen Datendurchsatz, den die Middleware

leisten kann, wenn von Netzwerk-Faktoren abstrahiert wird. Die Ergebnisse stellen daher

ein theoretisches Maximum dar, welches unter realen Netzwerk Bedingungen nicht erreicht

werden kann.

Die Untersuchung konzentriert sich auf die Ezienz der Implementierung. Es wird außerdem

untersucht, wie viele Netzwerk-Middleware Instanzen gleichzeitig, unter Volllast, auf einem

System aktiv sein können, bis Threading Faktoren den Durchsatz zu inkonsistent machen.

Mehrere Instanzen der Middleware sind dann wünschenswert, wenn mehrere Nachbarsysteme

(tendenziell mit eigenen Netzwerk-Nachrichten und Semantik) angebunden werden sollen.

Für jedes Nachbarsystem kann ein eigener Adapter mit eigener Netzwerk-Middleware Instanz

benutzt werden.

In Abschnitt 6.2.2 wird der Daten-Durchsatz der Middleware unter echten Netzwerkbedin-

gungen in einem 1GB Ethernet untersucht. In beiden Fällen wird ebenfalls untersucht, ob der

gemessene Durchsatz für die Übertragung von Meshes der Echtzeit Rekonstruktion (siehe

Tabelle 6.2 und A 12) ausreicht.

6.2.1 Netzwerk Middleware - Theoretischer Daten-Durchsatz

Komponente Beschreibung

CPU Intel Core i5-2500K 4 Cores

RAM 16 GB DDR3 SDRAM

GPU Zotac GeForce GTX 470

OS Microsoft Windows 10 Education (x64)

Tabelle 6.1: Spezikationen des Computers auf denen die Performance Tests ausgeführt wurden.

Der theoretische Datendurchsatz der Middleware wurde durch, über localhost verbunde-

ne, Middleware Instanzen getestet, die sich gegenseitig so schnell wie möglich Nachrichten

steigender Größe zuschicken (siehe Listing 1). Damit wird eine volle Auslastung aller Netzwerk-

Middleware Instanzen siumuliert. Bei zwei Middleware Instanzen beträgt der Durchsatz, bei

steigender Nachrichtengröße (bis zu 10 MB pro Nachricht), konstant ca 154 MB pro Sekunde.

Das theoretische Limit einer 1 GBit Ethernet Verbindung liegt bei 125 MB pro Sekunde.

55

6 Untersuchung

1

10

100

1000

10000

104857 2104857 4104857 6104857 8104857 10104857

Messagesize [bytes]

Number of received messages per second

MB transfered per Second

Abbildung 6.2: Daten Durchsatz bei zwei Netzwerk

Middleware Instanzen.

0

20

40

60

80

100

120

140

160

180

0 2 4 6 8 10 12 14 16 18 20

Number of Middleware Instances

Average sent messages

Average MB transferred per second

Abbildung 6.3: Durchschnittlicher Daten Durchsatz

einer Netzwerk-Middleware Instanz in Abhängig-

keit zur Gesamt-Anzahl der ausgeführten Netwerk-


Rekonstruktionsmethode MB pro Sekunde

Organized Fast Mesh HQ 1398

Organized Fast Mesh LQ 67,38

Greedy Projection HQ 205

Greedy Projection LQ 54,9

Tabelle 6.2: Durchschnittliche Datenmengen die von den verschiedenen Mesh-Rekonstruktionsmethoden

[Petersen] erzeugt werden. Es wird von 30 gesendeten Meshes pro Sekunde ausgegangen.

Die Anzahl der Netzwerk-Middleware Instanzen skaliert auf dem Testsystem (siehe Tabelle

6.1) vorhersehbar bis zu 8 Instanzen (siehe Abbildung 6.3). Darüber hinaus wird der Daten-

Durchsatz durch Threading Eekte schwer vorhersehbar (siehe Abbildungen .6, .7, .8, .9, .10,

.11, .12, .13 und .14 für die einzelnen Messergebnisse). Wenn nicht alle Netzwerk-Middleware

Instanzen dauerhaft unter Volllast laufen, können aber vermutlich mehr verwendet werden.

Übertragung von Meshes

Unter der Annahme, dass zur Rekonstruktion die Organized Fast Mesh LQ Rekonstrukti-

onsmethode verwendet wird, kann von einer durchschnittlichen Framegröße von 2300 KB

ausgegangen werden (Petersen). Nimmt man auch an, dass das System 30 Frames pro Sekunde

liefert kommt man auf eine Datenmenge von 67,38 MB pro Sekunde.

Mit einer durchschnittlichen theoretisch möglichen Übertragungsrate von 154 MB pro Sekunde,

sollte, selbst wenn der praktische Durchsatz deutlich geringer ausfällt, eine Übertragung der

Daten mit der Netzwerk-Middleware möglich sein. Die Greedy Projection LQ Rekonstrukti-

onsmethode benötigt unter gleichen Bedingungen 54,9 MB pro Sekunde und wäre damit auch

56

6 Untersuchung

theoretisch nutzbar. Das theoretische Limit einer 1 GBit Ethernet Verbindung liegt bei 125

MB pro Sekunde. Damit könnten die Meshes theoretisch an maximal zwei Clients verschickt

werden.

Greedy Projection HQ (205 MB pro Sekunde) und Organized Fast Mesh HQ (1,398 GB pro

Sekunde) können mit der Netzwerk-Middleware nicht in der geforderten Zeit übertragen

werden.

6.2.2 Netzwerk Middleware - Daten-Durchsatz im Netzwerk

Die Untersuchung der Middleware unter echten Netzwerk Bedingungen erfolgt über eine

Client und eine Server Anwendung, die über ein 1GB Ethernet verbunden sind. Es werden

Nachrichten ansteigender Größe von bis zu 65000 Bytes verschickt (das theoretische Limit

eines UDP Packets ist 65507 bytes). Dabei werden verschiedene Kongurationen des Clients

untersucht:

• TCP - Nachrichten steigender Größe werden so schnell wie möglich (in einem eigenen

Thread) über TCP an den Server geschickt ohne das auf Anwendungsebene auf eine

Bestätigung des Empfangs gewartet wird.

• TCP Synchron Blockierend - Nachrichten steigender Größe werden so schnell wie

möglich (in einem eigenen Thread) über TCP an den Server geschickt. Der Server schickt

eine Nachricht gleicher Größe zurück. Der Client wartet auf den Empfang der Nachricht,

bevor die nächste verschickt wird.

• TCP Synchron ACK - Nachrichten steigender Größe werden so schnell wie möglich

(in einem eigenen Thread) über TCP an den Server geschickt. Der Server schickt eine

ACK-Nachricht zurück. Der Client wartet auf den Empfang der Nachricht, bevor die

nächste verschickt wird.

• UDP - Nachrichten steigender Größe werden so schnell wie möglich (in einem eigenen

Thread) über UDP an den Server geschickt.

Der Datendurchsatz in der TCP Konguration bleibt mit steigender Nachrichtengröße kon-

stant um 110 MB pro Sekunde. Das wäre schnell genug, um Meshes mit der Organized Fast

Mesh LQ Rekonstruktionsmethode zu streamen (siehe Tabelle 6.2).

Actions und WorldStates bestehen im Anwendungsfall der Master-Arbeit meist nur aus

wenigen dreidimensionalen Vektoren und GUIDs. Ein Vektor besteht dabei aus 3 oats, die

57

6 Untersuchung

0,1

1

10

100

1000

10000

100000

1000000

0 10000 20000 30000 40000 50000 60000 70000

Messagesize [bytes]



Abbildung 6.4: TCP - Nachrichten steigender Größe

werden so schnell wie möglich (in einem eigenen

Thread) über TCP an den Server geschickt ohne

das auf Anwendungsebene auf eine Bestätigung

des Empfangs gewartet wird.

0,1

1

10

100

1000

10000

100000

1000000

0 10000 20000 30000 40000 50000 60000 70000

Messagesize [bytes]



Abbildung 6.5: TCP Synchron Blockierend - Nach-

richten steigender Größe werden so schnell wie

möglich (in einem eigenen Thread) über TCP an

den Server geschickt. Der Server schickt eine Nach-

richt gleicher Größe zurück. Der Client wartet auf

den Empfang der Nachricht bevor die nächste ver-

schickt wird.

insgesamt 12 Bytes benötigen. Quaternionen, die für Rotationen benutzt werden, bestehen aus

4 oats (insgesamt also 16 Bytes). Eine GUID benötigt 128 Bytes.

Bspw. benötigt das Update eines Bauteils die ID des Bauteils (GUID), Position (Vector3), Rota-

tion (Quaternion) und Geschwindigkeit (Vector3). Insgesamt also 128 Bytes + 12 Bytes + 16

Bytes + 12 Bytes = 168 Bytes an Nutzdaten. Die Nachricht selbst benötigt einen int32 Identier

(4 Bytes). Der Overhead durch Protobuf ist im Normalfall sehr gering1.

Insgesamt kann also von einer Nachrichtengröße von mindestens 172 Bytes für ein Bauteil

Status Update ausgegangen werden. Der Daten Durchsatz in der TCP Konguration beträgt im

Durchschnitt um 110 MB pro Sekunde. Geht man konservativ von einer Nachrichtengröße von

200 Bytes aus, können 1048576 * 110 / 200 Bytes = 576716,8 Updates für Bauteile übertragen

werden. Wird davon ausgegangen, dass ein Bauteil 30 Updates pro Sekunde erhalten soll, ergibt

sich eine theoretische maximale Anzahl von ca 19223 Bauteilen. Bei dieser Anzahl an Bauteilen

wird vermutlich das Rendering zu einem größeren Problem. In den Szenarien, die in Abschnitt

6.1 beschrieben wurden, waren maximal 8 Bauteile gleichzeitig aktiv.

Die blockierenden TCP Kongurationen sind für den Anwendungsfall des autoritativen

Servers interessant. Aktionen müssen übertragen und bestätigt werden, außerdem müssen

WorldStates von Client zu Server übertragen werden. Die Konguration TCP Synchron Blo-

ckierend geht von relativ komplexen Anfragen und Antworten von Server und Client aus.

1

https://developers.google.com/protocol-buers/docs/encoding

58

6 Untersuchung

Der Datendurchsatz in den blockierenden Kongurationen (siehe Abbildungen 6.5 und 6.6) ist

deutlich geringer als in TCP. Die meiste Zeit geht hier vermutlich durch das Warten auf die

Antwort verloren.

0,1

1

10

100

1000

10000

100000

1000000

0 10000 20000 30000 40000 50000 60000 70000

Messagesize [bytes]



Abbildung 6.6: TCP Synchron ACK - Nachrichten

steigender Größe werden so schnell wie möglich

(in einem eigenen Thread) über TCP an den Server

geschickt. Der Server schickt eine ACK-Nachricht

zurück. Der Client wartet auf den Empfang der

Nachricht bevor die nächste verschickt wird.

0,1

1

10

100

1000

10000

100000

0 10000 20000 30000 40000 50000 60000 70000

Messagesize [bytes]



Abbildung 6.7: UDP - Nachrichten steigender Grö-

ße werden so schnell wie möglich (in einem eige-

nen Thread) über UDP an den Server geschickt.

Benutzer Aktionen sind tendenziell größer als Bauteil Updates. Bspw. benötigt die Bewegung

eines Handknochens folgende Informationen: Anfangsposition (Vector3, kann zur Optimie-

rung deaktiviert werden), Zielposition (Vector3) und Zielrotation (Quaternion). D.h. ca 40 Byte

pro Handknochen. Das Handskelett der LEAP hat 4 Knochen pro Finger2. Damit müssen 20

Fingerknochen Updates pro Handbewegung übertragen werden. Das sind 800 Bytes pro Hand

Update.

Bei einer Übertragungsrate von 10 MB pro Sekunde können also theoretisch maximal ca 13107

Handbewegungen pro Sekunde übertragen werden. Im Anwendungsfall der Master-Arbeit

werden 60 Handbewegungen pro Sekunde übertragen.

Beim Versand von UDP Nachrichten über das Netzwerk kommt es zu unerwarteten Eekten

(siehe Abbildung 6.7). Für die schnelle Übertragung von UDP Nachrichten werden anscheinend

mehr Kontroll-Mechanismen in der Middleware benötigt. Die Verwendung von UDP könnte

sich aber in schlechten Netzwerk-Bedingungen (Internet) als vorteilhaft herausstellen.

2

https://developer.leapmotion.com/documentation/cpp/api/Leap.Bone.html

59

6 Untersuchung

Die Netzwerk Bedingungen in den Tests waren optimal. Die Nachteile der Fehlerkorrektur-

mechanismen von TCP für die Latenz hatten damit keinen Einuss. In schlechteren Netzwerk

Bedingungen (Internet) könnte sich das ändern.

6.2.3 Zusammenfassung

Die Koniktauösung wurde durch ein kollaboratives Konstruktionsszenario evaluiert. Jeweils

zwei Benutzer haben dabei kollaborativ verschiedene Konstrukte gebaut. Die Synchronisation

und Koniktauösung scheint die Teilnehmer nicht bei der Arbeit behindert zu haben.

Es können bis zu 8 Middleware-Instanzen (die unter Volllast stehen) auf einem vier Kern

System betrieben werden, bevor der Daten Durchsatz durch Thread-Scheduling Probleme zu

weit einbricht. Es wurde der theoretische und tatsächliche Datendurchsatz der Middleware

untersucht. Es wurde gezeigt, dass der Datendurchsatz für den Anwendungsfall der Master-

Arbeit und deutlich komplexere Szenarien ausreichend ist. Außerdem reicht der Durchsatz für

die Übertragung von Meshes der Echtzeit Rekonstruktion aus.

60

7 Fazit

In dieser Master-Arbeit wurde eine generische Lösung für die Sicherung der globalen Konsis-

tenz in verteilten kollaborativen Konstruktions MR-Anwendungen vorgestellt. Die Lösung

wurde im Kontext einer kollaborativen verteilten Konstruktionsanwendung evaluiert, in der

mehrere Benutzer ein Konstrukt aus virtuellen Bauteilen zusammen setzen. Die Bauteile verhal-

ten sich physikalisch korrekt und können von den Benutzern direkt angefasst und verschoben

werden. Die Synchronisation und Koniktauösung soll dabei für die Benutzer möglichst un-

sichtbar bleiben. Eine (statistisch nicht signikante) Benutzer Befragung hat ergeben, dass die

Synchronisation und Koniktauösung die Benutzer nicht in der Zusammenarbeit behindert

hat.

Die Anwendung löst Konikte durch gleichzeitige Manipulation eines Bauteils, Konikte mit

realen Objekt Referenzen und Konikte durch Latenzen auf. Die verteilten Physik-Simulationen

auf den Instanzen werden synchronisiert, sobald die Inkonsistenzen die Toleranzen überschrei-

ten, die vom Anwendungsfall festgelegt werden.

Für die Verteilung wurde eine Netzwerk Middleware vorgestellt, die eine objektorientierte,

typsichere und latenzarme nachrichtenbasierte Kommunikation über das Netzwerk ermöglicht.

Die Netzwerk-Middleware ermöglicht durch eine hohe Portierbarkeit die Kommunikation

zwischen verschiedenen Plattformen und Programmiersprachen. In der Evaluierung wurde

gezeigt, dass der Daten Durchsatz der Netzwerk-Middleware für den Anwendungsfall der

Master-Arbeit und deutlich komplexere Szenarien ausreichend ist.

61

Appendices

62

Durchschnitt: 2.91

Durchschnitt: 2.55

Welchem sozialen Geschlecht ordnen Sie sich am ehesten ein?11 von 11 Personen haben diese Frage beantwortet

Wie viel Erfahrung haben Sie mit Augmented/Virtual Reality?11 von 11 Personen haben diese Frage beantwortet

Keine Erfahrung Sehr viel Erfahrung

Wie viel Erfahrung haben Sie mit 3DProgrammen, die zum Erstellen und Betrachten von 3DModellen genutzt werden?11 von 11 Personen haben diese Frage beantwortet

Keine Erfahrung Sehr viel Erfahrung

6 / 55%1

3 / 27%2

1 / 9%3

1 / 9%4

0 / 0%5

3 / 27%1

3 / 27%4

2 / 18%2

2 / 18%5

1 / 9%3

4 / 36%2

3 / 27%1

2 / 18%5

1 / 9%3

1 / 9%4

Maskulin

Feminin

Sowohl Feminin als Maskulin

Weder Feminin noch Maskulin

Andere

1 2 3 4 5

1 2 3 4 5

Durchschnitt: 2.82

Durchschnitt: 1.27

Durchschnitt: 3.80

Eine regelmäßige Nutzung des Systems ist gewünscht.11 von 11 Personen haben diese Frage beantwortet

Stimme ich nicht zu Stimme ich zu

Das System ist unnötig komplex.11 von 11 Personen haben diese Frage beantwortet


Das System ist leicht zu nutzen.10 von 11 Personen haben diese Frage beantwortet


Zur Nutzung des Systems wird die Unterstützung einer technisch versierten Person benötigt.

5 / 45%3

3 / 27%4

2 / 18%1

1 / 9%2

8 / 73%1

3 / 27%2

5 / 50%4

2 / 20%3

2 / 20%5

1 / 10%2

1 2 3 4 5

1 2 3 4 5

1 2 3 4 5

Durchschnitt: 1.64

Durchschnitt: 4.36

Durchschnitt: 2.64

Durchschnitt: 3.73

11 von 11 Personen haben diese Frage beantwortet


Die meisten Nutzer werden die Bedienung des Systems sehr schnell lernen.11 von 11 Personen haben diese Frage beantwortet


Das System ist sehr mühsam zu nutzen.11 von 11 Personen haben diese Frage beantwortet


Die Nutzung des Systems fühlt sich vertraut an.11 von 11 Personen haben diese Frage beantwortet

6 / 55%1

4 / 36%2

1 / 9%4

5 / 45%4

5 / 45%5

1 / 9%3

5 / 45%2

3 / 27%4

2 / 18%3

1 / 9%1

1 2 3 4 5

1 2 3 4 5

1 2 3 4 5

1 2 3 4 5

Durchschnitt: 1.27


Um mit dem System zu Arbeiten müssen zuvor viele Dinge gelernt werden.11 von 11 Personen haben diese Frage beantwortet


5 / 45%3

4 / 36%4

2 / 18%5

8 / 73%1

3 / 27%2

1 2 3 4 5

Abbildung .1: Factory Klasse für INetworkAdapter Instanzen. Alle Abhängigkeiten werden über einen

IOC-Container (https://autofac.org/) verwaltet und können so einfach (auch dynamisch zur runtime)

ausgetauscht werden.

1 [Test]2 public void TestIncreasingMessagesPerformanceTCP()3 4 /* --- TEST CONFIG --- */5

6 int maxParallelTasks = 10;7

8 /* --- TEST CONFIG END --- */9

10 for (int i = 0; i < maxParallelTasks; i++)11 12 TestIncreasingMessagePerformanceTCPIteration(i + 1);13 14 15

16 private void TestIncreasingMessagePerformanceTCPIteration(int parallelTasks)17 18 /* --- TEST CONFIG --- */19

20 var iterations = 100;21 var maximumMessageSize = 1024 * 1024 * 10; // 10 MB maximum message size.22 var enableAssertion = false;23 var minimumNumberOfMessagesPerSecond = 0;24 var numberOfSeconds = 2;25 var mbSentPerSecond = 300;26 var checkReceivedMessages = false;27 var csvDir = Environment.GetFolderPath(Environment.SpecialFolder.Desktop);28 var csvFilePath = csvDir + "/performanceTestResultsTCP_" + iterations + "iterations_" + parallelTasks +

"Tasks" + "_CheckMessages_" + checkReceivedMessages + ".csv";29

30 /* --- TEST CONFIG END --- */31

32 var factoryLock = new object();

67

Abbildung .2: Genau wie INetworkAdapter Instan-

zen, können IAuthorativeRemote Instanzen über

eine Factory bezogen werden. IAuthorativeServer

implementiert dabei die Funktionalitäten eines au-

toritativen Servers, I AuthorativeClient die eines

Clients für diesen Server.

Abbildung .3: Um die unterliegende Serialisierungs-

lösung auszutauschen muss dem IOC Container

eine neue Implementierung des IMessageSerializa-

tion Interfaces übergeben werden.

33 var fileWriteLock = new object();34

35 var headLine = string.Format(36 "0;12",37 "CurrentMessageSizeInBytes",38 "NumberOfReceivedMessagesPerSecond",39 Environment.NewLine);40 File.WriteAllText(csvFilePath, headLine);41

42 var messageTasks = new Queue<Task>();43

44 var logger = LoggerFactory.GetConsoleLogger();45 logger.MessageLoggingThreshhold = LogLevel.None;46

47 for (var i = 0; i < iterations; i++)48 49 var i1 = i;50 messageTasks.Enqueue(51 new Task(() =>52 53 var iteration = i1;54 var currentMessageSize = (maximumMessageSize / iterations) * (iteration + 1);55 var numberOfReceivedMessages = 0;56

57 int listeningPort;58 INetworkAdapter networkAdapter1;59 INetworkAdapter networkAdapter2;60

61 lock (factoryLock)62 63 //TODO: Why isn’t the factory thread safe???64 networkAdapter1 = NetworkAdapterFactory.GetNewNetworkAdapter(logger);65 networkAdapter2 = NetworkAdapterFactory.GetNewNetworkAdapter(logger);66 listeningPort = CommonNetworkTestVariablesAndConstants.CurrentPort++;67 68

69 var testMessageID = 42;70

71 networkAdapter1.RegisterMessageType<TestByteArrayMessage>(testMessageID);72 networkAdapter2.RegisterMessageType<TestByteArrayMessage>(testMessageID);73

74 TestByteArrayMessage testMessageOfSize = null;75 networkAdapter1.SubscribeToMessagesOfType<TestByteArrayMessage>(76 (message, point, endPoint, id) =>

68

77 78 numberOfReceivedMessages++;79 if (checkReceivedMessages && !message.Equals(testMessageOfSize))80 81 Console.WriteLine("Corrupt message!");82 83 );84

85 networkAdapter1.StartAcceptingConnectionsOnTCPPort(listeningPort);86 networkAdapter2.ConnectToTCPRemote(CommonNetworkTestVariablesAndConstants.Loopback,

listeningPort);87

88 Thread.Sleep(100);89

90 numberOfReceivedMessages = 0;91

92 var resetEvent = new ManualResetEventSlim(false);93 var sendMessages = true;94 var timer = new Timer(1000 * numberOfSeconds);95

96

97 var size = currentMessageSize;98 testMessageOfSize = TestMessageFactory.GetTestMessageOfSize(size);99 var messageSenderThread = new Thread(

100 () =>101 102 var messagesThisIteration = mbSentPerSecond * numberOfSeconds *

1048576 / size;103

104 // Send messages as fast as possible.105 for (var j = 0; j < messagesThisIteration; j++)106 107 if (sendMessages)108 109 networkAdapter2.SendMessageOverTCP(110 testMessageOfSize,111 CommonNetworkTestVariablesAndConstants.Loopback,112 listeningPort);113 114 115 );116

117 timer.Elapsed += (sender, args) =>118 119 sendMessages = false;120 messageSenderThread.Abort();121 resetEvent.Set();122 ;123

124 messageSenderThread.Start();125 timer.Start();126

127 resetEvent.Wait();128

129 testMessageOfSize = null;130

131 networkAdapter1.Shutdown();132 networkAdapter2.Shutdown();133

134 networkAdapter1 = null;135 networkAdapter2 = null;136

137 var newLine = string.Format(138 "0;12",139 currentMessageSize,140 numberOfReceivedMessages / (float)numberOfSeconds,141 Environment.NewLine);142 lock (fileWriteLock)

69

143 144 File.AppendAllText(csvFilePath, newLine);145 146

147 if (enableAssertion)148 149 Assert.Greater(numberOfReceivedMessages / numberOfSeconds, 0);150 Assert.GreaterOrEqual(151 numberOfReceivedMessages / numberOfSeconds,152 minimumNumberOfMessagesPerSecond);153 154 ));155 156

157 while (messageTasks.Count > 0)158 159 var tasksThisIteration = new List<Task>();160

161 for (int i = 0; i < parallelTasks; i++)162 163 if (messageTasks.Count == 0)164 165 break;166 167 tasksThisIteration.Add(messageTasks.Dequeue());168 169

170 foreach (var task in tasksThisIteration)171 172 task.Start();173 174

175 Task.WaitAll(tasksThisIteration.ToArray());176 177

Listing 1: Netzwerk Middleware performance Test.

1 public class TestMessageFactory2 3 private static readonly Random random = new Random();4

5 public static TestMessage GetTestMessage()6 7 return new TestMessage(8 new TestDataType("I’m Batman...", 42),9 42,

10 "Joachim: They’re still running with shields down. "11 + "Khan: Of course! We are one big, happy fleet! Ah, Kirk, my old friend, do you know the Klingon

proverb that tells us revenge is a dish that is best served cold? "12 + "[pause] Khan: It is very cold in space!");13 14

15 public static TestByteArrayMessage GetTestMessageOfSize(int size)16 17 var testMessagePayload = new byte[size];18 random.NextBytes(testMessagePayload);19

20 return new TestByteArrayMessage(testMessagePayload);21 22

23 public static TestMessageResponse GetTestMessageResponse()24 25 return new TestMessageResponse(26 new TestDataType("I’m Batman...", 42),27 42,28 "Joachim: They’re still running with shields down. "

70

29 + "Khan: Of course! We are one big, happy fleet! Ah, Kirk, my old friend, do you know the Klingonproverb that tells us revenge is a dish that is best served cold? "

30 + "[pause] Khan: It is very cold in space!");31 32

Listing 2: Netzwerk Middleware performance Test Netzwerk Nachricht Generierung.

1 [ProtoContract]2 public class TestByteArrayMessage3 4 public TestByteArrayMessage()5 6 7

8 public TestByteArrayMessage(byte[] testPayload)9

10 this.TestPayload = testPayload;11 12

13 [ProtoMember(1)]14 public byte[] TestPayload get; private set; 15

16 public override bool Equals(object obj)17 18 if (ReferenceEquals(null, obj))19 20 return false;21 22

23 if (ReferenceEquals(this, obj))24 25 return true;26 27

28 if (obj.GetType() != this.GetType())29 30 return false;31 32

33 return this.Equals((TestByteArrayMessage)obj);34 35

36 public override int GetHashCode()37 38 return this.TestPayload != null ? this.TestPayload.GetHashCode() : 0;39 40

41 protected bool Equals(TestByteArrayMessage other)42 43 return this.TestPayload.SequenceEqual(other.TestPayload);44 45

Listing 3: Netzwerk Middleware performance Test Netzwerk Nachricht.

71

Abbildung .4: Das zentrale Interface der Netzwerk-Middleware. Über diese Schnittstelle können alle

Funktionen der Middleware (außer dem autoritativem Server Layer) aufgerufen werden.

72

Abbildung .5: Der autoritative Server Layer nutzt INetworkAdapter Instanzen zur Netzwerk Kommu-

nikation und implementiert darauf aufbauend Funktionalitäten für die Verwendung von Actions und

eines globalen World-States.

73

1

10

100

1000

10000

104857 2104857 4104857 6104857 8104857 10104857

Messagesize [bytes]


MB transfered per second

Abbildung .6: Daten Durchsatz bei vier Netzwerk


1

10

100

1000

10000

104857 2104857 4104857 6104857 8104857 10104857

Messagesize [bytes]


MB transferred per second

Abbildung .7: Daten Durchsatz bei sechs Netzwerk


1

10

100

1000

10000

104857 2104857 4104857 6104857 8104857 10104857

Messagesize [bytes]



Abbildung .8: Daten Durchsatz bei acht Netzwerk


1

10

100

1000

10000

104857 2104857 4104857 6104857 8104857 10104857

Messagesize [bytes]



Abbildung .9: Daten Durchsatz bei zehn Netzwerk


1

10

100

1000

10000

104857 2104857 4104857 6104857 8104857 10104857

Messagesize [bytes]



Abbildung .10: Daten Durchsatz bei zwölf Netzwerk


1

10

100

1000

10000

104857 2104857 4104857 6104857 8104857 10104857

Messagesize [bytes]



Abbildung .11: Daten Durchsatz bei vierzehn Netz-

werk Middleware Instanzen.

74

0,1

1

10

100

1000

10000

104857 2104857 4104857 6104857 8104857 10104857

Messagesize [bytes]



Abbildung .12: Daten Durchsatz bei sechzehn Netz-


0,1

1

10

100

1000

10000

104857 2104857 4104857 6104857 8104857 10104857

Messagesize [bytes]



Abbildung .13: Daten Durchsatz bei achtzehn Netz-


0,1

1

10

100

1000

10000

104857 2104857 4104857 6104857 8104857 10104857

Messagesize [bytes]



Abbildung .14: Daten Durchsatz bei zwanzig Netz-


75

Literaturverzeichnis

[AnyLand ] : Anyland on Steam. – URL http://store.steampowered.com/app/505700/

[Arvida2015 ] : Arvida - Arvida. – URL http://www.arvida.de/. – Zugrisdatum:

2015-04-28

[AutodeskAugment ] : Augment: Enterprise Augmented Reality Platform. – URL http://www.augment.com/

[ViewAR ] : Augmented Reality Architecture & Furniture Specialized Developers. – URL

http://www.viewar.com/

[bson ] : C# and .NET MongoDB Driver. – URL https://docs.mongodb.com/ecosystem/drivers/csharp/

[capnproto ] : Cap’n Proto: Introduction. – URL https://capnproto.org/

[ZeroMQ ] : Distributed Messaging - zeromq. – URL http://zeromq.org/

[ENet ] : ENet: ENet. – URL http://enet.bespin.org/

[FlatBuersInternals ] : FlatBuers: FlatBuer Internals. – URL https://google.github.io/flatbuffers/flatbuffers_internals.html

[FlatBuers ] : FlatBuers: Main Page. – URL https://google.github.io/flatbuffers/index.html

[improov ] : Improov | MiddleVR. – URL http://www.middlevr.com/improov/.

– Zugrisdatum: 2017-01-03

[JSON ] : JSON. – URL http://www.json.org/

[Lidgren ] : lidgren-network-gen3. – URL https://github.com/lidgren/lidgren-network-gen3

76

http://store.steampowered.com/app/505700/


http://www.arvida.de/

http://www.augment.com/

http://www.augment.com/

http://www.viewar.com/



https://capnproto.org/

http://zeromq.org/

http://enet.bespin.org/

https://google.github.io/flatbuffers/flatbuffers_internals.html

https://google.github.io/flatbuffers/flatbuffers_internals.html

https://google.github.io/flatbuffers/index.html

https://google.github.io/flatbuffers/index.html

http://www.middlevr.com/improov/

http://www.json.org/

https://github.com/lidgren/lidgren-network-gen3

https://github.com/lidgren/lidgren-network-gen3


[Photon ] : Multiplayer Game Development Made Easy | Photon: Multiplayer Made Simple. –

URL https://www.photonengine.com/en-US/Photon

[protobuf ] : Protobuf. – URL https://developers.google.com/protocol-buffers/. – Zugrisdatum: 2016-02-17

[protobuf-net ] Protobuf Net. . – URL https://github.com/mgravell/protobuf-net

[protobufspeed ] : Protobuf vs XML. – URL https://developers.google.com/protocol-buffers/docs/overview. – Zugrisdatum: 2016-02-17

[RabbitMQ ] : RabbitMQ - Messaging that just works. – URL https://www.rabbitmq.com/

[RakNet ] : RakNet. – URL https://github.com/OculusVR/RakNet

[SculptrVR ] : SculptrVR on Steam. – URL http://store.steampowered.com/app/418520/

[SimpleSpeedTester ] : SimpleSpeedTester. – URL https://github.com/theburningmonk/SimpleSpeedTester/tree/develop/examples

[SourceLagReduction ] : Source Multiplayer Networking - Valve Developer Com-

munity. – URL https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking. – Zugrisdatum: 2015-10-31

[Unity ] : Unity - Game Engine. – URL https://unity3d.com/de

[virtalis ] : Virtalis. – URL https://www.virtalis.com/. – Zugrisdatum: 2017-

01-03

[virtalis-visionary-render ] : Virtalis - Visionary-Render. – URL https://www.virtalis.com/visionary-render/. – Zugrisdatum: 2017-01-03

[VisualStudioCodeMetrics ] : Visual Studio - Code Metrics Values. – URL https://msdn.microsoft.com/en-us//library/bb385914.aspx

[Ben Rajeb und Leclercq 2015] Ben Rajeb, S. ; Leclercq, P.: Instruments for Collective

Design in a Professional Context: Digital Format or New Processes ? In: Eighth International

Conference on Advances in Computer-Human Interactions (2015), Nr. c, S. 72–79. ISBN

9781612083827

77

https://www.photonengine.com/en-US/Photon

https://developers.google.com/protocol-buffers/

https://developers.google.com/protocol-buffers/

https://github.com/mgravell/protobuf-net

https://github.com/mgravell/protobuf-net

https://developers.google.com/protocol-buffers/docs/overview

https://developers.google.com/protocol-buffers/docs/overview



https://github.com/OculusVR/RakNet



https://github.com/theburningmonk/SimpleSpeedTester/tree/develop/examples

https://github.com/theburningmonk/SimpleSpeedTester/tree/develop/examples

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

https://unity3d.com/de

https://www.virtalis.com/

https://www.virtalis.com/visionary-render/

https://www.virtalis.com/visionary-render/

https://msdn.microsoft.com/en-us//library/bb385914.aspx

https://msdn.microsoft.com/en-us//library/bb385914.aspx


[Benko u. a. 2012] Benko, Hrvoje ; Jota, Ricardo ; Wilson, Andrew: MirageTable: Free-

hand Interaction on a Projected Augmented Reality Tabletop. In: Proceedings of the

2012 ACM annual conference on Human Factors in Computing Systems - CHI ’12 (2012),

S. 199–208. – URL http://dl.acm.org/citation.cfm?doid=2207676.2207704. ISBN 9781450310154

[Blank 2016] Blank, Christian: Intuitive kontaktfreie Interaktion In Virtual undMixed Reality.

2016

[Bowman u. a. 2004] Bowman, Doug A. ; Kruijff, Ernst ; Laviola, Joseph J. ; Poupyrev,

Ivan: Evaluation of 3D User Interfaces. 2004. – 117–118 S. – ISBN 0201758679

[Cheng u. a. 2014] Cheng, Yuan ; He, Fazhi ; Xu, Bin ; Han, Soonhung ; Cai, Xian-

tao ; Chen, Yilin: A multi-user selective undo/redo approach for collaborative CAD

systems. In: Journal of Computational Design and Engineering 1 (2014), Nr. 2, S. 103–

115. – URL http://cadcam.or.kr/upfiles/2013-08-26-EAC-2-4.pdf%5Cnhttp://www.techno-press.com/content/fulltext/j_cde/cde1_2/cde0102004.pdf. – ISSN 22884300

[Hildebrandt und Others 1993] Hildebrandt, HELMU ;Others: Pschyrembel Medizinisches

Wörterbuch. In: Hamburg: Nikol (1993)

[Leithinger u. a. 2014] Leithinger, Daniel ; Follmer, Sean ; Olwal, Alex ; Ishii, Hiroshi:

Physical telepresence: Shape Capture and Display for Embodied, Computer-mediated Re-

mote Collaboration. In: Proceedings of the 27th annual ACM symposium on User interface

software and technology - UIST ’14 (2014), S. 461–470. – URL http://dl.acm.org/citation.cfm?id=2642918.2647377. ISBN 9781450330695

[Massie und Salisbury 1994] Massie, Thomas H. ; Salisbury, J K.: The PHANTOM Haptic

Interface : A Device for Probing Virtual Objects Threee Enabling Observations component of

our ability to "visualize ,"remember and establish cognitive models of the physical structure

of our environment stems from haptic interactions. In: ASME Winter Annual Meeting,

Symposium on Haptic Interfaces for Virtual Environment and Teleoperator Systems (1994),

S. 1–6. ISBN 0791814149

[Olwal u. a. 2014] Olwal, Alex ; Barry, Za ; Pe, Ken: T ( e ether ): Spatiall re Hand ures and

d Proprio oceptio on for Multi-Us ser 3D Modeli ng and d Anima ation. (2014), S. 90–93

[Petersen ] Petersen, Iwer: Kollaboration im virtuellen Team: Grenzen des Avatar-Realismus

bei verteilter Echtzeit-Rekonstruktion, Dissertation

78

http://dl.acm.org/citation.cfm?doid=2207676.2207704

http://dl.acm.org/citation.cfm?doid=2207676.2207704

http://cadcam.or.kr/upfiles/2013-08-26-EAC-2-4.pdf%5Cnhttp://www.techno-press.com/content/fulltext/j_cde/cde1_2/cde0102004.pdf



http://dl.acm.org/citation.cfm?id=2642918.2647377

http://dl.acm.org/citation.cfm?id=2642918.2647377


[Tesser und Schwarz 1994] Tesser, Abraham ; Schwarz, Norbert: Blackwell Handbook

of Social Psychology: Intraindividual Processes. URL https://www.amazon.com/Blackwell-Handbook-Social-Psychology-Intraindividual/dp/B007YZXCRC%3FSubscriptionId%3D0JYN1NVW651KCA56C102%26tag%3Dtechkie-20%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB007YZXCRC,

1994. – ISBN 0631210342

79

https://www.amazon.com/Blackwell-Handbook-Social-Psychology-Intraindividual/dp/B007YZXCRC%3FSubscriptionId%3D0JYN1NVW651KCA56C102%26tag%3Dtechkie-20%26linkCode%3Dxm2%26camp%3D2025%26creative%3D165953%26creativeASIN%3DB007YZXCRC



Hiermit versichere ich, dass ich die vorliegende Arbeit ohne fremde Hilfe selbständig verfasst und

nur die angegebenen Hilfsmittel benutzt habe.

Hamburg, 16. Januar 2017 Malte Eckho

konsistenz in verteilten kollaborativen konstruktions mr...

Documents