Parallelisierung von Ray Tracing Berechnungen in einem heterogenen Netzwerk. Studienarbeit

Transkript

1 Parallelisierung von Ray Tracing Berechnungen in einem heterogenen Netzwerk Studienarbeit Vorgelegt von Robert Bärz Institut für Computervisualistik Arbeitsgruppe Computergraphik Betreuer: Prüfer: Dipl.-Inform. M. Geimer Prof. Dr.-Ing. Stefan Müller Oktober 2004

2 ZUSAMMENFASSUNG. Die vorliegende Studienarbeit baut auf dem Ray Tracing System Dream auf. Mit dem Dream Ray Tracer ist es schon auf Einzelrechnern möglich, interaktive Frameraten zu erzielen. Um diese Frameraten auch bei komplexeren Berechnungen konstant zu halten, erweitert diese Studienarbeit das bestehende System um die Fähigkeit zur verteilten Berechnung von Ray Tracing Daten. Insbesondere ist es möglich, die Netzwerkfähigkeit auch in heterogenen Netzwerken mit unterschiedlichen Betriebsystemen und Prozessortypen zu verwenden. i

3 Inhaltsverzeichnis 1 Einleitung Ausgangspunkt Zielsetzung Schwerpunkte Strukturierung Architektur Externe Abhängigkeiten Komponenten des Systems Netzwerk Master Slave Softwaremodell Überblick Konzepte im Master Netzwerk Die IndexSource Schnittstelle Das fertige Bild Synchronisierung der Threads Konzepte im Slave Zentral: Der SlaveThread Synchronisierung mittels IndexBuffer Berechnung der Farbwerte Verbindungsabbruch Netzwerkkommunikation Aufbau des ServerThreads Netzwerkprotokoll Implementierung Programmierkonventionen Klassenbeschreibungen Tools Network ii

4 4.2.3 Master Slave Das Netzwerk Protokoll Bedienung Starten des Masters Starten eines Slaves Das Wrapper Skript Dream Voraussetzungen Beschreibung Netzwerk Beschreibungsdatei Eingabeschnittstelle des Masters Benutzerschnittstelle des slaves Performance Testumgebung Testergebnisse Datendurchsatz Load Balancing Leistungssteigerung bei mehreren Rechnern Leistungssteigerung in Abhängigkeit zur Szenenkomplexität Fazit Ausblick iii

5 Abbildungsverzeichnis 2.1 Verteiltes System im Netzwerk Komponentendiagramm (Master) Komponentendiagramm (Slave) Klassenübersicht (Master) Detailiertes Klassendiagramm (Master) Klassenübersicht (Slave) Detailiertes Klassendiagramm (Slave) Ablauf des ServerThreads Netzwerkprotokoll als Statechart IndexSource IndexBuffer NetIdxBuffer Socket TcpStream Protocol ServerThread SessionPool SessionThread SlaveThread TraceThreadPool SimpleTraceThread msginfo msghelo msgrequest msgcamera msgtile msgresult msgwait msgbye Netzwerkdurchsatz NetIO Netzwerkdurchsatz Dream I/O iv

6 6.3 Load Balancing Leistungsteigerung mit mehreren Rechnern Abhängigkeit von der Szenenkomplexität v

7 1 Einleitung 1.1 Ausgangspunkt Im September 2003 veröffentlichte das Institut für Computervisualistik einen Interaktiven Ray Tracer [GM03], mit dem es möglich ist, bei mittelgroßen Szenen bereits mit einem Rechner interaktive Frameraten zu erzielen. Um dieses System auch für komplexere Szenen oder erweiterte Effekte interaktiv zu halten, erweitert diese Studienarbeit das Framework um die Möglichkeit zur verteilten Berechnung der Ray Tracing Daten. Die Erweiterung des Systems kann sich auf die Verteilung der Ray Tracing Aufträge im Netzwerk konzentrieren, da es für die Ray Tracing Berechungen das vorhandene System verwendet. 1.2 Zielsetzung Das Ziel dieser Studienarbeit ist es, das optimierte Ray Tracing System Dream so zu erweitern, dass die Ray Tracing Berechnungen in einem Pool von Rechnern verteilt werden können. Um eine gute Skalierbarkeit des Systems zu gewährleisten, ist auf eine effiziente Datenübertragung zu achten. Außerdem soll das System in einem heterogenen Umfeld (x86/linux und PowerPC/Mac OS X) einsetzbar sein. 1.3 Schwerpunkte Schwerpunkte der Arbeit sind: 1. Einarbeitung in die verschiedenen Möglichkeiten zur Verteilung von Ray Tracing Berechnungen (demand/data driven, hybrid) und in das Ray Tracing System Dream. 2. Entwurf einer erweiterten Systemarchitektur. 3. Implementierung der spezifizierten Erweiterungen in der Sprache C++ und Integration des bestehenden Renderingsystemes. 1

8 4. Dokumentation des Gesamtsystemes sowie der erzielten Ergebnisse. 1.4 Strukturierung Die vorliegende Studienarbeit ist in folgende Kapitel unterteilt: Systemarchitektur stellt die Architektur des Softwaresystems vor. Softwaremodell erläutert anhand von UML Diagrammen die Umsetzung der Systemarchitektur. Implementierung geht näher auf Details in der Implementierung ein. Bedienung erklärt die Handhabung des Softwaresystems. Performance analysiert die Leistung des Softwaresystems. Fazit ist eine Zusammenfassung und Bewertung der Studienarbeit. 2

9 2 Architektur In diesem Kapitel wird die modulare Struktur des Systems aus der Sicht von Außen beschrieben. Um Ray Tracing Berechnungen parallel auf mehreren Rechnern ausführen zu können, muss auf jedem beteiligten Rechner ein entsprechendes Programm zum raytracen ausgeführt werden (Abbildung 2.1). Wobei genau ein Rechner für die Darstellung der berechneten Bilder zuständig ist. Bei den übrigen Rechnern spricht man von unterstützenden Rechnern. Das Programm zur Darstellung und Koordinierung heißt im Folgenden Master. Das Gegenstück, das Programm zur Unterstützung bei den Berechnungen, wird Slave genannt. Abbildung 2.1: Verteiltes System im Netzwerk Zur Umsetzung dieser Zweiteilung des Systems in Master und Slave, gibt es verschiedene Methoden: Master und Slave bilden ein Programm, das per Kommandozeilenparameter in den 3

10 Master- oder Slave-Modus versetzt werden kann. Master und Slave sind getrennt kompilierbare Programme mit jeweils einer eigenen ausführbaren Datei. Der Vorteil der ersten Methode ist eine geringere Redundanz im Quelltext, da beide Programme aus dem selben Quelltext entstehen. Die zweite Methode, die hier umgesetzt wurde, bietet jedoch zwei entscheidende Vorteile: Bibliotheken, die nur von einem der beiden Programme benötigt werden, sind zum kompilieren des jeweils andern nicht erforderlich. Der Quelltext kann sauberer geschrieben werden, da man nur auf die Möglichkeiten des einen Programms Rücksicht nehmen muss. Besonders der erste Punkt ist für die Umsetzung wichtig, da der Master gegen Bibliotheken gebunden wird, die möglicherweise nicht auf allen Rechnern vorhanden sind, z.b. OpenGL, GLUT, GLU oder GLEW. Der Master ist das komplexere Programm. Er ist einerseits für die Verwaltung der Netzwerkverbindungen zu den einzelnen Slaves zuständig, andererseits muss er die errechneten Daten in einer Bilderfolge anzeigen. Zusätzlich kann der Master nicht nur Berechnungsaufgaben an die Slaves verteilen, sondern er kann auch lokale Ray Tracing Berechnungen durchführen. Der Master kann also auch unabhängig von anderen Rechnern als Darstellungsprogramm für Einzelrechner genutzt werden. Ein Slave verbindet sich bei Programmstart mit dem Master und bekommt von ihm die benötigten Anfangsinformationen. Danach erhält er über die Verbindung seine Arbeitsaufträge. Der Slave ist somit abhängig vom Master und kann nicht alleine laufen. Damit die beiden Teilprogramme, Master und Slave, miteinander kommunizieren können, wird ein Kommunikationsprotokoll zwischen ihnen benötigt. Im Abschnitt 4.3 wird dieses Protokoll detailliert erläutert. 2.1 Externe Abhängigkeiten Wie schon weiter oben erwähnt, ist bereits das Ausgangssystem Dream von diversen Bibliotheken abhängig: OpenGL, GLU platformunabhängige, schnelle Darstellungsroutinen. 4

11 GLUT platformunabhängige, Schnittstelle zum Windowing System. GLEW portable Behandlung von OpenGL Extensions. pthread POSIX Thread Library (portables Multithreading). Dream stellt für das Multithreading (Nebenläufigkeiten) sogenannte C++ Wrapper Klassen zur Verfügung 1. Ebenso werden für OpenGL Klassen zur einfachen Handhabung bereitgestellt. Was an externen Abhängigkeiten für diese Studienarbeit noch fehlt, sind die Netzwerkkomponenten. Damit der Stil von Dream nicht gebrochen wird, sind die Netzwerkkomponenten ebenfalls als dünne Wrapper Klassen in C++ implementiert. Auf diese Art ist das System nicht von weiteren externen Bibliotheken abhängig. 2.2 Komponenten des Systems Die beiden Teile des verteilten Ray Tracing Systems untergliedern sich wiederum in einzelne Komponenten. In diesem Abschnitt werden die Komponenten vorgestellt und ihre Abhängigkeiten untereinander verdeutlicht. In Abbildung 2.2 ist das Komponentendiagramm für den Master dargestellt. Die Komponenten sind im Diagramm farbig gekennzeichnet. Graue Komponenten sind als externe Bibliotheken eingebunden. Grün sind die Teile des ursprünglichen Dream Systems. Sie werden von der Studienarbeit großenteils nur genutzt und nicht maßgeblich verändert. Die blauen Komponenten sind durch die Studienarbeit hinzugekommen. Der Slave besitzt ein eigenes Komponentendiagramm, das in 2.3 abgebildet ist. Die geringere Komplexität des Slaves drückt sich durch weniger Abhängigkeiten im Diagramm aus Netzwerk Das Netzwerkmodul bietet dem System Zugriff auf das Netzwerk. Vom Betriebssystem werden sogenannte Sockets zur Verfügung gestellt. Ein Socket ist als Endpunkt einer Netzwerkverbindung zu verstehen. Wie der Einsatz von Sockets vermuten läßt, wird die Netzwerkkommunikation über das TCP/IP Protokoll (ein gängiges Protokoll für Ethernet Netzwerke) abgewickelt. 1 Wrapper Klassen kapseln den Zugriff auf Funktionen einer niedrigeren Schicht 5

12 Abbildung 2.2: Komponentendiagramm (Master) Das Modul ist in Form eines C++ Wrappers für Sockets geschrieben. Im Einzelnen werden folgende Klassen bereitgestellt: Socket Diese Klasse implementiert Basisfunktionalitäten zum Aufbau und zur Handhabung von Netzwerkverbindungen. TcpStream Diese Klasse erweitert die Socket Klasse um die Fähigkeit, Daten über einen virtuellen Datenstrom zu verschicken. Die zweite Aufgabe die vom Netzwerkmodul erfüllt wird, ist die Spezifizierung eines Netzwerkprotokolls. In der Klasse Protocol ist die gesamte Kommunikation zwischen dem Master und dem Slave geregelt, d.h., andere Programmmodule benötigen keinen direkten Zugriff auf die Methoden des TcpStreams, sondern können auf einer höheren Ebene Nachrichten mit Hilfe des Protokolls verschicken. Eine Besonderheit, auf die speziell geachtet wurde, ist die Byte-Order der Prozessorn. Die Linux/x86 Systeme besitzen Intel oder AMD Prozessoren. Diese speichern Daten im Little- 6

13 Abbildung 2.3: Komponentendiagramm (Slave) Endian Format, d.h. niederwertige Bytes liegen an niedrigeren Adressen im Speicher. Die Motorola Prozessor basierten Mac Systeme hingegen speichern im Big-Endian Format, also genau anders herum. Bei der Übertragung von Daten zwischen Systemen mit unterschiedlicher Byte-Order muss also darauf geachtet werden, dass die Daten jeweils richtig interpretiert werden. Die Verantwortlichkeit dafür liegt im Dream System bei den Slaves. Die zweite Möglichkeit wäre, die Daten nur in einer Byte-Order über das Netzwerk zu schicken, was zum Nachteil hätte, das Daten möglicherweise doppelt geswapt würden. Die dritte Möglichkeit, dass der Master für die richtige Ordnung der Bytes sorgt, hätte zum Nachteil, dass der Master einen erhöhten Speicher- und Rechenaufwand hätte. In der Klassenhierarchie ist allein der TcpStream dafür zuständig, die Daten in der korrekten Form zur Verfügung zu stellen Master Die Master Komponente besteht ebenfalls aus zwei Teilen. Zum Einen gibt es den ServerThread, eine Klasse, die zum Programmstart als eigener Thread gestartet wird. Zum Anderen gibt es viele SessionThreads, die bei Bedarf von dem ServerThread gestartet werden. 7

14 Die SessionThreads werden in einem SessionPool verwaltet. Die Aufgabe des ServerThreads ist es, eingehende Verbindungen festzustellen und an die SessionThreads weiterzuleiten. Dazu initialisiert er zu Programmstart einen Serversocket zum lauschen an einem bestimmten TCP Port. Sobald er eine neue Verbindung registriert, wird diese auf einen anderen Port verlegt und an einen neu erstellten SessionThread übergeben. Danach widmet der ServerThread sich wieder dem Lauschen an seinem Serversocket. Ein SessionThread bekommt vom ServerThread die Verbindung zu einem Slave in Form eines TcpStreams übergeben. Nach der Übergabe ist dieser SessionThread für die Kommunikation mit diesem Slave zuständig. Sobald die Kommunikation beendet ist, terminiert auch der SessionThread und gibt seine Ressourcen frei Slave Das Slavemodul enthält einen SlaveThread. Dieser beginnt mit dem Programmstart seine Arbeit. Seine erste Aktion ist der Aufbau einer Verbindung zum Master. Sollte dies nicht gelingen, bricht der SlaveThread umgehend seine Arbeit ab und beendet das Programm. Andernfalls beginnt der SlaveThread seine Kommunikation mit dem Master und sorgt dafür, dass das Programm mit den nötigen Daten versorgt wird. 8

15 3 Softwaremodell 3.1 Überblick In diesem Kapitel wird mit Hilfe gängiger UML Techniken das entwickelte Softwaresystem von der Design Seite her vorgestellt. Die hier abgebildeten Diagramme wurden mit dem UML Modelling Tool Umbrello[ea04] erstellt. Zum Einsatz kommen Klassendiagramme der beiden Systemteile (Master und Slave). Zum Einen werden Diagramme auf hohem Abstraktionsniveau verwendet, die einen Überblick über die Beziehungen der einzelnen Klassen geben. Zum Anderen werden detaillierte Klassendiagramme benutzt, die einen größeren Aufschluss über die Funktionsweise der wesentlichen Klassen geben. Weiterhin wird der Netzwerkteil mit Hilfe von Aktivitätsdiagrammen genauer betrachtet. Das Netzwerkprotokoll wird in vereinfachter Form als Statechart präsentiert. In allen Diagrammen ist die Farbgebung, die auch schon weiter oben verwendet wurde, konsequent weiterverfolgt. Grüne Teile sind also aus dem ursprünglichen Dream System und blaue Teile sind neu hinzugekommen. In den Diagrammen taucht eine Klasse GlutThread (türkisfarben markiert) auf. Sie existiert im Quellcode nicht und repräsentiert in den Diagrammen die Aufgaben der display()- Funktion. 3.2 Konzepte im Master Netzwerk Das Netzwerksubsystem besteht im Kern aus dem ServerThread und dem SessionThread. Beide sind von der Klasse Thread abgeleitet, daher müssen sie die Methode run() implementieren, die zum Starten eines Threads intern aufgerufen wird. Der ServerThread nutzt, wie in Abbildung 3.1 zu sehen ist, die Basisklasse Socket. Er führt über seinen Socket keine Kommunikation durch (wofür die Socketklasse selber auch nicht gedacht ist), sondern nutzt ihn nur zum Lauschen auf Verbindungen. 9

16 Die SessionThreads kommunizieren via Netzwerk mit den Slaves. Dazu nutzen sie den TcpStream, eine von Socket abgeleitete Klasse. Der TcpStream wird nicht direkt zum Senden von Netzwerknachrichten verwendet, dafür ist die Klasse Protocol zuständig. Sie bekommt bei der Initialisierung eine Referenz auf die entsprechende Instanz einer TcpStream Klasse und kann diese zur Kommunikation mit dem Master nutzen. Die Fehlerbehandlung des Netzwerkbereiches wird mit Hilfe von Exceptions durchgeführt. Die Exceptions werden vom Protocol und vom TcpStream geworfen und können vom ServerThread, respektive dem SessionThread, gefangen werden. Abbildung 3.1: Klassenübersicht (Master) Die IndexSource Schnittstelle Der Master verhält sich, solange keine Slaves verbunden sind, genauso wie das ursprüngliche Dream System. Um möglichst ohne Änderungen im Quelltext des ursprünglichen Systems auszukommen und dennoch die Erweiterungen einbauen zu können, existiert die Schnittstelle 10

17 IndexSource. Diese abstrakte Basisklasse definiert virtuelle Funktionen, die Integerwerte (interpretiert als Indexwerte im PrimaryPool 1 ) zur Verfügung stellen. Die IndexSource Schnittstelle wird von den Klassen PrimaryPool, IndexBuffer und NetIdxBuffer implementiert. So kann sich der PrimaryThread 2 im Einzelrechner-Modus wie bisher seine Aufträge aus dem PrimaryPool holen. Im Netzwerk-Modus wird der PrimaryPool jedoch nicht mehr direkt angesprochen, sondern nur über die Indirektion der Klassen IndexBuffer und NetIdxBuffer (Abbildung 3.2). Zu Beginn jedes Frames wird der PrimaryPool zu einem bestimmten Prozentsatz für lokale Berechnungen reserviert und in den IndexBuffer überführt. Der Rest wird in den NetIdxBuffer zur verteilten Berechnung übertragen. Diese Aufteilung ist sinnvoll, weil die Berechnungen des Masters so identisch wie möglich zum Originalsystem bleiben sollen. Im Originalsystem werden die Arbeitsaufträge vom PrimaryThread bearbeitet, der jedoch nur eine kurze Zeit der Berechnungsdauer am arbeiten ist. Den größeren Teil der Arbeit erledigt der ShadingThread. Dieses Verhältnis ist ungünstig für das Load Balancing im Netzwerk, denn ein Großteil der Aufträge würde lokal weggeschnappt werden und viele Slaves gingen leer aus. Wenn nun von Anfang an eine bestimmte Anzahl von Aufträgen zur lokalen Berechnung reserviert ist, muss nur noch das Verhältnis günstig sein um ein brauchbares Load Balancing zu erhalten (siehe Abschnitt 6.2.2) Das fertige Bild Das Bild eines Frames kommt aus zwei Quellen zustande. Die eine ist der lokale ShadingThread, der zum richtigen Zeitpunkt vom PrimaryThread geweckt wird. Der ShadingThread berechnet die Sichtbarkeit, Reflektionen und abschließend den eigentlichen Farbwert eines Pixels. Danach trägt der ShadingThread den Farbwert im DreamImage ein. Die zweite Quelle sind die SessionThreads. Diese bekommen im Netzwerk-Modus die Resultate der Berechnungen der Slaves übertragen und tragen diese ebenfalls im DreamImage ein Synchronisierung der Threads Die lokale Synchronisierung der Primary- und ShadingThreads im Zusammenspiel mit der display()-funktion von Glut hat sich nicht geändert. Auch im Netzwerk-Modus funktioniert die gleiche Synchronisierung mittels einer Barrier 3. Allerdings wird anschließend 1 Der PrimaryPool enthält Tiles; kleine, zu ray tracende Bildbereiche. 2 Der PrimaryThread führt die Schnittpunktberechnungen durch und benötigt dafür Aufträge in Form von Tiles. 3 Zu Framebeginn wird eine Barriere von einer Höhe n errichtet, die erst durchlässig wird, wenn n Threads die Barriere betreten. 11

18 Abbildung 3.2: Detailiertes Klassendiagramm (Master) 12

19 zusätzlich auf die Fertigstellung der Arbeitsaufträge im NetIdxBuffer gewartet, sofern diese noch nicht abgearbeitet sind. Falls tatsächlich noch Aufträge im NetIdxBuffer warten - d.h. das Verhältnis der initialen Aufteilung der Arbeitsaufträge in Index- und NetIdxBuffer war nicht besonders günstig - unterstützt der Master während des Wartens die Abarbeitung der restlichen Arbeitsaufträge. Zur Unterstützun werden nicht der Primary- und ShadingThread herangezogen, sondern, wie auch auf den Slaves, ein SimpleTraceThread. Auf diese Art können Schwankungen in der Netzwerkübertragung ausgeglichen werden. 3.3 Konzepte im Slave Zentral: Der SlaveThread Im Slave übernimmt der SlaveThread kurz nach Programmstart die Kontrolle. Der Slave- Thread versucht eine Verbindung über einen TcpStream mit dem Master aufzubauen. Falls dies gelingt, beginnt er die Kommunikation mit dem Master mit Hilfe einer Instanz der Protocol Klasse. Sobald er die nötigen Daten, wie die Scene und die Größe des Bildes, empfangen hat, kann er seine SimpleTraceThreads, die für die Bearbeitung von Arbeitsaufträgen zuständig sind, starten. Anschließend sorgt der SlaveThread in einer Schleife dafür, dass stets genügend Arbeitsaufträge im IndexBuffer sind. Aus diesem können die SimpleTraceThreads ihre Aufträge beziehen Synchronisierung mittels IndexBuffer Der Slave versucht seinen IndexBuffer stets mit einer bestimmten Anzahl 4 von Arbeitsaufträgen voll zu halten. Da die SimpleTraceThreads ihre Arbeitsaufträge aus diesem IndexBuffer beziehen und nebenläufig sind, ist der IndexBuffer durch einen Mutex geschützt. Sollte der IndexBuffer leer werden, z.b. wenn ein Bild fertiggestellt ist, oder der SlaveThread nicht schnell genug für Nachschub sorgen kann, vergeuden die SimpleTraceThreads keine Prozessorzeit, sondern schlafen ein. Sobald wieder neue Arbeitsaufträge im IndexBuffer eintreffen, weckt dieser automatisch alle darauf wartenden Threads. 4 Die genaue Größe des IndexBuffers kann per Kommandozeilenparameter übergeben werden -q <anzahl>. Bei langsamen Rechnern sollte keine zu Große Anzahl von Arbeitsaufträgen vorgehalten werden, da sich sonst das ganze System verlangsamt. 13

20 Abbildung 3.3: Klassenübersicht (Slave) 14

21 3.3.3 Berechnung der Farbwerte Im Slave werden die Farbwerte einzelner Pixel durch einen oder mehrere SimpleTraceThreads berechnet. Ein SimpleTraceThread korrespondiert zu jeweils einem PrimaryThread und einem ShadingThread im Master. Der Unterschied zum Master liegt darin, dass die Arbeitsschritte sequentiell abgearbeitet werden. Abbildung 3.4: Detailiertes Klassendiagramm (Slave) 15

22 3.3.4 Verbindungsabbruch Der Slave kann auf zwei Arten beendet werden. Entweder er bekommt ein Unterbrechungssignal 5, oder die Verbindung bricht ab, was durch ein Beenden des Masters oder eine Verbindungsstörung geschehen kann. Im Fall eines Unterbrechungssignals wird vom Slave eine Nachricht(msgBye) zur Mitteilung seines Vorhabens gesendet. Anschließend trennt er die Verbindung und beendet das Programm. In den anderen Fällen braucht nur das Programm beendet zu werden, da die Verbindung nicht mehr existiert. 3.4 Netzwerkkommunikation Aufbau des ServerThreads Die Funktionsweise des ServerThreads wurde im vorangegangenen Kapitel schon kurz angesprochen. In diesem Abschnitt wird der Ablauf der ServerThreads schematisch als Aktivitätsdiagramm (siehe Abbildung 4.7) dargestellt. Der ServerThread befindet sich die meiste Zeit in einem wartenden Zustand, der nahezu keine Ressourcen verbraucht. Sobald jedoch eine eingehende Verbindung festgestellt wird, nimmt der Server diese an und erstellt zur Kommunikation mit dem entfernten Rechner einen SessionThread, der ab dann für diese Verbindung alleine zuständig ist. Anschließend fällt der Server wieder in seinen Wartezustand. Der Wartezustand ist zusätzlich mit einem Timeout von einer Sekunde versehen, damit der ServerThread von Zeit zu Zeit ansprechbar ist und auch wieder beendet werden kann. Damit der ServerThread beim Beenden alle noch offenen Verbindungen schließen kann, wurde der SessionPool entworfen, der die Verwaltung der SessionThreads übernimmt. Diese Klasse ermöglicht das Hinzufügen eines neuen SessionThreads in den Pool und das Beenden aller SessionThreads die zu dem Zeitpunkt im Pool sind Netzwerkprotokoll Eine vereinfachte, jedoch umfassende Darstellung des Kommunikationsprotokolles, welches zwischen SessionThread und SlaveThread gilt, ist in Abbildung 3.6 als Statechart dargestellt. In diesem Statechart wird die übliche Semantik für Transitionsbeschriftungen verwendet: Ereignisse werden normal dargestellt. 5 Wird in einem Terminal meist mit CTRL+C gesendet. 16

23 Abbildung 3.5: Ablauf des ServerThreads 17

24 Wächter 6 werden in eckige Klammern geschrieben. Aktionen, die beim Transitionsübergang ausgelöst werden, sind hinter einen Slash gestellt. Das Diagramm ist insofern vereinfacht, als daß keine Netzwerkfehler berücksichtigt wurden. Dies kann aber vernachlässigt werden, da bei einem Fehler stets das Programm abgebrochen wird. Fehler kommen jedoch im Normalfall nicht vor, da TCP/IP ein sicheres Protokoll ist, das bei Fehlern eine Neuübertragung veranlasst. Zu Beginn einer Verbindung zwischen Master und Slave liegt die Initiative beim Master. Der Slave hingegen verhält sich passiv und wartet alle vom Master kommendenen Nachrichten ab, bis eine msgnoop (No Operation) kommt, die die Initialphase beendet. Innerhalb der Initialphase sendet der Master eine msghelo, die den Slave begrüßt und die Serverseitige Byte- Order mitteilt. Anschließend teilt der Master interaktiv einige Daten zur aktuellen Szene mit, so auch den Namen der Szenedatei, die Größe des Bildes und bei Bedarf sogar den kompletten Inhalt der Szenedatei. Ab dann liegt zum größten Teil der Zeit die Initiative beim Slave. Dieser startet zuerst eine msgrequest, woraufhin der Master weiß, daß dem Slave Arbeitsaufträge fehlen. Dann wird der Master bei Bedarf (d.h., falls ein neuer Frame begonnen hat) die Kamera Informationen in einer msgcamera und danach, sofern im NetIdxBuffer vorhanden, die gewünschte Anzahl an Arbeitsaufträgen als msgtile versenden. Abgeschlossen wird der Request wiederum durch eine msgnoop. Falls also keine Arbeitsaufträge, sondern nur eine msgnoop beim Slave ankommt, weiß dieser, daß zur Zeit seine Rechenleistung nicht benötigt wird. Wenn der Slave einen Arbeitsauftrag erledigt hat und somit Farbwerte für den Master bereit sind, verschickt er diese Ergebnisse eines Tiles gebündelt in einer msgresults an den Master zurück. Sobald keine Aufträge mehr in Bearbeitung sind und vom Master keine weiteren Aufträge zu erhalten sind (da zur Zeit kein Frame in Auftrag ist), fällt der Slave in einen Ruhezustand. Die SimpleTraceThreads befinden sich zu dem Zeitpunkt schon in einem Schlafzustand. Der SlaveThread sendet eine msgwait an den Master. Diese Nachricht sagt dem Master, daß der Slave idle ist und sendet erst eine Antwort, nachdem ein Timeout aufgetreten ist oder neue Arbeitsaufträge vorhanden sind (ein neuer Frame hat angefangen). 6 Bedingung die beim Transitionsübergang gelten muss. 18

25 Abbildung 3.6: Netzwerkprotokoll als Statechart 19

26 4 Implementierung 4.1 Programmierkonventionen Die Implementierung des Systems erfolgte analog zu der ursprünglichen Implementierung von Dream in objektorientiertem C++. Wie auch in Dream wurde auf die Dokumentierung aller Klassen geachtet, so daß mit einem Programm zur automatisierten Erstellung von Dokumentationen (Doxygen [vh04]) eine komplette Beschreibung aller Klassen in HTML erzeugt werden kann. 4.2 Klassenbeschreibungen In den folgenden Abschnitten werden die Klassen aus den vier neuen Komponenten (Master, Slave, Network und Tools 1 ) beschrieben und Details ihrer Implementierung näher erläutert. Neben jeder Klasse wird ein UML konformes Klassendiagramm dargestellt, das einen Überblick über die Methoden und Attribute der Klasse geben soll Tools IndexSource Diese Klasse ist eine Schnittstelle 2 für Integerwerte liefernde Quellen. Die Werte werden von der Funktion nextindex() geliefert. Falls keine Werte mehr in der Quelle vorhanden sind, wird der Fehlerwert NO TILE zurückgeliefert. Bei den gespeicherten Werten handelt es sich um Indizes auf Tiles im PrimaryPool, die als Arbeitsauftrag verstanden werden können. In Abschnitt ist beschrieben, wir diese Schnittstelle im Zusammenspiel mit den anderen Klassen funktioniert. Abbildung 4.1: IndexSource 1 Das Modul Tools gab es schon zuvor. Es wurde jedoch um einige Klassen erweitert, die hier vorgestellt werden. 2 Schnittstelle: in C++ Terminologie heißt dies Abstrakte Basis Klasse. 20

27 IndexBuffer Der IndexBuffer implementiert die Schnittstelle IndexSource. Zum Speichern der Integerwerte wird intern ein Vector aus der Standard Bibliothek benutzt. Zum Eintragen von Werten in den Vector wird die Funktion addindex() verwendet, die nicht in der Schnittstelle definiert ist, da die Schnittstelle sich auf das Entnehmen von Werten beschränkt. Die Funktion weckt alle Threads, die auf neue Werte warten, auf, sofern der entsprechende Parameter sigifwaiting mit übergeben wird und solche wartenden Threads existieren. Abbildung 4.2: IndexBuffer Auf Seite des Masters dient der IndexBuffer als Quelle für Arbeitsaufträge für den Primary- Thread. Der Buffer wird zu Beginn eines neuen Frames mit einem Prozentsatz aller zu berechnenden Tiles gefüllt. Dies gilt jedoch nur für den Netzwerk-Modus, im Einzelrechner-Modus bezieht der PrimaryThread seine Aufträge aus dem PrimaryPool (siehe Abschnitt 3.2.2). Auf Seite des Slaves beziehen die SimpleTraceThreads ihre Arbeitsaufträge aus einem Index- Buffer. Hier wird der IndexBuffer vom SlaveThread mit neuen Aufträgen gefüllt, die dieser via Netzwerk vom Master abruft. NetIdxBuffer Der NetIdxBuffer ist von der Klasse IndexBuffer abgeleitet und implementiert somit ebenfalls die IndexSource Schnittstelle. Auch er wird zu Beginn eines Frames mit Arbeitsaufträgen gefüllt. Er enthält den zum IndexBuffer komplementären Teil an Arbeitsaufträgen. Diese sind jedoch nicht zur lokalen Berechnung, sondern zur Verteilung ins Netzwerk gedacht. Aus diesem Grund muss über die durch nextindex() herausgegebenen Werte Buch geführt werden, um feststellen zu können welche Aufträge schon erledigt sind und welche noch im Netzwerk in Bearbeitung sind. Abbildung 4.3: NetIdxBuffer Wenn die Berechnungsresultate beim Master eintreffen, muss daher die Funktion release() für das zugehörige Tile aufgerufen werden, um dieses aus der Buchführung zu streichen. Zum Speichern der herausgegebenen Aufträge wird eine std::map verwendet, da mit dieser schnell auf bestimmte Werte zugegriffen werden kann. 21

28 4.2.2 Network Socket Der Socket bildet als C++ Wrapper Klasse die Schnittstelle zu den systemnahen Socket Funktionen. Die Klasse bietet keine Methoden zur Übertragung, sondern nur zum Aufbau einer Verbindung (Serverseitig oder Clientseitig). Um einen Socket zu erstellen, der auf einem bestimmten Port lauscht (Serversocket genannt), ist folgende Befehlsfolge nötig: Socket server; server.create(); Abbildung 4.4: Socket server.bind (<portnummer>); server.listen(); Socket stream; while (server.ispending(pendingconnection, <timeout>)) { server.accept(stream); // Kommuniziere über den neu erstellten stream stream.disconnect(); } Um hingegen als Client zu einem Serversocket zu verbinden, reicht diese Befehlsfolge: Socket client; client.create(); client.connect(<servername/ip>, <port>); // kommuniziere mit server client.disconnect(); Da der Socket selber keine Funktionen zur Kommunikation besitzt, ist es sinnvoll für Clientsockets den im folgenden Abschnitt beschriebenen TcpStream zu verwenden. TcpStream Der TcpStream ist abgeleitet von der Socket Klasse. Er erweitert die Socket Klasse um Funktionen zur Kommunikation mit dem verbundenen Socket. 22

29 Er ist zum Einsatz als Clientsocket gedacht und bietet explizite Funktionen zum Übertragen von Bytes, Integerwerten, Gleitkommazahlen und Datenströmen. Außerdem kann mit der Funktion setbyteswap() eingestellt werden, ob beim Übertragen von Werten, die je nach Byte-Order des Prozessors unterschiedlich interpretiert werden können, ein Tausch der einzelnen Bytes vorgenommen werden soll. Der TcpStream ist dafür verantwortlich, dass die Werte im richtigen Format vorliegen. Um hohe Datenübertragungsraten erzielen zu können, sollten so wenig Pakete wie möglich verschickt werden, die so groß wie möglich sind. Im Verlauf der Performance-Tests wurden zwei unterschiedliche Übertragungsmethoden getestet. Die eine Methode war leicht zu implementieren und führte intern zu 8 Systemaufrufen von ::send() mit jeweils 128 zu sendenden Bytes. Die zweite Methode erforderte mehr Aufwand bei der Implementierung und führte dazu, dass nur noch ein Systemaufruf Abbildung 4.5: TcpStream von ::send() mit 1024 zu übertragenden Bytes stattfand. Das Ergebnis der Tests war, dass die zweite Methode die Übertragung um einen Faktor von bis zu vier beschleunigen konnte. Da zum Erhalten von interaktiven Frameraten ein enorm hoher Datendurchsatz notwendig ist (zum Übertragen eines Bildes der Größe 512x512 Pixel, werden schon 4 MB benötigt, interaktive Frameraten verlangen jedoch mehr als ein Bild pro Sekunde), müssen die Übertragungsmethoden stark optimiert sein. Um die Anzahl der Aufrufe von ::send() zu minimieren ist die Klasse so programmiert, dass alle Methoden zum Versenden die Daten vorerst intern in einen Buffer schreiben. Erst wenn dieser Buffer voll ist, oder ein flush() aufgerufen wurde, werden die Daten tatsächlich abgeschickt. 23

30 Protocol Wie im vorangegangenen Kapitel beschrieben, dient die Klasse Protocol dem Kapseln der gesamten Netzwerkkommunikation. Die einzelnen Methoden repräsentieren die Protokollstruktur des Systems. Das Zusammenspiel der Methoden ist ein Hauptbestandteil der Studienarbeit und wird daher am Ende dieses Kapitels ausführlich beschrieben. Die Klasse steht im engen Zusammenhang mit dem TcpStream, der die Übertragung der einzelnen Nachrichten vornimmt. Daher muss auch die Protocol Klasse mit Blick auf die Minimierung der Anzahl an übertragenen Paketen implementiert werden. Ebenfalls wichtig zur Maximierung des Datendurchsatzes ist die Vermeidung von Latenzzeiten, die durch interaktive Nachrichten auftreten. Aus diesem Grund sind diejenigen Nachrichten, die während der Kommunikation zum Berechnen eines Frames auftreten, soweit möglich, nicht interaktiv gehalten. Abbildung 4.6: Protocol Master ServerThread Die Funktionsweise des ServerThread ist im Abbschnitt beschrieben. Der ServerThread ist verantwortlich für die SessionThreads und den SessionPool. Mit dem ServerThread werden am Programmende die Instanzen dieser beiden Klassen terminiert und deren Ressourcen freigegeben. Abbildung 4.7: ServerThread 24

31 SessionPool Im SessionPool sind die SessionThreads, die mit den Slaves kommunizieren in einer std::list abgelegt. Um diese Liste bei Programmende zu leeren, müssen alle in ihr enthaltenen Threads zum Stoppen veranlasst, ihre Terminierung abgewartet und ihre Ressourcen freigegeben werden. Abbildung 4.8: SessionPool SessionThread Ein SessionThread ist jeweils für die Kommunikation mit einem verbundenen Slave verantwortlich. Der SessionThread steht, wie in Abschnitt erläutert, für Anfragen des Slaves zur Verfügung. Da der Session- Thread eine eigenständige Einheit ist, kann er sich bei einer vorzeitigen Terminierung (z.b. aufgrund von Verbindungsfehlern oder vorzeitigen Programmabbruchs des zugehörigen Slave) selbst aus der ihn enthaltenden Liste entfernen und zerstören. Abbildung 4.9: SessionThread Slave SlaveThread Auf Seite des Slaves ist der SessionThread mit einem SlaveThread verbunden. Der Slave- Thread ist verantwortlich für die Erzeugung der Instanzen von allen wichtigen Klassen, wie z.b. Scene, Image, TcpStream, Protocol oder SimpleTraceThreads. Zum Programmstart versucht er sich mit dem Master zu verbinden. Kommt die Verbindung zustande, erhält er die benötigten Informationen über den Namen der Szene und die Bildgröße. Schlägt die Verbindung jedoch fehl, wird der Slave umgehend beendet, da er ohne Master keine sinnvolle Arbeit verrichten kann. 25

32 In seiner Betriebsphase muss der SlaveThread versuchen, mit möglichst wenig Prozessorzeit den IndexBuffer für die SimpleTraceThreads voll zuhalten. Dies macht er, indem er in einer Schleife prüft, ob der IndexBuffer neue Aufträge benötigt und ob neue Ergebnisse zum versenden an den Master bereit sind. Zum Abschluss jedes Durchlaufes dieser Schleife gibt er mit dem Aufruf yield() seine Rechenleistung ab. Abbildung 4.10: SlaveThread Sobald der SlaveThread feststellt, dass ein Frame fertiggerendert wurde, gibt er entsprechende Leistungsstatisken auf der Konsole aus. TraceThreadPool Der TraceThreadPool kann eine bestimmte Anzahl an SimpleTraceThreads erzeugen und verwalten. Zum Speichern der Referenzen wird ein std::vector verwendet. Wenn der Slave beendet wird, veranlasst der TraceThreadPool die Abbildung 4.11: TraceThreadPool Terminierung aller in ihm enthaltenen Threads und leert anschließend seinen Pool, indem er die Ressourcen der Threads freigibt. SimpleTraceThread Der SimpleTraceThread übernimmt im Slave die entsprechende Funktion, wie der PrimaryThread und der ShadingThread im Master, d.h. er bezieht Arbeitsaufträge aus einer IndexSource und berechnet die zugehörigen Farbwerte im Bild. Wenn keine Aufträge vorhanden sind, schläft der Thread ein um keine Prozessorzeit zu vergeuden. Abbildung 4.12: SimpleTraceThread 4.3 Das Netzwerk Protokoll Dieser Abschnitt behandelt einen Hauptbestandteil des um Netzwerk erweiterten Dream Systems: Das Netzwerk Protokoll. Der Zustandsgraph der beiden Netzwerkkommunikationspartner (auf Master Seite der SessionThread und auf Slave Seite der SlaveThread) wurde im Abschnitt schon spezifiziert und erläutert. Hier soll die Implementation der einzelnen Netzwerknachrichten erklärt werden. Die gesamte in diesem Abschnitt vorgestellte Funktionalität liegt im Zuständigkeitsbereich der Klasse Protocol. 26