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.
Inhaltsverzeichnis
2 Einleitung und Motivation
2.1 Einleitung
2.2 Motivation
3 Grundlagen
3.1 Allgemeines
3.1.1 Interpolation nach Lagrange
3.1.2 Three-Tier-Architektur
3.1.3 Two-Tier-Architektur
3.1.4 Demilitarisierte Zone
3.2 Protokolle
3.2.1 Internet Protocol
3.2.2 Transport Control Protocol .
3.2.3 Hypertext Transport Protocol .
3.2.4 Secure Socket Layer
3.3 Kommunikationstechniken
3.3.1 Parallel Virtual Maschine . .
3.3.2 Remote Method Invocation .
3.3.3 Common Object Request Broker Architekture .
3.3.4 Simple Object Access Protocol .
3.4 PHP
3.4.1 Allgemeines
3.4.2 Variablen-Handling .
3.5 Datenbanken
3.6 3D-Computergra£k
3.6.1 Modellierung
3.6.2 Animation
3.6.3 Rendering
4 Anforderung
4.1 IST-Analyse
4.1.1 Renderbus
4.1.2 RenderControl V.2
4.2 Zielbestimmung
4.2.1 Renderer
4.3 Zielgruppe
4.4 Einsatzgebiet
4.5 Funktionsumfang
4.5.1 GUI des Kunden . .
4.5.2 GUI des Administrator
4.5.3 Verteilanwendung . .
4.6 Hardwarespezi£kation
4.7 Betriebssystemspezi£kation .
5 Konzeption und Entwurf
5.1 Datenbankentwurf
5.1.1 Wahl des Datenbankbetriebsystems
5.1.2 De£nition der Datenbanktabellen .
5.1.3 De£nition der Relationen
5.2 verschiedene Client / Server Kommunikationsansätze .
5.2.1 Parallel Virtual Maschine
5.2.2 Remote Methode Invocation
5.2.3 Common Object Request Broker Architekture .
5.2.4 Fazit
5.3 gra£sche Benutzerober¤äche
5.3.1 Programmierung
5.3.2 Gestaltung
5.4 Sicherheitsanforderungen
5.4.1 Verschlüsselung
5.4.2 Authentisierung
5.4.3 Session-Management
5.4.4 Angriff eines authentisierten Benutzers
5.4.5 Angriffspunkt Datenbank
5.4.6 Sicherheitsrisiko FTP
5.4.7 Komplexitätsanalyse
5.5 Verteilalgorithmus
5.6 Abrechnungsmechanismen
6 Implementierung
6.1 Entwicklungsumgebung
6.2 Klassendiagramm
6.3 Probleme
6.3.1 Renderer
6.3.2 Überprüfung der tatsächlichen Existenz von gerenderten Frames
6.3.3 Anbindung von Renderknoten über das WAN
6.3.4 Parallelität der Auftragsvergabe
7 Fazit
A Glossar I
B Tabellenverzeichnis XIII
C Abbildungsverzeichnis XIV
D Literaturverzeichnis XV
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ür- zung gebraucht werden, werden bei der ersten Verwendung ausgeschrieben. Im wei- teren Verlauf nur noch als Abkürzung weiterverwendet. Aus Gründen der besseren Lesbarkeit kann es vorkommen, dass Abkürzungen doppelt beschrieben werden (bei- spielsweise.: 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.
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
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 Dienst- leister. 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 klei- ne Produktions£rma leisten, einen aufwändigen Film zu produzieren. Sie muss sich um die Unterhaltung der Computer, welche die Rechenkapazität zur Verfügung stel- len, keine Gedanken machen. Sie wendet sich einfach an den Dienstleister und dieser übernimmt das Rendern, den rechenintensiven Teil der Produktion eines computera- nimierten 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 ei- genen Administrationsaufwand möglichst minimieren kann. Zudem muss der Dienst- leister 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 geringst- mö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 Ar- beitsintensiven Prozessen auf mehrere Computer beschäftigt. Um ein Semesterbeleg rechtzeitig abliefern zu können, entstand die Idee, die ungenutze Rechenpower eines 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 Di- plomarbeit 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.
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 Polynom p(x), hier mit beispielsweise drei Stützpunkten, folgendermaßen fest:
Abbildung in dieser Leseprobe nicht enthalten
mit den wie folgt de£nierten „Lagrangschen Grundpolynomen”:
Abbildung in dieser Leseprobe nicht enthalten
Der Sinn dieser Festlegung wird offensichtlich, wenn man in diese Formeln die gegebenen Wertepaare einsetzt. Für die Stützpunkte x0 beispielsweise erhält man:
Abbildung in dieser Leseprobe nicht enthalten
Für das Interpolationspolynom p(x) an der Stelle x0 gilt daher:
Abbildung in dieser Leseprobe nicht enthalten
Analog hierzu ergeben sich die Funktionswerte für x1 und x2 wie folgt:
Abbildung in dieser Leseprobe nicht enthalten
Damit enthält das Polynom p(x) tatsächlich die Punkte P0, P1 und P2.
Allgemein, d.h. für (n + 1) Stützpunkte, lassen sich die Lagrangeschen Grundpolyno- me Lk (k = 0, 1, . . . , n) auf folgende Weise bestimmen: Der Zähler stellt ein Produkt aus den Faktoren (x−x0), (x−x1), . . . , (x−xn) mit Ausnahme des Faktors (x−xk) dar, im Nenner lauten die Faktoren (xk −x0), (xk −x1), . . . , (xk −xn) mit Ausnahme von (xk − xk). Dadurch nimmt Lk(x) an der Stelle xk den Wert 1 an; an allen anderen Stützstellen den Wert 0. Dieses Vorgehen lässt sich in folgende Formel fassen:
Abbildung in dieser Leseprobe nicht enthalten
Um das gesuchte Interpolationspolynom p(x) zu erhalten, wird die Summe aus den Produkten von yk und Lk(x) gebildet:
Abbildung in dieser Leseprobe nicht enthalten
Hierbei wird deutlich, dass die Grundpolynome Lk(x) vom Grad n sind, da sie im
Zähler die n Faktoren (x − xi) (für i = 0, 1, . . . , k − 1, k + 1, n) enthalten. Es ist daher zu erwarten, dass die Interpolation mit (n + 1) Stützpunkten zu einem Polynom n-ten Grades 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 Punkten P0(−2/4), P1(−1/1), P2(0/0), P3(1/1), P4(2/4) zu p(x) = x2führen würde und nicht zu einem Polynom vierten Grades. Daher sagt man, dass das Inter- polationspolynom maximal n-ten Grades ist. Eine schnelle Aussage über den Grad von p(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 Polynom p(x) existiert, für das die Forderung p(xi) = yi erfü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 aus n Faktoren 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
3.1.2 Three-Tier-Architektur
Die Three-Tier-Architektur wird in der Literatur auch in der Kurzbezeichnung 3-Tier geführt. Das englische Wort „Tier” bezeichnet eine Schicht. Demnach geht es also um drei Schichten. Im einzelnen sind diese:
Schicht 1 Datenschicht
Schicht 2 Logikschicht
Schicht 3 Präsentationsschicht
Die Datenschicht wird auch als Backend bezeichnet. Das Backend weiss, wie die zu verarbeitenden Daten physikalisch gespeichert sind. Die Schicht kennt also die Daten, kann mit ihnen aber nichts anfangen. Ein Beispiel wäre eine SQL-Datenbank.
Die Logikschicht ist auch als Middletier bekannt. Wie beide Bezeichnungen es be- reits andeuten, bedindet sich diese Schicht in der Mitte des Modells und in ihr läuft die eigentliche Programmintelligenz ab. So würde beispielsweise ein Programm zum Errechnen von Primzahlen in dieser Schicht die Berechnungen vornehmen.
Die Präsentationsschicht, auch als Frontend bezeichnet, dient der Darstellung der in der 2. Schicht gewonnenen Informationen. Ein simples Beispiel hierfür ist ein Browser. Er stellt die ihm übermittelten Daten einfach nur dar.
Die Three-Tier-Architektur zeichnet sich sowohl durch ihre Skalierbarkeit als auch durch die erhöhte Wartbarkeit der einzelnen Komponenten aus. So ist es beispiels- weise möglich, jede Schicht auf einem separaten Computer laufen zu lassen. Bei der Wartbarkeit wäre es beispielsweise denkbar, eine Datenbank durch eine andere zu er- setzen, ohne an der Anwendungslogik Änderungen vornehmen zu müssen.
3.1.3 Two-Tier-Architektur
Anders als die Three-Tier Architektur wird eine Anwendung in der Two-Tier-Architektur nur in zwei Schichten aufgeteilt. Sie arbeiten mit einem Server im Backend, auf dem die Datenbank gespeichert ist, und einer Benutzerschnittstelle, welche auf dem Client- Rechner liegt. Die Applikationslogik kann entweder auf dem Server oder auf dem Client-Rechner liegen.
3.1.4 Demilitarisierte Zone
In einer demilitarisierten Zone (DMZ) plazierte Rechner gehören zwar zum Local Area Network (LAN), können aber selber keine Verbindung zum LAN aufbauen. Allerdings sind Verbindungen vom Internet oder vom LAN zu einem Rechner in der DMZ erlaubt. Somit ist das übrige LAN bei einer eventuellen feindlichen Übernahme der in der DMZ plazierten Rechner nicht bedroht. Eine DMZ selber wird in der Regel durch ein Intrusion Detection System (IDS), quasi einem Einbruchsmelder für ein LAN, und einer Firewall geschützt.
3.2 Protokolle
Damit zwei oder mehr Partner miteinander kommunizieren können, benötigen sie Pro- tokolle. Als Protokolle bezeichnet man die Menge aller Regeln, die nötig sind, um eine kontrollierte und eindeutige Kommunikation zwischen den Teilnehmern zu ge- währleisten. Man stelle sich vor, dass sich drei Menschen aus verschiedenen Ländern der Erde treffen und Informationen austauschen wollen. Ohne Protokolle würden die- se drei Menschen wild durcheinander sprechen. Keiner würde den anderen verstehen. Haben sich alle drei auf ein Protokoll, quasi auf eine Sprache, geeinigt, klappt die Ver- ständigung untereinander gleich viel besser. Es ist geregelt, wer wann spricht und was passiert, wenn der eine den anderen nicht verstanden hat und so weiter.
Man könnte sagen, dass es in der Computerlandschaft fast genauso viele Protokol- le gibt wie unter den Menschen Sprachen. Nachdem die ersten Netzwerkprotokolle
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3.1: ISO/OSI-7-Schichten-Referenzmodell
entwickelt waren, hat man sich bemüht, die Kommunikation über Protokolle allge- meingültig darzustellen und zu de£nieren. Dazu gehört das weit verbreitete ISO/OSI- Referenzmodell. Alle in dem Modell beschriebenen Protokolle haben sehr unterschied- liche Ansprüche. Man hat sie daher, in Abhängigkeit von ihrem Abstraktionsgrad, in sieben Schichten unterteilt.
Die Schichten im Einzelnen:
- Die Physikalische Schicht überträgt die Daten über das physikalische Medium, das die Computer miteinander verbindet, also zum Beispiel ein Kabel oder eine Funkstrecke. Hier werden im Wesentlichen Nullen und Einsen übertragen.
- Die Leitungsschicht überträgt sogenannte Datenframes. Sie stellt eine fehlerfreie Verbindung zwischen den Teilnehmern sicher.
- Die Netzwerkschicht übernimmt die Weiterleitung, das Routing, der zu Paketen zusammengefassten Daten an den Empfänger.
- Aufgabe der Transportschicht ist es, die Daten der Sitzungsschicht in kleine- re Teile aufzuteilen und den Empfang der Pakete in der richtigen Reihenfolge sicherzustellen.
- Die Sitzungsschicht ist im Wesentlichen für das sogenannte Token Management und die Synchronisation bestimmter Abläufe zuständig.
- In der Darstellungsschicht werden, anders als in den darunter liegenden Schich- ten, strukturierte Daten, also Zahlen und Zeichen, übertragen .
- Die Anwendungsschicht stellt die Schnittstelle zum Benutzer dar und bietet Dienste, wie zum Beispiel die Übertragung von Dateien oder das Versenden von eMails, an.
Da im Allgemeinen nur die Protokolle der TCP/IP Familie benutzt werden, beschränkt sich der Autor bei den weiteren Betrachtungen auf diese Protokollfamilie. Häu£g £n-
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3.2: vereinfachtes 4-Ebenen-Modell
det sich für diese Familie eine auf vier Schichten reduzierte Darstellung des ISO/OSI Referenzmodelles:
Die TCP/IP Protokollfamilie wird sowohl in lokalen Netzen als auch im Internet verwendet. Alle Eigenarten des Transportweges werden auf der zweiten bzw. dritten Ebene ausgeglichen. Die Anwendungsprotokolle merken prinzipiell keinen Unterschied zwischen lokalen und globalen Verbindungen.
3.2.1 Internet Protocol
Das Internet Protocol (IP) de£niert den Transport von Datagrammen, der kleinsten Einheit für die Übertragung von Daten, über das Internet. Der Transport von einem Rechner zum anderen geschieht über das sogenannte Routing. Kann ein Empfänger nicht im lokalen Teilnetz gefunden werden, so wird versucht, den Empfänger über einen oder über mehrere dazwischenliegende Router zu erreichen. Dabei spielt es keine Rolle, welcher Weg beschritten wird. Es zählt einzig und allein die Tatsache, dass das Ziel gefunden wird.
Um Daten über ein Netzwerk transportieren zu können, ist eine Adressierung dieser Daten notwendig. Der Absender muss angeben können, an wen er die Daten senden möchte und der Empfänger muss erkennen können, von wem die Daten stammen. Die Adressierung erfolgt in TCP/IP Netzen in der Netzwerkschicht mit Hilfe einer 32-Bit langen IP-Adresse. Die IP-Adresse besteht aus einer Netzwerk-ID und einer Host-ID. Die Host-ID gibt die Bezeichnung des Computers innerhalb seines eigenen Netzwer- kes an und die Netzwerk-ID liefert die Bezeichnung des Netzwerkes. Alle innerhalb eines Verbundes von Netzwerken sichtbaren Adressen müssen eindeutig sein. Es darf also nicht zweimal dieselbe Host-ID innerhalb eines Netzes geben. Sind mehrere Netz- werke miteinander verbunden, wie es zum Beispiel beim Internet der Fall ist, so müs- sen auch die Netzwerk-ID’s innerhalb des Verbundes eindeutig sein. Auf den genauen Aufbau der IP-Adressen und deren Unterteilung in verschiedene Klassen möchte der Autor nicht weiter eingehen.
Die Benutzung von IP-Adressen durch den Computer mag für diesen einfach sein. Jedoch ist die Art und Weise der Adressierung über Zahlen für den Menschen alles andere als leicht. Daher wurde eine Zuordnung von IP-Adressen zu leichter merkbaren Namen unter der Bezeichnung Domain Name System (DNS) eingeführt. Das IP bietet selber keine eigene Fehlerkorrektur. Für den Ausgleich von Fehlern sind andere Schichten, wie zum Beispiel die Transportschicht, zuständig.
3.2.2 Transport Control Protocol
Das Transport Control Protocol (TCP) ist ein verbindungsorientiertes Protokoll, das auf der Basis von IP eine fehlerfreie Punkt-zu-Punkt-Verbindung realisiert. Das heißt, dass ein eintreffendes Datenpaket jeweils auf Vollständigkeit kontrolliert und der Emp- fang beim Sender bestätigt wird. Kommt ein Datenpaket fehlerhaft oder gar nicht an, so wird der Sender veranlasst, das entsprechende Paket noch einmal zu senden und zwar solange, bis das Paket vollständig eingetroffen ist. Ein weiteres Protokoll oberhalb von IP ist das User Datagram Protocol (UDP). Anders als TCP ist UDP ein verbindungs- loses Protokoll. Die Anwendung selber muss für den fehlerfreien und folgerichtigen Empfang der Datenpakete aufkommen. Per UDP versandte Datenpakete werden also nach dem Send-And-Forget-Prinzip versandt.
Vergleichend kann man feststellen, dass TCP also denkbar ungeeignet für Dienste ist, bei denen es nicht auf Vollständigkeit, dafür aber auf Kontinuität, ankommt, wie z.B. Video-Streaming. Ein einzelnes fehlendes Datenpaket fällt bei der Darstellung von Vi- deoströmen nicht ins Gewicht. Genau diese Eigenschaften kann UDP abdecken. Geht es jedoch um die Übertragung von Dateien, so ist eine absolut zuverlässige Übertra- gung unerlässlich. Würde ein Datenpaket nicht ankommen und auch kein Ersatz ange- fordert werden, so wäre die Datei auf der Empfängerseite nicht mehr zu gebrauchen. Ein fehlendes oder fehlerhaftes Bit reicht dafür schon aus. Hier liegen die Stärken von TCP.
3.2.3 Hypertext Transport Protocol
Das Hypertext Transport Protocol (HTTP) ist die gemeinsame Sprache von WWW- Servern und -Clients, über die sie Dokumente austauschen und sich sonstige Nachrichten zuschicken. Über dieses Protokoll sollen Daten beliebigen Typs, zum Beispiel Text, Gra£k, Gra£ksequenzen oder Musik transportiert werden.
Bei der Konzeption des HTTP-Protokolls galt es, zwei Ansätze miteinander zu ver- knüpfen. Zum einen sollte das Ausliefern von Dokumenten per HTTP für die Server- maschine nur eine minimale Belastung darstellen. Dies erreicht das Protokoll durch seine Zustandslosigkeit. Das bedeutet: Nach dem Übermitteln einer Datei an den WWW- Client geht der Server wieder in seinen Grundzustand zurück. Es gibt keine langandau- ernden „HTTP-Sitzungen”, bei denen sich der Benutzer auf einem WWW-Server ein- loggt, durch das dort be£ndliche Informationsangebot surft und den Server anschlie- ßend wieder verlässt. Vielmehr wird für jedes einzelne zu übertragende Dokument ei- ne separate Verbindung aufgebaut und nach der Datenübertragung wieder geschlossen. Nach dem Senden einer HTML-Datei, einer Inline-Gra£k oder einer sonstigen Datei geht der Server wieder in seinen Grundzustand zurück. Jede nachfolgende Anfrage an den WWW-Server hat keinen Bezug zur vorhergehenden Anfrage. Diese Zustands- losigkeit des Protokolls hat jedoch zur Folge, dass beispielsweise bei einem HTML- Dokument mit mehreren Inline-Bildern für jedes Bild eine neue Verbindung aufge- baut werden muss. Da der Verbindungsaufbau durchaus im Sekundenbereich liegen kann, widerspricht dies dem zweiten Ansatz der Konzeption des HTTP Protokolls - der Geschwindigkeit. Um Geschwindigkeit dennoch garantieren zu können, soll es möglich sein, TCP-Verbindungen wiederverwenden zu können. Dabei gibt der Server eine bestehende TCP-Verbindung zum Client nicht sofort nach jeder Transaktion auf, sondern wickelt mögliche weitere Anforderungen desselben Clients über diese Verbin- dung ab. Das setzt natürlich voraus, dass der Client diese Funktion unterstützt. Durch diese Maßnahme sparen sich die Kommunikationspartner den Aufbau von neuen TCP- Verbindungen für jedes einzelne Dokument.2
Abbildung in dieser Leseprobe nicht enthalten3
Abbildung 3.1: Secure Socket Layer
3.2.4 Secure Socket Layer
Mit TCP/IP war der Wunsch nach sicheren Verbindungen im Sinne von Datensicherheit nicht zu verwirklichen. Jedoch ohne TCP/IP gibt es kein Internet. Die Firma Netscape löste das Problem auf folgende elegante Weise: Die Entwickler erweiterten TCP/IP um zwei weitere Schichten
- Secure Socket Layer Record Protocol
- Secure Socket Layer Handshake Protocol.
Sie liegen funktional zwischen dem Aufgabenbereich von TCP/IP und den Anwen- dungen. Diese beiden Schichten liegen bildlich betrachtet unmittelbar aufeinander und werden darum von einigen Autoren auch als eine einzige Schicht angesprochen. Bei- de sind für angrenzende Schichten transparent: Weder die Anwendung (beispielswei- se ein Browser), noch die unter dem Secure Socket Layer (SSL) Protokoll liegende Transportschicht bemerken das Wirken des SLL-Protokolls. Das heißt, SSL erfordert weder massive Änderungen vorhandener Anwendungen noch neue Transportprotokol- le. Während einer sicheren Verbindung kommunizieren die beteiligten Rechner aus- schließlich über den Mechanismus, der von SSL bereit gestellt wird. Steht die sichere Verbindung nicht zur Verfügung, schaltet sich das SSL-Protokoll gleichsam aus.
Der Verbindungsaufbau läuft in vier Schritten ab4:
1. In der sogenannten „HELLO-Phase” baut der Client eine Verbindung zum Ser- ver auf und teilt ihm mit, welche Kryptographie-Algorithmen er unterstützt.
2. Der Server wählt daraus ein Public-Key-, ein Privat-Key- und ein Hash-Verfahren aus und teilt sie dem Client mit. Gleichzeitig sendet der Server ein Zerti£kat, das unter anderem den öffentlichen Schlüssel des Servers enthält. (Mit Hilfe des Zer- ti£kats kann der Client überprüfen, ob die Antwort tatsächlich vom gewünschten Server stammt).
3. Der Client generiert einen Sitzungsschlüssel (Session key) für einen Datenaus- tausch per Private-Key-Verfahren. Aus Geschwindigkeitsgründen werden stan- dardmäßig symmetrische Verfahren verwendet. Der dazu notwendige Schlüsse- laustausch wird durch Verschlüsselung mit den in den Zerti£katen enthaltenen öffentlichen Schlüsseln geschützt. Diesen chiffrierten Schlüssel schickt der Cli- ent an den Server.
4. In der abschließenden Authenti£zierungsphase authenti£ziert der Client den Ser- ver, indem er ihm eine Reihe von mit dem Sitzungsschlüssel chiffrierten zufälligen Testnachrichten schickt, die der Server nur dann korrekt dechiffrieren und bestätigen kann, wenn es sich um den „echten” Server handelt. In einem optionalen Schritt kann der Server auf vergleichbare Weise den Client authenti£zieren. Die Client-Authenti£kation funktioniert nur dann, wenn der Client über ein of£ziell registriertes Zerti£kat verfügt.
Der Ablauf einer mittels SSL geschützten Verbindung soll am Beispiel des Secure HTTP (HTTPS) beschrieben werden. Durch die Initialisierung einer Verbindung über das HTTPS Protokoll (beispielsweise https://www.ud.com) wird der Browser veran- lasst vom angesprochenen Server ein Zerti£kat und einen öffentlichen Schlüssel ab- zufordern. Dieser Schlüssel wird zusammen mit einer Prüfsumme und einer ID an den Browser zurückgemeldet. Diese Informationen werden von einigen wenigen Zer- ti£zierungs£rmen errechnet. Die bekannteste Firma ist VeriSign5. Der Browser prüft anhand der übermittelten Daten, ob er wirklich mit dem Server verbunden ist, der in der URL angegeben ist. In der folgenden Phase verständigen sich die beiden Rechner auf einen symmetrischen Schlüssel (Session Key). Da diese Absprache in asymmetri- scher Verschlüsselung vollzogen wird, ist die Sicherheit gegeben. Der Browser schickt dem Server vor dem Beginn des eigentlichen Datenaustausches einige Testnachrich- ten, die der Server nur beantworten kann, wenn es wirklich der Server ist, der er zu sein vorgibt.
3.3 Kommunikationstechniken
3.3.1 Parallel Virtual Maschine
Bei der Parallel Virtual Maschine (PVM) handelt es sich um ein frei verfügbares Message-Passing-System, welches den Programmierer in die Lage versetzt, ein heterogenes Netzwerk als einen zusammenhängenden virtuellen Parallelrechner erscheinen zu lassen. Das PVM-Paket ist für alle UNIX und Windows-Systeme frei erhältlich. PVM selbst unterstützt alle TCP-basierten Rechnernetze wie FDDI, ATM und Ethernet. Daraus ergibt sich, dass die angeschlossenen Hosts über vollkommen verschiedenen Netzen miteinander verbunden sein können. Die PVM eigenen Bibliotheken stehen sowohl für C, C++ als auch für Fortran zur Verfügung.
Eine Berechnungseinheit im Programm wird in PVM als Task bezeichnet. Diese Tasks haben die Möglichkeit zur Kommunikation und zur Synchronisation. Auf diese Wei- se können die auf den einzelnen Hosts laufenden Tasks miteinander kooperieren, die Anwendungen können parallel ablaufen. Die erwähnte Heterogenität wird auf der Anwendungs-, Maschinen- und Netzwerkebene des ISO/OSI Referenz Modells un- terstützt. Das heißt, dass sich PVM um eventuell nötige Datenkonvertierung kümmert (big-endian / little-endian). Die Tasks können so die Besonderheiten der einzelnen Ar- chitekturen optimal ausnutzen.
Eine mit PVM programmierte Applikation kann nun in p-Prozesse unterteilt werden. Es ist sinnvoll, die zugehörige Client-Applikation auf p-physikalischen Prozessoren zu starten, so dass auf jedem Prozessor ein Prozess läuft. Stehen PVM weniger als p Prozessoren zur Verfügung, so kann es vorkommen, dass ein Prozessor mehr als einen Prozess zu bearbeiten hat. Welche Prozessoren dem PVM-Netzwerk beiwohnen, kann man durch ein sogenanntes HOSTFILE festlegen. Jedoch ist es auch möglich, im laufenden Betrieb Prozessoren zu einem bestehenden PVM-Netz hinzuschalten.
3.3.2 Remote Method Invocation Allgemein
Die Programmiersprache Java bietet zwar selbst schon grundlegende Fähigkeiten der Netzwerkkommunikation, jedoch beschränken sich diese auf reine socketbasierte Kom- munikation. Allerdings ist die Implementierung dieser Fähigkeiten nur auf ein Mini- mum beschränkt. So ist es zum Beispiel nicht möglich, ohne großen Aufwand ein erzeugtes Objekt auf einem anderen Computer zu verarbeiten. Diesen Mangel behebt die Erweiterung Java RMI (Remote Methode Invocation). Seit dem JDK 1.1 ist diese Erweiterung fester Bestandteil der Programmiersprache Java. Bei der Entwicklung von RMI galt es folgende Punkte zu berücksichtigen:6
- die Benutzung von Remote-Objekten über unterschiedliche Virtual Maschines (VM) hinweg
- die Unterstützung von Callbacks vom Server zum Applet
- die Integration des Modells der verteilten Objekte in Java unter Beibehaltung der Objektsemantik Javas
- die Unterschiede zwischen den Modellen der lokalen beziehungsweise der ver- teilten Objekte aufzuzeigen
- die Entwicklung von zuverlässigen verteilten Systemen so weit wie möglich zu erleichtern
- die durch die Java Laufzeit-Umgebung zur Verfügung gestellte Typ-Sicherheit beizubehalten
- verschiedene Referenzierungen der Remote-Objekte
- die sichere Java-Umgebung (Security Manager, Class Loader)
Die eigentliche Kommunikation bei der durch RMI etablierten Verbindung ist für den Programmierer fast vollständig unsichtbar. Der Programmierer muss sich bei der Implementierung von Funktionen keine Gedanken mehr um den reinen Kommunikationsweg machen. Er kann einfach auf einem Rechner auf das von einem anderen Rechner zur Verfügung gestellte Remoteobjekt zugreifen.
Die Kommunikation im Detail
Zunächst werden in einem Remote-Interface eine oder mehrer Methoden de£niert, die als aufrufbare Dienste anderen Computern zur Verfügung gestellt werden sollen. Ei- ne Serverklasse implementiert das Interface und erzeugt eine oder mehrer Instanzen, die als Remote-Objekt bezeichnet werden. Die Remote-Objekte werden daraufhin bei einem Namensdienst, zum Beispiel der zum RMI-Paket mitgelieferten RMI-Registry, angemeldet. Sobald sie registriert wurden, können sie von potentiellen Client-Anwendungen abgefragt werden. Wird nun ein Remote-Objekt über einen Namensdienst abgefragt,
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3.2: RMI - Kommunikation zwischen Client und Server
so erhält die Client-Anwendung ein Stub-Objekt. Ein Stub ist eine Klasse, die - wie das implementierende Remote-Objekt - das Remote-Interface implementiert und daher für die Clientanwendung als Platzhalter für den Zugriff auf das Remote-Objekt dient.
Abbildung 3.2 zeigt wie der Stub über eine Netzwerkverbindung mit dem als Skeleton bezeichneten Gegenstück auf der Server-Seite kommuniziert. Das Skeleton kennt indes das tatsächliche Applikationsobjekt, leitet die Anfrage des Stubs an dieses weiter und gibt den Rückgabewert an ihn zurück. Die Details der Kommunikation zwischen Stub und Skeleton bleiben für den Programmierer und den Anwender verborgen.7
3.3.3 Common Object Request Broker Architekture
Die Common Object Request Broker Architecture, kurz CORBA, ist ein Konzept für eine Middleware, welche von der Object Management Group (OMG), einer Vereinigung von über 800 Firmen, ins Leben gerufen wurde, um einen eiheitlichen Standard der Kommunikation und des Datenaustausches zu schaffen, in dessen Mittelpunkt die Sprach- und Plattformunabhängigkeit steht. Wie RMI benutzt auch CORBA das Prinzip der lokalen Transparenz, das heißt die Objektaufrufe von nicht-lokalen Objekten sollen sich nicht von denen ihrer lokalen Gegenstücke unterscheiden. Im Gegensatz zu RMI ist CORBA jedoch sprachunabhängig. Es können damit Server- und Clientanwendungen in unterschiedlichen Sprachen erstellt werden.
CORBA de£niert sich aus drei Bestandteilen, dem Object Request Broker (ORB), den Object Services (CORBA Services) und den Common Facilities (CORBA Facilities). Der Object Request Broker ist als ein Nachrichtenbus zu verstehen, mit dessen Hilfe die erzeugten CORBA-Objekte miteinander kommunizieren können. Er arbeitet zum einen als Informationsverteiler, aber auch als Konverter für Implementierungssprachen und Datentypen. Die Object Services stellen grundlegende Dienste, wie zum Beispiel den Namensdienst, zur Verfügung. Common Facilities stellen erweiterte Dienste, wie zum Beispiel Drucken, zur Verfügung.
3.3.4 Simple Object Access Protocol
Das Simple Object Access Protocol (SOAP) ist ein Protokoll, das XML als Codierung verwendet und einen Mechanismus zum Austausch von Informationen zwischen Computern in einer dezentralisierten Umgebung erlaubt. Es de£niert eine Semantik durch einen modularen Aufbau und erlaubt Daten innerhalb dieser Module zu kodieren. Aufgrund dieser Eigenschaften kann SOAP von verschiedenen Systemen eingesetzt werden. Mögliche Einsatzgebiete sind der Austausch von Nachrichten und der Aufruf entfernter Prozeduren (remote procedure calls).
SOAP besteht aus folgenden drei Teilen:
- SOAP envelope: de£niert, was in einer Nachricht stehen kann, wer es verwenden sollte und ob die Nachricht optional oder verp¤ichtend ist
-SOAP encoding: de£niert einen Serialisierungsmechanismus, der für den Aus- tausch instanziierter Anwendungstypen verwendet werden kann
-SOAP RPC representation: de£niert, wie entfernte Prozeduren aufgerufen wer- den und wie mit der Antwort umgegangen wird.
Diese drei Teile beschreiben zusammen SOAP, sind jedoch so modular aufgebaut, dass jeder Teil getrennt voneinander de£niert ist.8
3.4 PHP
3.4.1 Allgemeines
Eine weitere Anforderung der zu entwickelnden Software ist ein gra£sches Benut- zerinterface. Da es ohne großen Aufwand von jedem Punkt der Welt aus benutzt wer- den soll, bietet sich zunächst HTML an. Der Benutzer greift dabei über einen Browser auf eine einzurichtende Internetseite zu. Diese stellt das Benutzerinterface zur Verfügung. Der Nutzer soll über dieses Eingaben tätigen und sich stets über den Fortgang seiner Eingaben informieren können. Das hat zur Folge, dass man auf dynamisch generierte Internetseiten angewiesen ist, also Internetseiten, welche anhand von Bedingungen und Datenquellen zur Laufzeit generiert werden. Für diese Aufgabe kämen verschiedene Programmiersprachen in Frage. PHP ist für die verwendete Datenquelle eine sehr geeignete Sprache, welche sich gerade durch ihre einfach zu erlernende Syntax bei anhaltend guter Performance überzeugt.
3.4.2 Variablen-Handling
Ein sicher kon£guriertes System setzt voraus, dass die einem PHP-Skript übergebenen Daten in der richtigen Reihenfolge bearbeitet werden. So soll folgende Reihenfolge gelten: GET, POST, SESSION. Das heißt, per HTTP-GET übergebene Variablen wer- den von gleich bezeichneten per HTTP-POST übertragenen Variablen überschrieben, welche wiederum von SESSION-Variablen überschrieben werden können. Folgendes Beispiel soll die Reihenfolge verdeutlichen:
Abbildung in dieser Leseprobe nicht enthalten
Unter der oben stehenden Voraussetzung würde nach Betätigen des Submit-Button nach „Testvariable:” das Wort „sess” stehen. Darüber hinaus ist es jedoch nicht mehr zeitgemäß, übergebene Variablen wie in dem gezeigten Beispiel global abzufragen. Vielmehr werden die alternativ zur Verfügung stehenden Arrays HTTP_GET_VARS, HTTP_POST_VARS und HTTP_SESSION_VARS zur Auswertung übergebener Va- riablen genutzt. So wäre für das obige Beispiel folgende zusätzliche Zeile denkbar:
Abbildung in dieser Leseprobe nicht enthalten
Hinter „Testvariable-GET” würde dann nach Betätigen des Submit-Button das Wort „get” stehen.
3.5 Datenbanken
Daten in einer Datenbank können nur von einem Datenbankbetriebssystem (DBBS) eingefügt, gelesen, geändert oder gelöscht werden. Nach Codd9muss ein DBBS min- destens die Operationen Selektion, Projektion und Join zur Verfügung stellen. Die Daten werden vom DBBS auf einem persistenten Speichermedium zur Weiterverar- beitung abgelegt. Intern verwaltet das DBBS die Daten in Tabellen. Diese Tabellen können zueinander in Beziehung stehen. Die Art und Weise, wie weit die Daten in der Tabelle strukturiert wurden, beschreibt den Grad der Normalisierung einer Tabelle. Man unterscheidet dabei fünf Formen. Es soll exemplarisch nur kurz auf die erste und die fünfte kurz eingegangen werden. Eine Datenbank ist in der ersten Normalform, wenn alle Attribute atomar sind. Sind bei Existenz einer mehrwertigen Abhängigkeit alle Attribute eines Tupels funktional abhängig, so spricht man von einer Datenbank in der fünften Normalform.
3.6 3D-Computergra£k
Die Bedeutung der 3D-Computergra£k nimmt immer mehr zu. Die Film- und Fernsehindustrie kommt ebenso wenig ohne sie aus wie die Bauindustrie. Nahezu alle Architekten entwerfen ihre Bauwerke nur noch am Computer, ebenso wie fast alle Action£lme aus der Traumfabrik Hollywood ohne 3D-Computergra£k nicht ihren Erfolg haben würden. Was den Einsatz in der Filmindustrie angeht, sei an Kassenschlager wie „Terminator 2” oder „Jurassic Park” erinnert. In diesem Zweig ist gerade ein neuer Trend zu erkennen: komplett am Computer entstandene Filme in Spiel£lmlänge. Beispiele hierfür sind „Toy Story” und „Die Monster AG”.
Der Begriff 3D-Computergra£k ist ein sehr weit gefasster Begriff. Er umfasst im Mi- nimum die Teilgebiete Modellierung, Animation und Rendering, wobei jedoch Mo- dellierung und Rendering den Prozess der Modellierung voraussetzen. Für alle Teil- bereiche gibt es spezielle Software. Das schließt nicht aus, dass manche Teilbereiche zu einem Softwarepakete zusammengefasst wurden. Beispiele für professionelle Pro- gramme der 3D-Computergra£k sind Alias Wavefront Maya und Softimage XSI.
3.6.1 Modellierung
Modellierung ist der Prozess der Beschreibung, Erzeugung und Modi£kation von 3D- Modellen. Ein dreidimensionales Modell ist wiederum die rechnerinterne Darstellung eines dreidimensionalen Objektes, die die Geometrie dieses Objektes vollständig und widerspruchsfrei beschreibt und für Computer gut interpretierbar und weiterverarbeitbar ist.10Im allgemeinen Sprachgebrauch handelt es sich bei dreidimensionalen Modellen um rechnerinterne Darstellungen, bei denen Punkte, Kurven, Flächen und Volumina direkt im dreidimensionalen Raum beschrieben werden.
3.6.2 Animation
Unter animieren versteht man zunächst „etwas beleben”. Die Animation ist demzufolge das Bewegen eines Objektes, welches sich aus eigener Energie nicht bewegen könnte. Die Animation beschreibt also immer eine Bewegung, das heißt also, die Bewegung eines Objektes im 2D / 3D Raum in Bezug zur Zeit.
Es gibt verschiedene Formen der Animation. Es soll im folgenden nur auf die Anima- tion von 3D-Computermodellen eingegangen werden. Da diese immer im Zusammen- hang zum Film steht, ist eine weitere Betrachtung notwendig: Um für das menschliche Auge eine durchgängige, ruckelfreie Bewegung zu simulieren, müssen dem Auge min- destens 24 Einzelbilder in einer Sekunde präsentiert werden. Erst ab diesem Wert ist aufgrund der Erkennungsträgheit des Auges der Bildwechsel nicht mehr zu erkennen. Die Anzahl der in einer Sekunde dargestellten Einzelbilder wird in der Literatur meist mit dem englischen „Frames per Second” bzw. mit der Abkürzung „FPS” angegeben.
Um etwas animieren zu können, muss der Animateur direkt oder indirekt wissen, wie er das Objekt von einem Punkt zum anderen bewegen soll. Dabei gibt es zwei ver- schiedene Ansätze. Entweder er legt den Ablauf der Bewegung fest, indem er durch Setzen von Schlüsselpositionen die zwischenliegenden Bewegungsschritte vom Ani- mationsprogramm bestimmen lässt oder er entwirft den Bewegungsablauf auf Basis von Algorithmen und Gesetzen. Beide Verfahren £nden in der Computeranimation ih- re Anwendung.
3.6.3 Rendering
Im Titel dieser Arbeit kommt das Wort Renderprozess vor. Es soll zunächst geklärt werden, um was es sich beim Begriff Rendering handelt. Aus dem englischen über- setzt, bedeutet es so viel wie „Übersetzung” bzw. „Übertragung”. In der 3D-Computergra£k versteht man darunter die optische Aufwertung eines dreidimensionalen Modells mittels computerunterstützter Prozesse / Algorithmen. Es gibt zwei wesentliche Verfahren des Rendering: Raytracing und Radiosity.
Raytracing
Raytracing ist die englische Bezeichnung für „Lichtstrahlverfolgung”. Es simuliert den Prozess der Lichtausbreitung und arbeitet dabei nach den Gesetzen für ideale Spiegelung und Brechung. Daher ist dieses Verfahren für Szenen mit besonders ho- hem Anteil an spiegelnden und transparenten Flächen geeignet. Die Grundidee besagt, die Lichtstrahlen auf ihrem Weg bis zum Auge zu verfolgen. Da jedoch nur weni- ge Lichtstrahlen das Auge erreichen, wird das Verfahren umgekehrt (Reziprozität der Re¤exion). Man sendet durch jeden Bildpunkt (Pixel) des betrachtenden Auges einen vom Augpunkt ausgehenden Strahl in die Szene. Trifft dieser Sehstrahl auf ein Objekt, so wird das lokale Beleuchtungsmodell des Auftrittpunktes berechnet. Im Anschluss daran werden zwei neue erzeugt: der re¤ektierte und der transmittierte (gebrochene) Sehstrahl. Der Leuchtdichtebeitrag dieser beiden Strahlen wird rekursiv berechnet, so- lange
- keine Lichtquelle getroffen wurde
-die auf dem Sehstrahl transportierte Lichtenergie stark genug ist
-der Sehstrahl sich noch in der Szene be£ndet.
Um den Rechenaufwand jedoch in Grenzen zu halten, wird dennoch eine Rekursions- tiefe festgelegt. Um Schatten zu berechnen, werden vom Auftreffpunkt des Sehstrahls sogenannte Schattenstrahlen zu den Lichtquellen der Szene gesendet. Nur wenn kein undurchsichtiges Objekt zwischen einer Lichtquelle und dem Auftreffpunkt liegt, trägt sie zur Beleuchtung bei.
Radiosity
Unter Radiosity versteht man ein Visualisierungsverfahren, welches zunächst in einem sogenannten "Beleuchtungsmodell" die physikalischen Verhältnisse eines dreidimen- sionalen Raumes unter Verwendung eines energetisch abgeschlossenen Strahlungsmo- dells exakt nachbildet, um sie im zweiten Schritt zu berechnen. Das Ergebnis ist eine fotorealistische Darstellung mit diffuser Beleuchtung und diffusen Schlagschatten.
Radiosity ist also ein Berechnungsverfahren für photorealistische Bilder, bei dem die indirekte Beleuchtung berücksichtigt wird.
[...]
1[DD75, S. 119]
2vgl. [TRH96]
3siehe auch [RJJ+97]
4vgl. [APP96]
5http://www.verisign.com
6Aus: [Sun02]
7[EK01]
8[DBDEGK+00]
9[AG00, Quellenübernahme]
10aus [IND+02]
- Citar trabajo
- Diplom Informatiker (FH) Daniel Wedewardt (Autor), 2002, Entwicklung eines objektorientierten Client-Server-Systems zur Verteilung von Renderprozessen unter besonderer Berücksichtigung von Userinteraktionen und Abrechnungsmechanismen, Múnich, GRIN Verlag, https://www.grin.com/document/59584
-
-
-
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X.