Projekt Micarpet Projektbericht - artecLab - Universität Bremen

Projekt MiCarpet Projektbericht
12.4 Netzwerksystem
Wie schon in der Übersicht erwähnt wurde, ist das System fähig, mehrere Computer parallel in einem
Netzwerk zu nutzen, um mehrere Ansichten der Szene verteilt auf mehreren Rechnern zu rendern. Das
hat den Vorteil, dass jeder Rechner nur eine Standard-Grafikkarte mit einem Ausgang benötigt. Es wäre
zwar auch theoretisch möglich, nur einen Rechner zu benutzen, das aber erfordert eine Ausstattung mit
einem Grafikausgang für jede Projektionswand und ist somit nur sehr schlecht zu realisieren. Insbesondere
wäre ein Rechner mit dem gleichzeitigen Rendern mehrerer Ansichten bei interaktiven Bildwiederholungsraten
überfordert.
Da wir keine stereoskopische Ansicht im System nutzen (für die pro Wand auch zwei Projektoren oder
ein Spezialprojektor mit extrem hoher Bildwiederholungsrate notwendig wäre), sind die Aufgaben für
das Netzwerksystem, welches die verteilte Grafikausgabe koordiniert, folgende:
• Finden der Rechner im Netz, Initialisieren und Beenden einer Sitzung
• Synchronisation des Renderns aller Rechner auf Framebasis
• Synchronisation der Szene (Animation, Änderungen im Objektstatus)
Wir haben auf Basis des Netzwerkprotokolls TCP/IP[TCP/IP??] (das Standardprotokoll im Internet,
siehe [?]) ein Netzwerksystem für die Engine entwickelt, welches diese Punkte erfüllt. Unser System
setzt dabei auf dem Protokoll UDP auf, welches eine verbindungslose und schnelle Datenübertragung
ermöglicht. Das übliche Protokoll TCP schied dabei aus, weil es verbindungsbasiert ist und so bei jedem
Paket noch weitere Verbindungsinformationen (Datenbestätigungen, ...) übertragen werden müssen, was
insgesamt die Latenzzeit erhöht. In unserem Fall ist aber die Latenzzeit entscheidender als die Verbindungssicherheit,
da jede Verzögerung durch Datenübertragung die Reaktionszeit des Systems erhöht. Die
durch die Verwendung von UDP fehlende Übertragungssicherheit (UDP garantiert keine Erkennung und
Behebung bei Paketverlusten) fällt nicht ins Gewicht, da wir in einem lokalen Netzwerk arbeiten, in dem
im Normalfall keine Verluste entstehen sollten. In den meisten Fällen kann außerdem das System einen
solchen Ausfall ausgleichen.
Aufbau Das Protokoll baut auf dem Master/Slave-Prinzip auf, d.h. es gibt einen bestimmenden Rechner
(Master) und n untergeordnete Clients (Slaves). Wie in Abbildung 10.2 auf Seite 71 schon zu sehen
war, hat üblicherweise der Master auch alle Peripherie-Geräte und die Slaves haben nur jeweils einen
Grafikausgang. Es wäre aber auch einfach möglich, dass der Master selbst keine Grafik ausgibt und nur
die Slaves Projektoren ansteuern. Änderungen an der Szene und dem Status kann allerdings nur der
Master hervorrufen, die Slaves selbst haben ansonsten keine Mitwirkungsmöglichkeiten.
Die Kommunikation im Netzwerksystem über UDP/TCP/IP kann auf drei verschiedene Arten erfolgen:
• Unicast. Entspricht jeweils einer 1:1 Verbindung. Der Master schickt also Pakete, die an alle Slaves
gesendet werden sollen, nacheinander einzeln an alle Slaves, was natürlich gerade bei steigender
Anzahl Slaves länger dauern kann. Dementsprechend skaliert diese Lösung schlecht mit einer
steigenden Menge an Slaves, bei einer kleinen Menge von Slaves (2-3) ist die dadurch entstehende
Verzögerung bei unseren Tests noch vernachlässigbar gewesen.
• Broadcast. Hier schickt der Master Pakete grundsätzlich an alle Rechner im Netzwerk, also auch
alle, die gar nicht im System teilnehmen. Dadurch muss jedes Paket an die Slaves natürlich nur
einmal geschickt werden, in einem größeren Netzwerk erhalten aber viele Rechner Pakete, die sie
nichts angehen und es kann so zu einer Störung des Datenverkehrs kommen (insbesondere, weil
6. Januar 2005 Seite 108