Entwicklung eines objektorientierten Client-Server-Systems zur Verteilung von Renderprozessen unter besonderer Berücksichtigung von Userinteraktionen und Abrechnungsmechanismen E-Book
Daniel Wedewardt
36,99 €
Mehr erfahren.
- Herausgeber: GRIN Verlag
- Sprache: Deutsch
Diplomarbeit aus dem Jahr 2002 im Fachbereich Informatik - Angewandte Informatik, Note: 1,0, Hochschule für Technik und Wirtschaft Berlin, Sprache: Deutsch, Abstract: Dem computeranimierten Film wird eine große Zukunft vorhergesagt. Die Zahl der Produktionen steigt von Jahr zu Jahr. Doch nicht jede Produktions£rma kann es sich leisten, selbst für genügend Rechenkapazität zu sorgen. Das ist die Stunde der Dienstleister. Die Firma DIGITAL SYSTEMS ist einer dieser Dienstleister. Sie bieten ihre Rechenkapazität gegen ein Entgeld an. Auf diese Weise kann es sich auch eine kleine Produktions£rma leisten, einen aufwändigen Film zu produzieren. Sie muss sich um die Unterhaltung der Computer, welche die Rechenkapazität zur Verfügung stellen, keine Gedanken machen. Sie wendet sich einfach an den Dienstleister und dieser übernimmt das Rendern, den rechenintensiven Teil der Produktion eines computeranimierten Filmes. Für den Dienstleister stellt sich jedoch das Problem, wie er seine Leistung möglichst transparent dem Kunden gegenüber abrechnen und wie er den eigenen Administrationsaufwand möglichst minimieren kann. Zudem muss der Dienstleister sicherstellen, dass seine Computer möglichst gleichmäßig ausgelastet sind und berücksichtigen, dass ein Auftrag so schnell wie möglich beendet werden soll. In der Diplomarbeit soll gezeigt werden, dass es möglich ist, eine Renderfarm mit geringstmöglichem Aufwand zu betreiben, indem der Kunde einen Großteil der Aufgaben selbst erledigen kann. Der Administrator soll nur im Notfall eingreifen müssen.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Veröffentlichungsjahr: 2006
Ähnliche
Page 1
Page 3
3.3.3 Common Object Request Broker Architekture . . . . . . . . . 15 3.3.4 Simple Object Access Protocol . . . . . . . . . . . . . . . . . 16 3.4 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.2 Variablen-Handling . . . . . . . . . . . . . . . . . . . . . . . 17 3.5 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6 3D-Computergra£k . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6.1 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.2 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.3 Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Anforderung 22
4.1 IST-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.1 Renderbus . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.2 RenderControl V.2 . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 Zielbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.1 Renderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3 Zielgruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.4 Einsatzgebiet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5 Funktionsumfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5.1 GUI des Kunden . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5.2 GUI des Administrator . . . . . . . . . . . . . . . . . . . . . 28 4.5.3 Verteilanwendung . . . . . . . . . . . . . . . . . . . . . . . 31 4.6 Hardwarespezi£kation . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.7 Betriebssystemspezi£kation . . . . . . . . . . . . . . . . . . . . . . 32
5 Konzeption und Entwurf 33
5.1 Datenbankentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.1 Wahl des Datenbankbetriebsystems . . . . . . . . . . . . . . 34 5.1.2 De£nition der Datenbanktabellen . . . . . . . . . . . . . . . 34
Page 4
iv
5.1.3 De£nition der Relationen . . . . . . . . . . . . . . . . . . . . 36 5.2 verschiedene Client / Server Kommunikationsansätze . . . . . . . . . 39 5.2.1 Parallel Virtual Maschine . . . . . . . . . . . . . . . . . . . . 39 5.2.2 Remote Methode Invocation . . . . . . . . . . . . . . . . . . 40 5.2.3 Common Object Request Broker Architekture . . . . . . . . . 41 5.2.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3 gra£sche Benutzerober¤äche . . . . . . . . . . . . . . . . . . . . . . 42 5.3.1 Programmierung . . . . . . . . . . . . . . . . . . . . . . . . 42 5.3.2 Gestaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.4 Sicherheitsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . 47 5.4.1 Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.4.2 Authentisierung . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.4.3 Session-Management . . . . . . . . . . . . . . . . . . . . . . 49 5.4.4 Angriff eines authentisierten Benutzers . . . . . . . . . . . . 52 5.4.5 Angriffspunkt Datenbank . . . . . . . . . . . . . . . . . . . . 53 5.4.6 Sicherheitsrisiko FTP . . . . . . . . . . . . . . . . . . . . . . 54 5.4.7 Komplexitätsanalyse . . . . . . . . . . . . . . . . . . . . . . 55 5.5 Verteilalgorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.6 Abrechnungsmechanismen . . . . . . . . . . . . . . . . . . . . . . . 58
6 Implementierung 61
6.1 Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . 61 6.2 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.3 Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.3.1 Renderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.3.2 Überprüfung der tatsächlichen Existenz von gerenderten Frames 65 6.3.3 Anbindung von Renderknoten über das WAN . . . . . . . . . 66 6.3.4 Parallelität der Auftragsvergabe . . . . . . . . . . . . . . . . 67
Page 5
v
A Glossar I
B Tabellenverzeichnis XIII
C Abbildungsverzeichnis XIV
Page 6
Hinweise zur Benutzung dieses
Dokumentes
Bei der Erstellung dieses Dokumentes wurde darauf geachtet, dass auch Laien einen Sachverhalt nachvollziehen können. Fachbegriffe, welche allgemein in ihrer Abkürzung gebraucht werden, werden bei der ersten Verwendung ausgeschrieben. Im weiteren Verlauf nur noch als Abkürzung weiterverwendet. Aus Gründen der besseren Lesbarkeit kann es vorkommen, dass Abkürzungen doppelt beschrieben werden (beispielsweise.: HTTP-Protokoll). Fremdworte, Eigenbezeichnungen und Abkürzungen sind im Glossar zu £nden. Der dort angebrachte Hinweis ist zu beachten. Im Glossar erklärte Begriffe sind Kursiv vom übrigen Text abgehoben.
Page 7
Danksagung
Ich danke allen Menschen, die mich während der Erstellung meiner Diplomarbeit begleitet haben, meine Macken ertragen haben und immer wieder durch neue Ideen dazu beigetragen haben, die Arbeit ein Stück besser werden zu lassen. Würde ich an dieser Stelle alle Menschen aufzählen, so würden wohl einige Seiten beschrieben werden, darum beschränke ich mich auf die für mich Wichtigsten:
•Britta
•meiner lieben Familie
•meinen lieben Komilitonen, denn geteiltes Leid ist halbes Leid
•der Firma DIGITAL SYSTEMS, insbesondere Danny und Herrn Loos
Page 1
Kapitel 2
Einleitung und Motivation
2.1 Einleitung
Dem computeranimierten Film wird eine große Zukunft vorhergesagt. Die Zahl der Produktionen steigt von Jahr zu Jahr. Doch nicht jede Produktions£rma kann es sich leisten, selbst für genügend Rechenkapazität zu sorgen. Das ist die Stunde der Dienstleister. Die Firma DIGITAL SYSTEMS ist einer dieser Dienstleister. Sie bieten ihre Rechenkapazität gegen ein Entgeld an. Auf diese Weise kann es sich auch eine kleine Produktions£rma leisten, einen aufwändigen Film zu produzieren. Sie muss sich um die Unterhaltung der Computer, welche die Rechenkapazität zur Verfügung stellen, keine Gedanken machen. Sie wendet sich einfach an den Dienstleister und dieser übernimmt das Rendern, den rechenintensiven Teil der Produktion eines computeranimierten Filmes. Für den Dienstleister stellt sich jedoch das Problem, wie er seine Leistung möglichst transparent dem Kunden gegenüber abrechnen und wie er den eigenen Administrationsaufwand möglichst minimieren kann. Zudem muss der Dienstleister sicherstellen, dass seine Computer möglichst gleichmäßig ausgelastet sind und berücksichtigen, dass ein Auftrag so schnell wie möglich beendet werden soll. In der Diplomarbeit soll gezeigt werden, dass es möglich ist, eine Renderfarm mit geringstmöglichem Aufwand zu betreiben, indem der Kunde einen Großteil der Aufgaben selbst erledigen kann. Der Administrator soll nur im Notfall eingreifen müssen.
2.2 Motivation
Bereits während des Studiums habe ich mich mit dem Thema der Verteilung von Arbeitsintensiven Prozessen auf mehrere Computer beschäftigt. Um ein Semesterbeleg rechtzeitig abliefern zu können, entstand die Idee, die ungenutze Rechenpower eines
Page 2
KAPITEL 2. EINLEITUNG UND MOTIVATION2
ganzen Unix-Labors zu vereinen, anstatt auf nur einem Rechner des selben Labors die gesamte Arbeit ausführen zu lassen. Bei der Suche nach einem Thema für die Diplomarbeit kam der Zufall ins Spiel. Auf der CeBIT 2001 traf ich per Zufall auf die Firma DIGITAL SYSTEMS aus Leipzig. Sie gehört zu den wenigen Firmen, welche Rechenzeit gegen Bezahlung anbietet. Ich hatte die Gelegenheit die damals aktuelle Version der Software zum Verteilen von Renderprozessen zu begutachten. Auf den ersten Blick war mein Interesse geweckt diese Software zu vervollkommnen. Aber erst die Ideen der Firma machten den Service, der er heute ist. Die Zusammenarbeit hat sich als äußerst produktiv erwiesen und wird sich in Zukunft auch als weiterhin produktiv erweisen, da ich das Glück habe, direkt nach Beendigung des Studiums als fester Mitarbeiter eingestellt zu werden.
Page 3
Kapitel 3
Grundlagen
Im folgenden werden Grundlagen zum besseren Verständnis der in der Diplomarbeit verwendeten Techniken geschaffen. Bei ausreichend großem Vorwissen ist es möglich, dieses Kapitel zu überspringen.
3.1 Allgemeines
3.1.1 Interpolation nach Lagrange
Im weiteren Verlauf der Diplomarbeit wird es nötig sein anhand von Meßwerten, einen Folgewert näherungsweise im Voraus zu bestimmen. Mittels eines Interpolationsverfahrens ist es nun möglich, auf Basis von nicht äquidistanten Stützwerten (Meßwerten) eine Polynomfunktion zu entwickeln. Durch diese aufgestellte Funktion können beliebige andere Messungen näherungsweise vorausbestimmt werden. Das hier vorgestellte Verfahren wurde vom italienisch-französischen Mathematiker Joseph Louis Lagrange (1736-1813) entwickelt und später auch nach ihm benannt.
Lagrange setzt das gesuchte Polynomp(x),hier mit beispielsweise drei Stützpunkten, folgendermaßen fest:
p(x)y0L0(x) +y1L1(x) +y2L2(x)
mit den wie folgt de£nierten „Lagrangschen Grundpolynomen”:
Page 5
KAPITEL 3. GRUNDLAGEN5
Zähler dienFaktoren(x−xi)(füri. . . , k−1,k+ 1,n)enthalten. Es ist daher zu erwarten, dass die Interpolation mit(n + 1)Stützpunkten zu einem Polynomn-tenGrades führt, bei beispielsweise drei Punkten also zu einer Parabel. Dies kann aber nicht derartig verallgemeinert werden, da beispielsweise eine Interpolation mit den
fünf PunktenP0(−2/4),P1(−1/1),P2(0/0),P3(1/1),P4(2/4)zup(x)x2führen würde und nicht zu einem Polynom vierten Grades. Daher sagt man, dass das Interpolationspolynom maximaln-tenGrades ist. Eine schnelle Aussage über den Grad vonp(x),ohne das Polynom explizit auszurechnen, wird erst durch das Newtonsche Verfahren möglich.
Die allgemeine Formulierung des Lagrangeschen Interpolationsverfahrens zeigt, dass in jedem Fall, auch bei sehr vielen Stützpunkten, ein Polynomp(x)existiert, für das die Forderungp(xiyierfüllt ist. Sie zeigt aber auch, dass der Schreib- und Rechenauf-wand immer noch erheblich ist, da pro Stützpunkt ein Lagrangesches Grundpolynom anzugeben ist, das wiederum ausnFaktoren im Zähler und Nenner besteht. Außerdem ist eine völlig neue Rechnung erforderlich, wenn beispielsweise zu drei Punkten, durch die das Interpolationspolynom bereits bekannt ist, ein vierter hinzugefügt werden soll. Daher ist dieses Verfahren für praktische Anwendungen nicht immer geeignet.1
