Verteilte Systeme Übung 8 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 8.1 Echtzeit-Systeme Echtzeitsysteme sind Hardware- oder Hardware/Software-Systeme, die Operationen innerhalb einer bekannten Zeitspanne vor einer deadline abschließen müssen (nicht zwingend sofort ) Weiche Echtzeitsysteme: Eine Verletzung der deadline stört das System, kann aber entweder kompensiert werden oder verletzt die Systemanforderungen nicht zwangsläufig fatal (Videokonferenzen, Audio-Streaming, Multiplayer-Spiele) Harte Echtzeitsysteme: Eine Überschreitung der deadline verletzt die Systemanforderungen unmittelbar auf fatale Weise (Airbag-Auslösesteuerung, Notabschaltungssystem einer Fertigungsstraße, Drive- und Fly-by-Wire-Systeme) Zur Bestimmung von deadlines eines mehr-komponentigen Echtzeitsystems müssen die jeweiligen deadlines der Komponenten ermittelt werden 8-2
8.2 Verteilte Echtzeit-Systeme In einem verteilten Echtzeitsystem ist das Kommunikationsnetzwerk zentrale Komponente Deadline für Übertragung einer kleinen Steuernachricht von wenigen Bytes? Deadline für Übertragung mehrerer Gigabyte? Wieviele Hosts? Erweiterbar? Worst-Case Auslastung? Deadlines im Netzwerkstack und Middleware? Echtzeitbetriebssystem? Ethernet: Deadlines in CSMA/CD, CSMA/CA, CSMA/BA? Vermittlung: Deadlines im Routing? Zur Realisierung eines verteilten Echtzeitsystems muss das Kommunikationsnetzwerk garantierte Dienstgüten (Quality of Service) bzgl. Minimalbandbreite und Maximallatenz erfüllen Der TCP/IP-Stack und Ethernet mit CSMA/CD bieten nur einen best effort Dienst ohne jegliche Gütegarantien 8-3 8.3 Asynchronous Transfer Mode (ATM) Der Asynchronous Transfer Mode-Stack Implementiert die Schichten 1-3 des OSI-Modells, ist also Alternative zu IP Kann sowohl paket-basierte wie auch synchrone Bitströme übertragen. Asynchronous Transfer bedeutet dabei für einen synchronen Bitstrom, dass Sender und Empfänger unterschiedlich getaktet sein können Versendet Zellen (vergleichbar mit Paketen) mit einem 5 Byte großen Header und 48 Byte Nutzdaten Richtet virtuelle Verbindungen für einen Kommunikationskanal ein (fest oder dynamisch): Jeder Router auf dem Verbindungsweg wird informiert, erfordert Setup-Zeit Pakete nehmen immer denselben Weg Eindeutiger Identifier für einen Kanal 8-4
8.3 Asynchronous Transfer Mode (ATM) eine ATM-Verbindung erfüllt einen Traffic Contract bzgl. der bereitgestellten Bandbreite. Typen: UBR Unspecified Bit Rate (best effort) CBR Constant Bit Rate (Garantierte Mindestbandbreite) VBR Variable Bit Rate (Mit gewisser Schwankung um Mittelwert) ABR Available Bit Rate (Dynamisch von ATM geregelt) Erfüllung eines Traffic Contract durch Traffic Shaping: Steuerung des Zellflusses am Eingangspunkt in das ATM-Netz Traffic Policing: Überwachung der Verbindungen und ggf. Verwerfen von Zellen bei Überschreitung der zugesicherten Bandbreite ATM wird z. B. eingesetzt Zur Echtzeitübertragung von Rundfunk- und Fernsehprogrammen In Internet- und Telefonie-Backbones Für DSL-Zugänge 8-5 8.4 Multiplayer-Spiele Echtzeitspiele arbeiten intern mit diskreten Einzelzuständen, die mit hoher Frequenz aktualisiert werden. Je nach Spieltyp etwa 5-35 Aktualisierungen (ticks oder game- bzw. server-frames) pro Sekunde Vergleichbar: Ein aus dynamisch berechneten Einzelbildern bestehender Film Mehrspieler-Modus zumeist als Client-Server-Architektur Clients senden Benutzerkommandos (Bewegen, Blickrichtung ändern, Schiessen, Einheit x zu Punkt y kommandieren usw.) zum Server Server errechnet neuen Spielzustand aus den eingegangenen Aktionen und sendet neuen Zustand zu den Clients zurück Clients ändern ihre Zustandskopie nie selbst, sondern immer nur gemäß der vom Server empfangenen Aktualisierungen (Optimierung: Temporäre Extrapolation von Bewegungen zur flüssigen Darstellung) Client-Zustände sind somit Replikate des Serverzustands, Konsistenzmodell? 8-6
8.4 Multiplayer-Spiele Beispiel: An einem Unreal Tournament-Client empfangene Positionsupdates eines anderen Spielermodels (20 updates/sek) 8-7 Client-Server Architektur: Eigenschaften Clients erwarten ein Update der Spielwelt gemäß der Update-Frequenz (weiches Echtzeitsystem) Client-Server-Architektur mit einzelnem Server: + Konsistenz leicht zu wahren + Einfach zu implementieren Ermöglicht kleine Partien (unter 100 Mitspielern) wie in First Person Shooter (FPS) und Real-time Strategy (RTS) Spielen üblich - Nicht skalierbar, der Server ist bottleneck - Server ist zentraler Ausfallpunkt Game World Single Game Server Game Entities (Avatars, NPCs, items) 8-8
Skalieren von Echtzeitspielen Verschiedene Skalierungsaspekte denkbar: Maximalzahl der Clients Spielweltgröße Maximaldichte der Clients Jede Erhöhung einer dieser Größen führt zu höherem Rechenaufwand im Server. Maximale Rechenleistung eines einzelnen Servers ist konstant Verletzung der deadline bei Überschreitung der maximalen Rechenzeit für einen neuen Spielzustand: S i 2 1/tickrate S i 1 time S i S i+1 S i+2 φ Si 2,S i 1 φ Si,S i+1 φ Si 3,S i 2 φ Si 1,S i 8-9 Verletzung der Deadline Beispiel: Positionssprünge als Auswirkung verzögert eingetroffener updates (durch Serverüberlastung oder Kommunikationsverzögerungen) 8-10
Zoning: Skalierbarkeit für MMOG Massively Multiplayer Online Games (MMOG) werden mit tausenden von Spielern gleichzeitig in einer Spielwelt gespielt Üblicherweise Zonenaufteilung der Spielwelt mit mehreren Servern, Clients wechseln zu anderem Server bei Zonenwechsel Server A Zone A Game World Zone D Server D Server B Server C Zone B Game Entities Zone C + Spielerzahl mit Spielweltgröße skalierbar + gut geeignet für MMORPG mit riesigen Spielwelten - Erlaubt keine höhere Spielerdichte als einzelner Server - Kaum geeignet für FPS und RTS, da vergleichsweise kleine Spielwelt 8-11 Zoning-Beispiel: Ragnarok online 8-12
Skalierungsalternative: Multi-Server Replikation An unserer Arbeitsgruppe entwickelte Alternative: Vollständige Replikation des Spielzustandes auf mehreren Servern Shadow Entity Game World Server A update Active Entity at B Server B update Shadow Entity Server C + Spielerdichte und -maximalzahl skalierbar + Beliebig kleine Spielwelten möglich + Keine Nahtstellen, kein Serverwechsel erforderlich - Keine Skalierung der Spielweltgröße - Erhöhter Aufwand zur Konsistenzhaltung der Daten Konsistenzmodell: Eventual Consistency 8-13 Skalierungsbeispiel: Rokkatan Im Projektseminar von Studierenden entwickeltes Massively Multiplayer Online Real-time Strategy Game Avatar aus mehreren Klassen auswählbar Teams kämpfen um Flaggen, besetzte Flaggen geben Punkte Bewegungen indirekt: Klicken mit automatischem Laufen Kämpfen direkt: Pro Schlag/Schuss ein Klick auf die Angriffsposition (Erst der Server prüft, ob dort auch ein Gegner steht) 8-14
Skalierungsbeispiel: Rokkatan 600 500 400 300 200 100 supported clients measured 64 forecast 64 measured 128 forecast 128 Session estimated measured deviation 1 pr., 115 cl. 150.7kB/s 152.0kB/s 2 % 2 pr., 170 cl. 213.9kB/s 210.3kB/s 2 % 3 pr., 220 cl. 245.3kB/s 235.5kB/s 5 % 4 pr., 250 cl. 237.0kB/s 222.7kB/s 7 % 5 pr., 290 cl. 243.7kB/s 242.5kB/s 1 % 6 pr., 310 cl. 257.1kB/s - - 8 pr., 375 cl. 284.8kB/s - - 10 pr., 410 cl. 291.2kB/s - - number of proxy servers l 0 0 1 2 3 4 5 6 7 8 9 10 Maximale Spielerzahlen und Netzwerkbandbreite bei 25 updates pro Sekunde (vergleichsweise hoch für ein RTS ) Vorhersagen mit eigenem analytischen Skalierbarkeitsmodell erstellt 8-15 Skalierungsbeispiel: Rokkatan 8-16