MiCaDo Projektbericht - artecLab - Universität Bremen

ab 6 : Die beobachteten Paketverluste waren stets auf einen Überlauf des vom Betriebssystem bereitgestellten
Socket-Puffers zurückzuführen 7 , weil die Cave-Anwendung die ankommenden Pakete nicht
so schnell bearbeiten konnte, wie sie am UDP-Socket eintrafen. Dies lag darin begründet, dass anwendungsseitig
das Rendern der Grafik sowie das Abholen und Bearbeiten der Netzwerkpakete
abwechselnd von einem einzigen Thread vorgenommen wurde, der neue Pakte nur dann abholte,
wenn er gerade nichts anderes zu tun hatte.
Das Workaround bestand daher aus der Einführung eines dedizierten Receiver-Threads, welcher
nichts anderes tut, als Pakete vom UDP-Socket abzuholen und in einer verketteten Liste zwischenzuspeichern,
aus welcher der Hauptthread der Cave-Anwendung sie nacheinander abholt – also in
der Schaffung eines sekundären Paketpufferpools innerhalb der Engine. Unsere Implementierung
versucht hierbei den durch das Memory Management entstehenden Overhead möglichst klein zu
halten, indem sie die Allokation und Freigabe von Heapspeicher auf ein Minimum reduziert. Das
Workaround behebt zwar nicht die Auswirkungen eines Paketverlustes, da es nur die Wahrscheinlichkeit
eines solchen reduziert, dennoch kann sich das Ergebnis sehen lassen: Während des gesamten
Projekttages blieb der Cave nicht ein einziges Mal aufgrund eines Paketverlustes stehen. Eine
Weiterentwicklung der Madness bietet sich jedoch nach wie vor in einer Realisierung der sauberen
Lösung an – der paketverlusttoleranten Reimplementierung des Netzwerkcodes.
6 u.a. aufgrund berechtigter Bedenken, kurz vor einer wichtigen Deadline, bzw. dem Projekttag, möglicherweise mehr
Fehler einzubauen, als am Ende zu beheben.
7 Ist dieser Puffer voll, gehen alle weiteren eintreffenden Pakete verloren.
111