E.1.2 Netzwerktypen - Institut für Verteilte Systeme

Transcription

E.
Verteilung im Netz
E.1.1 Inhaltsübersicht:
Einführung
Verteilte Informationen
Algorithmen
„The Internet sucks“
Sicherheit
C-1
Virtuelle Präsenz, Winter 2010, P. Schulthess, ©VS Informatik, Ulm
E.1.2 Netzwerktypen
LAN
hohe & feste Bandbreite
kurze Latenzen mit geringer Varianz
hohe Ausfallsicherheit
Internet
niedrigere Bandbreite, grössere Paketlaufzeiten,
größere Latenz durch Routing und Entfernung,
hohe Varianz von Bandbreite und Latenz (ping)
Paketverlust nicht ungewöhnlich
C-2
E.2.
Internet Protocol Format
Internet Protocol RFC 791 1981
Vermittlungsschicht nach OSI Modell
Zuständig für Weglenkung der Pakete
Maximale Paketgröße von 64 Kbyte.
IP Header:
IHL spezifiziert Länge in 32-bit Worten,
Protokollfeld für zuständigen Dienst,
TTL = „time to live“, Lebenszeit in Hops,
Type of Service (Diffserv ...).
Fragmentierung:
erlaubt Pufferökonomie in den Subnetzen,
Ethernet erlaubt zum Beispiel maximal 1500 Bytes,
Fragment-Offset bei zerteilten Datenpaketen,
Identifikation zur Fragmentzuordnung.
C-3
E.3.
Latenz
Paketlaufzeit:
typischerweise Hin- & Rückweg zwischen 2 Knoten,
elektrische Signallaufzeit (~0.7 * Lichtgeschwindigkeit),
Store- & Forward-Delay (abhängig von Bitrate, Anz. Hops),
Processing und Warteschlangen.
Am Beispiel Ulm-Hamburg Ulm:
2000 km / (0.7 * 200'000 km/sec) = 14 msec
300 Bits / (300 Kbits/sec) = 1 msec
26 * 0.5 msec = 13 msec
Store & Forward-Verzögerung,
Paket vollständig empfangen vor der Weiterleitung,
entsteht in jedem Knotenrechner/Router,
Einfluss von Paketlänge & Datenrate.
Ausbreitungsgeschwindigkeit hier ca. 50%.
Asymmetrischer DSL-Anschluss.
C-4
E.3.1 Laufzeittests mit „ping“, „tracert“ etc.
Tracing route
1
4 ms
4
2 12 ms 11
3 22 ms 15
4 13 ms 16
5 16 ms 15
6 16 ms 16
7 27 ms 27
8 54 ms 46
9 34 ms 31
10 31 ms 31
11 31 ms 31
12 32 ms 34
13 31 ms 31
to
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
rzaixsrv5.rrz.uni-hamburg.de [134.100.32.72]
3 ms Hexcore-Peter [192.168.2.1]
11 ms dslb-084-057-128-001.pools.arcor-ip.net [84.57.128.1]
14 ms 88.79.15.149
12 ms 92.79.212.229
14 ms ffm-145-254-19-198.arcor-ip.net [145.254.19.198]
15 ms zr-fra1-ge0-2-0-4.x-win.dfn.de [188.1.56.21]
28 ms zr-han1-te0-0-0-1.x-win.dfn.de [188.1.145.214]
55 ms xr-bre1-te1-1.x-win.dfn.de [188.1.144.86]
31 ms xr-ham1-te1-1.x-win.dfn.de [188.1.144.89]
31 ms gr-ham1-te1-1.x-win.dfn.de [188.1.145.226]
31 ms nixgate-te-xwin.rrz.uni-hamburg.de [188.1.231.82]
31 ms crrz2-te-nixgat.rrz.uni-hamburg.de [134.100.254.173]
32 ms rzaixsrv5.rrz.uni-hamburg.de [134.100.32.72]
Tracing route
1
7 ms
5
2 11 ms 11
3 21 ms 11
4 10 ms 11
5 19 ms 19
6 17 ms 18
7 27 ms 24
8 21 ms 22
9 74 ms 22
10 23 ms 23
11 148 ms 147
12 152 ms 149
13 151 ms 148
14 144 ms 146
15 148 ms 154
to
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
adobe.com [192.150.16.117]
4 ms Hexcore-Peter [192.168.2.1]
11 ms dslb-084-057-128-001.pools.arcor-ip.net [84.57.128.1]
20 ms 88.79.15.145
13 ms 92.79.213.117
20 ms 92.79.200.146
18 ms 212.162.17.21
24 ms ae-34-52.ebr2.Dusseldorf1.Level3.net [4.69.139.33]
21 ms ae-46-46.ebr1.Amsterdam1.Level3.net [4.69.143.201]
22 ms ae-1-51.edge4.Amsterdam1.Level3.net [4.69.139.138]
22 ms acr1-so-3-0-0.Amsterdamamx.savvis.net [208.174.49.1]
150 ms cr2-tengig0-7-0-0.dallas.savvis.net [204.70.196.214]
149 ms hr1-tengig-12-0-0.dallasda1.savvis.net [204.70.203.58]
152 ms 216.39.66.26
159 ms 192.150.16.6
165 ms 192.150.16.117
C-5
E.4.
User Datagram Protocol
Einfachstes Protokoll:
Ungesicherte Übertragung einzelner IP-Pakete,
keine Garantien für Reihenfolge,
keine Garantien für Zustellung,
sehr schlank & sehr schnell,
paketorientierter Ansatz.
Übertragung zwischen Ports:
Dienste über „Well known Ports“ bereitstellen,
viele Ports pro Rechner möglich
16-Bit Portnummern ...
UDP-Header:
C-6
E.5.
Transmission Control Protocol
Bytestrom-orientiertes Protokoll:
garantierte Ablieferung und Reihenfolge der Daten,
intern wird Datenstrom in IP-Pakete aufgebrochen,
evtl. Fragmentierung innerhalb IP.
Sliding window protocol:
komplexer Mechanismus zur Fehlerbehandlung,
Empfänger bestätigt empfangenes Paket,
stark schwankende Datenrate & Latenz,
behelfsmässige Flusskontrolle.
TCP Header:
Port Nummern,
Vorwärts-Sequenznummer
Bestätigungssequenznummer,
Sende- und Empfangsport,
...
C-7
E.5.1 Nagle's Algorithm:
Datenbündelung:
ist Nagle's Algorithmus aktiv, so
wartet TCP mit dem versenden von
einzelnen Daten bis zu einem
TimeOut t (z.B. 500ms) um evtl. so
mehr Daten mit nur einem Header
versenden zu können.
Wichtig bei zeichenorientiertem
Terminalbetrieb (Telnet).
Delayed Acknowledge:
verzögert Bestätigungen und hofft
darauf, die Bestätigungen Huckepack
mit ausgehenden Daten versenden zu
können.
C-8
E.6.
Sockets
Abstraktion des Netzwerkes:
Behandlung analog zu Dateisystem,
öffnen, schliessen, lesen, schreiben.
Kommunikationsendpunkte für den Programmierer:
werden an einen Port gebunden (bind),
verwendbar für eine Vielzahl von Protokollen
Unterscheidung zwischen TCP & UDP Sockets
C-9
E.6.1 UDP Sockets
Broadcast möglich (im LAN).
Datagramm-Betrieb:
Schreiben & Lesen in Paketgranularität,
Fragmentierung innerhalb IP,
Verbindungsaufbau entfällt.
OS Nutzung:
bindet sich an definierten Port
close() gibt Puffer frei
Pufferung im OS
C - 10
E.6.2 TCP Sockets
Verbindungsaufbau nötig
spezieller Server Socket wartet auf Verbindungsanforderung,
erzeugt neuen serverseitigen Socket
bindet sich an definierten Port.
Charakteristiken:
garantierte Ablieferung
unstrukturierter Bytestrom
Punkt-zu-Punkt Verbindung
close() gibt Puffer & Ports frei
C - 11
E.7.
Dienstorganisation
E.7.1 Client-Server Schema
Klassischer Ansatz
Server übernimmt die komplette Kontrolle und Koordination
Geringe Netzlast und Bandbreitenbedarf für Klienten
Latenzen gut vorhersagbar
Single point of failure.
C - 12
E.7.2 Peer-To-Peer
Verbindungstopologie:
Höherer Bandbreitenbedarf falls kein Multicast,
Im LAN durch Broadcast einfacher
Vollvermaschte Verbindungen
Komplexität:
Sehr gute Ausfallsicherheit erreichbar,
häufige Abstimmungsverfahren,
Hoher Koordinationsaufwand,
Latenzen schwer abschätzbar.
C - 13
E.7.3 Mischformen
Client ist gleichzeitig Server
Einige Klienten können als Backup fungieren.
mehrere Server zur Lastverteilung ebenfalls möglich
C - 14
E.8.
E.8.1 Übersicht
Einführung
Replikation
Konsistenz
Synchronisierungsarten
Algorithmen
„The Internet sucks“
Sicherheit
C - 15
E.8.2 Replikation
Abstraktion, konzeptionelle Sicht:
alle Knoten sehen zu jeder Zeit die gleichen
Daten und Datenwerte,
Datenelemente sind konzeptuell nur einmal
vorhanden.
Implementierung:
jeder Knoten kann eine eigene Sicht besitzen,
auf die verteilten Informationen,
evtl. verschiedene Versionen,
partielle Sichten.
Replikate:
jeder Knoten kann eigene Replikate besitzen,
z.B. zur Leistungssteigerung (paralleles Lesen),
oder zur Verbesserung der Ausfallsicherheit
Ziel ist, die Replikate konsistent zu halten
C - 16
E.8.3 Konsistenzmodelle
Definition (Michael Schöttner):
„Der Speicherungsmechanismus garantiert gegenüber den zugreifenden Prozessen
Regeln, nach welchen er die Schreiboperationen sichtbar werden lässt.“
Ein Konsistenzmodell ist ein Vertrag zwischen Prozess und
Speicherungsinstanz, der einen deterministischen Ablauf garantieren soll
Die Wahl eines Konsistenzmodells ist immer ein Kompromiss zwischen
geschickter Latenzvermeidung und einfacher Programmierung.
Daten-zentriert:
„Konsistenz aus Sicht des Datenspeichers“
auf verteilten Datenspeicher bezogen,
Teilnehmer verwenden Replikate,
traditioneller Konsistenzbegriff.
Client-zentriert:
„Konsistenz aus Sicht des Klienten“,
unterschiedliche, aber in sich konsistente Sichten in verschiedenen Klienten,
meist seltene und zentrale Aktualisierung,
schwächer als Daten-zentriert
C - 17
E.9.
Zustands-Synchronisierung
Verteilter Speicher als Programmierparadigma.
Synchronisierungspunkte:
beschreiben den diskreten Fortschritt der logischen Zeit im System,
dazwischen sind Zustandsabweichungen zulässig/unvermeidlich,
zum Synchronisierungzeitpunkt ist das System konsistent.
Übertragung des Objektzustandes bei Änderung:
evtl. großer Bandbreitenbedarf bei größerer Anzahl von Objekten,
entweder den kompletten Zustandes eines Objektes übertragen,
oder die Veränderung einzelner Variablen (Diffs),
evtl. automatische Hüllenbildung für Objekte.
Unterschiedliche Dringlichkeit von Eigenschaften:
Interaktionen zwischen entfernten Objekten, Kollisionen,
Position, Bewegung, Bewegungsrichtung, Rotation,
Verformungen, Texturen,
Beleuchtung.
C - 18
E.9.1
Eingabe-Synchronisierung
Nachrichtenbasierte verteilte Programmierung.
Methodenaufrufe übertragen (RMI ...):
Tasten, Mausbewegung, Mausklicks, Events …
Methodencode ist in jedem Knoten repliziert,
Synchronisierungseffekt einer Nachricht.
Konsistenz-Eigenschaften:
Outfit
Objekt-IDs, Meshes, Texturen, Transformationen,
Caching spart Bandbreite in Wide-Area Netzen,
potentiell geringerer Bandbreitenbedarf.
Sit On
Umfangreiche Parametrisierung der Methoden:
Programmierer sorgt für partielle oder globale Konsistenz,
die Semantik der Methoden sollte selbstkorrigierend sein,
Prognosen relativ einfach zu erstellen (Dead-Reckon).
C - 19
E.10.
Zeitskalen zur Synchronisierung
E.10.1 Network Time Protocol
Network Time Protocol entsprechend RFC1305.
Synchronisiert die Uhrzeit (physikalische Zeit).
Primäre Server mit Atomuhr synchronisiert.
Genauigkeit im Internet bei ca. 10ms.
hierarchischer Aufbau:
C - 20
E.11.
Algorithmen zur Szenensynchronisierung
Dead Reckoning
Bucket Synchronisation
Time Warp Synchronisation
Trailing State Synchronisation
Area of Interest Management
Fallstudie: Age of Empires 2
C - 21
E.11.1 Dead Reckoning
Verfahren um Latenzeindrücke zu vermindern (Sprünge vermeiden).
Klienten haben evtl. abweichende Sicht auf globale Szenedaten.
Standardmässig in allen modernen Spielen verwendet.
C - 22
E.11.2 Bucket Synchronisation für „MiMaze“
„MiMaze“, ein Computerspiel:
Forschungsprojekt von Laurent Gautier et. al.
Labyrinth, ähnlich PACMAN.
ADUs – Application Data Units:
feste Größe von 52 Byte,
davon 16 Byte Payload,
Objekt-Zustandes (Position ...)
IP-Header, UDP-Header, RTP-Header,
Zeitstempel bezüglich NTP.
Multicast im LAN mithilfe von RTP.
C - 23
E.11.3 Bucket Synchronisierungsverfahren
Ähnlich zu Bucket-Buffer zur Jitterkorrektur bei Audiodaten
Zeitmanagement:
Zeit in diskrete Intervalle unterteilt,
Eingaben werden verzögert ausgeführt (ca. 100ms)
pro Intervall ein Bucket (40ms bucket interval)
Buckets:
- ADUs abhängig vom Zeitstempel in Bucket einsortieren
- Dead Reckoning für leere Buckets
- Bucketrate entspricht Framerate
Zustands-Drift bei
Paketausfällen.
C - 24
E.11.4 TimeWarp Synchronisierung
Ereignisse:
führen bestehenden Zustand sn über in den Zustand sn+1 ,
können Nachrichten an andere Knoten auslösen,
tragen einen Zeitstempel.
Rücksetzbare Zustandsübergänge:
Zustand erhält den Zeitstempel des auslösenden Ereignisses.
bei jedem Übergang Sicherheitskopie des Zustandes erstellen,
Ereignisse werden mit gesichert.
C - 25
E.11.5 TimeWarp Synchronisierung, Rollback
Zurücksetzen auf Zustand mit Zeitpunkt < e :
falls Ereignis e empfangen, welches älter als gegenwärtiger Zustand,
Undo-Nachrichten für irrtümlich versendete Nachrichten verschicken,
alle Ereignisse nochmal ausführen, kaskadierende Abbrüche möglich!
Speicherbetrachtung:
spezieller Timer für älteste ausstehende Nachricht um alte Zustände zu entfernen,
hoher Speicherbedarf für Checkpoints (z.B. Quake ca. 1MB/Chkpt, 25MB/s/Player)
C - 26
E.11.6 Trailing State Synchronisierung
mehrere simultane zeitverzögerte Ausführungen
move-Befehl zum Zeitpunkt 150 ms rechtzeitig für alle States erhalten.
fire-Befehl erreicht Leading State bei 225ms, also zu spät.
C - 27
E.11.7 Trailing State Synchronisierung, Rollback
zum Zeitpunkt 200ms merkt State S1 das in S0 kein fire-Befehl ausgeführt wurde.
Der notwendige Rollback erfolgt durch kopieren von Zustand S1 auf S0
Der Leading State führt alle Befehle ab 200ms erneut aus
Befehl kann weggeworfen werden, wenn der letzte Trailing State diesen verarbeitet hat
keine Anti-Messages nötig, da Befehle keine Abhängigkeiten erzeugen
benutzt für Quake Worlds
C - 28
E.11.8 Age of Empires 2 (1999)
Eingabe-Synchronisierung, ausgelegt auf hohe Latenzen (bis zu 500 ms).
Stark variierende Antwortzeiten sind für den Spieler unangenehm.
C - 29
E.11.9 Age of Empires 2 – verzögerte Frameberechnung
Verzögerte Frameberechnung (z.B. 300 ms)
Dynamische Anpassung der Spielgeschwindingkeit.
je nach beobachteter Latenz über das Netzwerk,
mit dem Ziel einer gleichförmigen Animation.
Niedrige Latenz:
Process all
Messages
50 ms
Frame
Frame
Frame
50 ms
50 ms
50 ms
Frame
Frame
Frame
Frame
Frame
Frame
50 ms
50 ms
50 ms
50 ms
50 ms
50 ms
Hohe Latenz:
Process all
Messages
50 ms
C - 30
E.11.10 Area of Interest Management – SIMS in Second Life
Partitionierung von großen Spielwelten, Inseln, SIMS, Regions ...
Nötig durch CPU, RAM und Bandbreiten Beschränkung.
Statische vs. dynamische Partitionierung
C - 31
E.12.
Kritikpunkte zum Internet
E.12.1 Fünf Internet-Weisheiten aus Coding X-Wing vs. TIE-Fighter
First Lesson (Peter Lincroft)
„If all players dial into the same phone number, you are not testing the Internet. You
are testing the modems and the POP server, but you are not testing the Internet.“
Second Lesson (Peter Lincroft)
„TCP is evil. Don’t use TCP for a game. You would rather spend the rest of your life
watching Titanic over and over in a theater full of 13 year old girls.“
(TCP stellt keine Pakete zu, die Out-of-Order ankommen sondern wartet bis alles korrekt
eingetroffen ist. Wenn Pakete verloren gehen, geht TCP von einer Verstopfung aus und
drosselt die Paketrate und erhöht in diesem Fall die TimeOut-Zeit)
C - 32
Third Lesson (Peter Lincroft)
„Use UDP. The solution to this evil protocol seems simple at first. Don’t use TCP, use
UDP instead.“
(UDP gibt keine Garantien, Algorithmen zur sicheren Übertragung müssen von Hand imple-mentiert
werden; abhängig von benötigten Garantien großer Implementierungsaufwand)
Fourth Lesson (Peter Lincroft)
„UDP is better than TCP, but it still sucks. We expected packets to be dropped
occasionally, but the Internet is much worse than that.“
(Pakete gehen häufig verloren, Laufzeiten variieren stark. Einfache Acknowledge-Protokolle sind
meistens überfordert. Double-Send sehr erfolgreich)
Fifth Lesson (Peter Lincroft)
„Whenever you think the Internet can’t get any worse, it gets worse. “
(Verbindungsabbrüche, extreme Latenzen und häufige Paketverluste können vorkommen. Hohe
Varianz von Durchsatz und Verlustrate!)
C - 33
E.13.
E.13.1
Sicherheit in Spielen und virtuellen Welten
Klassifizierung von Cheats
Reflex Augmentation
Verbesserung der Reflexe durch automatische Hilfestellung
Authoritative Clients
Klienten, welche uneingeschränkt globale Spieldaten anpassen können
Information Exposure
kritische Information können eingesehen werden
Compromised Server
sicherer Server wird kompromittiert
Bugs and Design Loopholes
Fehler im Quellcode und auch Fehler im Design können Angriffspunkt bieten
Environmental weaknesses
Probleme treten auf, wenn bestimmte Bedingungen herrschen (z.B. Netzwerklatenz)
C - 34
E.13.2 Nine Rules of Security
How to Hurt Hackers: The Scoop on Internet Cheating and How You Can
Combat It. (Matthew Pritchard)
http://www.gamasutra.com/view/feature/3149/how_to_hurt_the_hackers_t
he_scoop_.php?page=1
aus Sicht des Spieleentwicklers (Age of Empire 2, Age of Mythologie … )
jeder der Punkte lässt sich auf virtuelle Welten übertragen.
Sicherheit ist kritisch für eine Online Welt
Rule One (Matthew Pritchard ):
„If you built it, they will come – to hack or cheat it.“
Motivation reicht von „Yes, we can“ bis zu finanziellen Interessen
es kann jeden treffen
Rule Two (Matthew Pritchard ):
„Hacking attempts increase with the success of your game.“
Diablo hatte aufgrund von Cheats einen äußerst schlechten Ruf
Wettbewerbe bei Age of Empires wurden abgesagt
Einzelspieler Cheats gängig und unkritisch
Itemverkauf bei Diablo 2
C - 35
Chinafarmer bei WoW
Rule Three (Matthew Pritchard):
„Cheaters actively try to keep developers from learning their cheats.“
Cheats meistens Clan intern
öffentliche Verbreitung beraubt Cheater des Vorteils
Entwickler könnten Angriffspunkt beheben
öffentliches Brandmarken nur eingeschränkt möglich (Anonymität im Netz)
Rule Four (Matthew Pritchard):
„Your game, along with everything on the cheater's computer, is not secure. The files
are not secure. Memory is not secure. Services and drivers are not secure.“
mächtige Tools wie SoftICE erlauben disassemblieren und Laufzeituntersuchung.
Spiele entwickeln Gegenmaßnahme durch Process Scanning (WoW)
Rule Five (Matthew Pritchard)
„Obscurity is not security.“ (Standardsatz der Sicherheit)
auch komplizierte Dateiformate/Paketformate werden immer entschlüsselt werden
kryptographische Methoden können Abhilfe schaffen.
Rule Six (Matthew Pritchard):
„Any communication over an open line is vulnerable to intercept, analysis & modification.“
Kommunikation im Internet ist unsicher!
„Man in the Middle“ Angriff.
C - 36
Rule Seven ( Matthew Pritchard):
„There is no such thing as a harmless cheat or exploit. Cheaters are incredibly
inventive figuring out how to get the most from loopholes or exploit.“
Kleinste Fehler in Design/Programmierung können fatale Folgen haben.
Gleiche Problematik mit Sicherheitslücken in jeder Art von Software.
Rule Eight ( Matthew Pritchard)
„Trust in the server is everything in a client-server game.“
Besonders bei Servern, die von normalen Benutzer gehostet werden können,
Nutzerknoten sollen nur eingeschränkte Spielinformationen besitzen,
Zentrale Server von Spieleanbietern eher unkritisch,
kaum Kontrollmöglichkeiten bezüglich Server,
veränderte Server schwer feststellbar.
Rule Nine ( Matthew Pritchard)
„Honest players would love for a game to tip them off to possible cheating. Cheaters
want the opposite.“
Problematisch für Gelegenheitsspieler cheating zu erkennen
Meldung des Klienten, wenn veränderte Werte erkannt werden
vgl. Quake 3 „pure server“
C - 37
E.14.
Reflex Augmentation mit Aim-Bots
Cheating Ansatz für Shooter:
Proxy puffert Pakete zwischen und analysiert Spielverlauf:
Proxy gleicht falsche Schussrichtung durch Injektion von Drehbewegung aus,
Spielerverbannung kann auch ehrliche Spieler treffen,
schwer zu detektieren.
C - 38
E.14.1 Aim-Bots Konter (Gegenmassnahme)
Verwürfelte Kommando-IDs:
Verwürfelung zum Beispiel mit Pseudozufallszahlen,
erschwert Identifizierung und Modifikation.
Verschlüsselung der Befehle:
erschwert das Lesen der Daten,
Befehle aber deterministisch.
C - 39
E.14.2 Authoritativer Klient
Autoritätsanmaßung!
Spieler meldet an andere Spieler falsche Daten, diese akzeptieren die
Daten ohne Nachfrage:
Risikobereiche:
Eingriff in die Netzwerkkommunikation
Hacking der lokalen Daten
Gepatchte Software
z.B. Prüfsummen als
Gegenmaßnahme
C - 40
E.14.3 Command Model
Verifikation z.B. im Sinne einer physikalischen Machbarkeit
Meist keine Überprüfung der eingehenden Updates.
Meistens Erweiterung bestehender Game Engines.
C - 41
E.14.4 Command Request
Statt gültigen Kommandos werden Kommandoanfragen verschickt
Jeder Knoten prüft ob die
Anfrage gültig ist, ungültige
Anfragen werden verworfen.
Ansatz kann nicht verhindern,
dass ein Request generiert wird,
der nicht hätte generiert werden
dürfen.
Zusätzlich Generierung von
Checksummen über die Spieldaten.
Ein gehackter Knoten sollte
abweichende Daten produzieren.
C - 42
E.14.5
Information Exposure
Risiko:
kompromittierter Knoten erlaubt Zugriff/Sichtbarkeit auf versteckte Informationen,
Eingriff in das Programm durch Disassemblierer oder Debugger,
Bei Stategiespielen ist Aufhebung des „Fog-of-War“ beliebt.
Gegenmaßnahmen:
Statistiken der Render-Engine über angezeigte Figuren an andere Knoten versenden,
evtl. Einbeziehen der Spielelogik und Heuristiken.
Unterschied zu Autoritativen Klienten: Spieler-Kommandos unverändert.
C - 43
E.14.6 Passive Information Exposure
Risiko:
Spieldaten werden im laufendem Betrieb ausgelesen
kritische Daten werden identifiziert und erlauben Rückschlüsse auf Spielablauf des
Gegners
Gegenmassnahme:
Erkennung evtl. durch Prozess-Scanning
Verschlüsselung der Daten im Speicher
C - 44
E.14.7 Bugs & Design Issues
Age of Empire:
Bug ermöglichte es, eine begrenzte Ressource wiederaufzufüllen.
HalfLife:
Möglichkeit eines schnelleren Nachladens, indem man die Waffe wechselte.
Patching ist unverzichtbar im Design heutiger Spiele und virtueller Welten.
Fehler können praktisch nur durch Entwickler behoben werden.
Fehler sind unvermeidlich.
C - 45
E.14.8 Environmental Weaknesses
Definition:
„Exploitable problems a game may have on particular hardware or
operating conditions.“
Beispiele:
Grafikkartentreiber patchen, um unsichtbare Gegner zu sehen
„construction cancel“ Fehler in Age of Empires & Starcraft
Flooding um Spiel abzubrechen
C - 46
E.14.9 Quellen / Weiterführende Links
The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter Proceedings of
Game Developer's Conference 1999
http://www.gamasutra.com/view/feature/3374/the_internet_sucks_or_what_i_.php?
print=0
Bucket Synchronisation, Proceedings of the IEEE International Conference on
Multimedia Computing and Systems 1998
Scalable distributed military simulations using the SPEEDES object-oriented simulation
framework, In Proc. of Object-Oriented Simulation Conf. (OOS'98), pages 3-23, 1998
An Efficient Synchronization Mechanism for Mirrored Game Architectures, Journal
Multimedia Tools and Applications, Volume 23, Number 1 / May, 2004
1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond
http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php?
print=0
C - 47

E.1.2 Netzwerktypen - Institut für Verteilte Systeme

Transcription

Similar documents

- it-journalist.de

telnet towel.blinkenlights.nl

Handbuch Nero BackItUp

Bedienungsanleitung

Kostenentwicklung Transatlatikkabel

Gebrauchsanleitung Mentype AMLplex

(In)security of Online-Games - Ruhr

____BIU_UML_Nero BackItUp 5.2