Beispiel 3 - Studentenportal
Werbung
Zusammenfassung VSS
Inhalt
01 Charakteristische Eigenschaften Verteilter System ........................................................................... 9
Sicherheit............................................................................................................................................. 9
Transparenz ....................................................................................................................................... 10
02 Systemmodelle ................................................................................................................................. 10
Hardware- und Software-Servicesschichten ..................................................................................... 11
Systemarchitekturen ......................................................................................................................... 11
Entwurfsanforderungen ................................................................................................................ 12
Ubiquitäre Systeme ....................................................................................................................... 13
Grundlegende Systemmodelle .......................................................................................................... 13
Interaktionsmodell ........................................................................................................................ 13
Fehlermodell.................................................................................................................................. 14
Sicherheitsmodel ........................................................................................................................... 15
04 Interprozesskommunikation ............................................................................................................ 15
Anforderungen an eine Interprozesskomunikation .......................................................................... 16
Externe Darstellung und Marshalling ................................................................................................ 16
Probleme mit Little-(Intel)/Big-Endian (SPARC) ............................................................................ 16
Ansatz ............................................................................................................................................ 16
Existierende Externe Darstellungen: ............................................................................................. 16
Java 2 XML ......................................................................................................................................... 17
Referenzierung von entfernten Objekten ......................................................................................... 18
URI/URL in Java.............................................................................................................................. 18
Synchroner vs. Asynchroner IPC........................................................................................................ 18
Java und UDP ..................................................................................................................................... 19
Struktur eines UDP Programms ..................................................................................................... 19
Beispiel .......................................................................................................................................... 19
Java und TCP ...................................................................................................................................... 20
Struktur eines TCP Programmes.................................................................................................... 21
Beispiel .......................................................................................................................................... 21
Direkte Netzprogrammierung vs. Middleware ................................................................................. 24
Gruppenkommunikation ................................................................................................................... 24
IP-Multicast ................................................................................................................................... 24
05 Verteilte Objekte Entfernte Aufrufe................................................................................................. 25
Kommunikationsmöglichkeiten......................................................................................................... 25
Transparenz (Anforderung an kommunizierende Objektsysteme)................................................... 26
Middleware ....................................................................................................................................... 26
RRA Protokoll (Ansatz für Request-Reply Kommunikationsprotokolle)............................................ 26
Nachrichtenformate des Protokolls .............................................................................................. 27
Beispiel eines RequestReply-Protokolls HTTP ............................................................................... 27
Fehlermodell des Protokolls .......................................................................................................... 28
RPC: Remote Procedure Calls (RFC: Remote Function Call) .............................................................. 28
Remote Schnittstellen ................................................................................................................... 28
Schnittstellenbeschreibung (IDL = InterfaceDefinitionLanguage) ................................................. 29
RMI: Remote Method Invocation ...................................................................................................... 30
RMI Komponenten und Aufbau..................................................................................................... 31
Objektübergabe............................................................................................................................. 32
Weitere Begrifflichkeiten .............................................................................................................. 32
Java RMI............................................................................................................................................. 32
Vorteile von RMI............................................................................................................................ 33
Ziel ................................................................................................................................................. 33
Vorbedingung ................................................................................................................................ 33
Vorgehen Grob .............................................................................................................................. 33
Beispiel: Entwicklung einer RMI-Applikation ................................................................................ 34
06 Indirekte Kommunikation – Messaging............................................................................................ 37
Definition ........................................................................................................................................... 37
Modell-Ansatz ................................................................................................................................... 37
Anwendungsfälle ............................................................................................................................... 37
Gruppen-Kommunikation.................................................................................................................. 37
Prozess-Gruppen und Objekt-Gruppen ............................................................................................. 38
Offene und geschlossene Gruppen ................................................................................................... 38
Überlappende Gruppen..................................................................................................................... 38
Synchron und Asynchrone Systeme .................................................................................................. 38
Implementation ................................................................................................................................. 38
Zuverlässigkeit und Ordnung von Multicast .................................................................................. 38
Mitgliederverwaltung .................................................................................................................... 39
JGroups Toolkit .................................................................................................................................. 40
Channels ........................................................................................................................................ 41
JGroups Toolkit Codebeispiel ............................................................................................................ 41
Producer ........................................................................................................................................ 41
Consumer ...................................................................................................................................... 42
Publich-Subscribe System 1:n ........................................................................................................... 42
Publisher ........................................................................................................................................ 43
Subscriber ...................................................................................................................................... 43
Varianten ....................................................................................................................................... 43
Message Queues 1:1 (P2P) ................................................................................................................ 44
Messaging ...................................................................................................................................... 44
Daten Distributions Architekturen .................................................................................................... 44
Virtuell vollverknüpfte Netzwerke .................................................................................................... 45
Kommunikations-Pattern P2P ........................................................................................................... 45
Kommunikations-Pattern Publish-Subscribe ..................................................................................... 45
Kommunikationsmodelle .................................................................................................................. 45
Message-Struktur .............................................................................................................................. 45
Message Selektor .............................................................................................................................. 46
Einfacher Queue Sender und Receiver – Codebeispiel ..................................................................... 46
Publish Suscribe Codebeispiel ........................................................................................................... 46
Message Delivery .............................................................................................................................. 47
Distributed Shared Memory .............................................................................................................. 47
JavaSpaces ......................................................................................................................................... 47
Definitionen ................................................................................................................................... 47
JavaSpace Codebeispiel ................................................................................................................. 48
Transaktionen ................................................................................................................................ 48
08 Verteilte Dateisysteme ..................................................................................................................... 49
Eigenschaften von Dateisystemen / File System Design / Dateisystem Architektur ........................ 49
Dateisystem-Verwendungsstufen ................................................................................................. 49
AIP-Zugriffe: ................................................................................................................................... 50
Varianten verteilter Dateizugriff ................................................................................................... 50
Anforderungen an verteilte Dateisysteme .................................................................................... 50
Sun NFS (Network File System) ......................................................................................................... 51
Andrew File System (AFS) .................................................................................................................. 51
Zusammenfassung............................................................................................................................. 52
09 Namensdienste................................................................................................................................. 52
Definitionen ....................................................................................................................................... 52
Anforderungen an Verzeichnisdienste .............................................................................................. 53
Strategien zur Namensauflösung ...................................................................................................... 53
Iterativ ........................................................................................................................................... 53
Rekursiv ......................................................................................................................................... 53
Server-kontrolliert ......................................................................................................................... 53
DNS .................................................................................................................................................... 54
Aufgaben ....................................................................................................................................... 54
Ressourcen Records ...................................................................................................................... 54
Directory-, und Discoveryservices ..................................................................................................... 54
LDAP (Lightweight Directory Access Protocol) .................................................................................. 54
Typische Attribute laut RFC2256 ................................................................................................... 54
Ablauf LDAP Kommunikation ........................................................................................................ 55
Schema .......................................................................................................................................... 55
JNDI (Java Naming & Directory Interface) ......................................................................................... 55
10.1 Peer 2 Peer Systeme ...................................................................................................................... 56
Routing Overlays ............................................................................................................................... 56
Routing Problem ................................................................................................................................ 56
API für verteilte Hashtabelle (DHT) ............................................................................................... 56
Replikation (DHT) .......................................................................................................................... 56
DOLR Api ........................................................................................................................................ 57
Replikation (DOLR) ........................................................................................................................ 57
Pastry, Tapestry ............................................................................................................................. 57
Routing (Pastry, Tapestry) ............................................................................................................. 57
Zirkuläres Routing.......................................................................................................................... 57
Pastry Routing Beispiel .................................................................................................................. 57
Lokalität in P2P Systemen ................................................................................................................. 58
Lokalität in Tapestry / Tapistry’s Routing Algorithmus ................................................................. 58
10.2 Zeit und globale Zustände ............................................................................................................. 58
Uhren, Ereignisse und Prozesszustände ............................................................................................ 58
Synchronisierung physischer Uhren .................................................................................................. 59
Logische Zeit und logische Uhren ...................................................................................................... 60
Lamport ......................................................................................................................................... 61
VektorZeit ...................................................................................................................................... 62
Globale Zustände............................................................................................................................... 62
Schnappschuss - Algorithmus ........................................................................................................ 64
Anderer Ansatz zur Darstellung des Ablaufes bei der globalen Zustandsfindung ........................ 65
Deterministisch.............................................................................................................................. 66
Nicht-Deterministisch .................................................................................................................... 66
Zusammenfassung............................................................................................................................. 68
11.1 Koordination und Übereinstimmung ............................................................................................ 68
Verteilter wechselseitiger Ausschluss ............................................................................................... 68
Lösungsansatz lokal ....................................................................................................................... 68
Lösungsansatz im Netzwerk .......................................................................................................... 68
Verteilte Synchronisation .............................................................................................................. 69
Mutual Exclusion (ME)................................................................................................................... 69
Leistungsbewertung der Ausschlussalgorithmen.......................................................................... 69
Lösungsansatz Zentraler Server..................................................................................................... 70
Lösungsansatz Ring........................................................................................................................ 70
Ricard und Agrawala’s Algorithmus .............................................................................................. 70
Beispiel R&A .................................................................................................................................. 71
Multicast Synchronisation Beispiel................................................................................................ 71
Verteilte Lösung Beispiel ............................................................................................................... 72
Maekawa’s Algorithmus ................................................................................................................ 72
Resume .......................................................................................................................................... 73
Wahlen Algorithmen ......................................................................................................................... 73
Voraussetzungen ........................................................................................................................... 74
Leistungsbewertung der Algorithmen ........................................................................................... 74
Ring Algorithmus ........................................................................................................................... 74
Bewertung ..................................................................................................................................... 75
Bully-Algorithmus .......................................................................................................................... 76
Bewertung ..................................................................................................................................... 76
Multicast ............................................................................................................................................ 77
IP-Multicast ................................................................................................................................... 77
Konsens und verwandte Probleme ................................................................................................... 78
Byzantinische Generäle ................................................................................................................. 79
PAXOS ............................................................................................................................................ 80
11.2 Petrinetze ...................................................................................................................................... 82
Nebenläufige Systeme....................................................................................................................... 82
Grafische Komponenten.................................................................................................................... 83
Statische Modellbildung .................................................................................................................... 83
Regeln ............................................................................................................................................ 83
Dynamische Modellbildung ............................................................................................................... 84
Definitionen ................................................................................................................................... 84
Beispiel Petrinetz ............................................................................................................................... 84
Notation......................................................................................................................................... 84
Darstellung einer Transition .............................................................................................................. 85
Beispiel-Simulation ............................................................................................................................ 85
Erste Transaktionen....................................................................................................................... 85
Weitere mögliche Transaktionen .................................................................................................. 85
Beispiel: Dining Philosopher .............................................................................................................. 86
Strukturelemente .............................................................................................................................. 87
Strukturkombinationen ..................................................................................................................... 87
Erreichbarkeitsgraph ......................................................................................................................... 88
Definition Erreichbarkeit ............................................................................................................... 88
Beispiel Erreichbarkeitsgraph ........................................................................................................ 88
Beschränktheit............................................................................................................................... 89
Unabhängigkeit ............................................................................................................................. 89
Konflikt .......................................................................................................................................... 89
Deadlock Situation......................................................................................................................... 89
Tote, aktivierbare und lebendige Transitionen ................................................................................. 90
Petri-Netz als Matrix.......................................................................................................................... 90
Invarianten von Netzen ..................................................................................................................... 90
Standardaufgabe Petrinetze.............................................................................................................. 90
Petrinetze Aufgabe 2 ......................................................................................................................... 91
11.3 Messagebased Concurrency.......................................................................................................... 92
Begriffe .............................................................................................................................................. 92
Interprozesskommunikation ............................................................................................................. 92
Semantik ............................................................................................................................................ 92
Unterschied Operationale und Denotationale Semantik .............................................................. 92
Beispiel für die operationale Semantik ......................................................................................... 92
Beispiel für die denotationale Semantik ....................................................................................... 92
Beispiel für die axiomatische Semantik ......................................................................................... 93
Hoarsche Regeln für die Axiomatische Semantik .......................................................................... 93
Semantik in Concurrent Programmen ........................................................................................... 94
Grundprobleme bei der Beschreibung von concurrent Systemen: .............................................. 94
Synchronisationsmechanismen ......................................................................................................... 94
Ansatz CoRoutine .......................................................................................................................... 94
Ansatz Fork... Join .......................................................................................................................... 94
Ansatz cobegin...coend.................................................................................................................. 95
Ansatz process ............................................................................................................................... 95
Shared Variablen ............................................................................................................................... 95
Semaphoren .................................................................................................................................. 95
Conditional Critical Regions CCR ................................................................................................... 96
Monitor.......................................................................................................................................... 96
Message Passing ................................................................................................................................ 96
Beispiel .......................................................................................................................................... 97
Guarded Command ....................................................................................................................... 97
Actors (Higher Level Message Passing) ............................................................................................. 97
Beispiel: Chat ................................................................................................................................. 97
11.4 Modelierung verteilter und mobiler Systeme ............................................................................... 98
Formale Modelle ............................................................................................................................... 98
Labelled Transition System (LTS) ....................................................................................................... 98
Calculus of Communicating Systems (CCS) ....................................................................................... 99
Zündholz ........................................................................................................................................ 99
Kaffeemaschine ............................................................................................................................. 99
Kaffee- und Teemaschine .............................................................................................................. 99
1 Kaffeemaschine + 2 Programmierer ......................................................................................... 100
Restriction ................................................................................................................................... 100
Relabeling (konkretisierung abstrakter Strukturen).................................................................... 100
Parametrisierte Kanäle ................................................................................................................ 100
CCS to LTS ........................................................................................................................................ 100
19 Webservices ................................................................................................................................... 101
XML-RPC .......................................................................................................................................... 101
Language Mapping ...................................................................................................................... 101
Web-Services nächste Phase ........................................................................................................... 101
WSDL ............................................................................................................................................... 101
UDDI ................................................................................................................................................ 101
Referenzen ...................................................................................................................................... 102
SOAP – Simple Object Access Protocol ........................................................................................... 102
REST Design Pattern ........................................................................................................................ 103
CODE BEISPIELE ................................................................................................................................... 104
Bild Bitweise downloaden und speichern (mit Buffer) ................................................................... 104
Webseite mithilfe der Klassen URL, BufferedReader und InputStreamReader lesen .................... 104
JAVA-API .............................................................................................................................................. 105
01 Charakteristische Eigenschaften Verteilter System
Definition
„Verteiltes System“
„Bei einem verteilten System arbeiten Komponenten zusammen, die sich
auf vernetzten Rechnern befinden und ihre Aktionen durch den Austausch
von Nachrichten koordinieren“.
Konsequenzen
1. Komponenten können nebenläufig arbeiten, 2. Komponenten können
unabhängig voneinander ausfallen. 3. Es gibt keine globale Uhr, 4. Es ist
schwierig einen globalen Zustand zu definieren.
Besondere
Anforderungen
An die Fehlertoleranz, Nebenläufigkeit, Sicherheit, Offenheit (anpassbar an
neue Anforderungen, Erweitern), Skalierbarkeit (Ressourcen sollen nur O(x)
verhalten aufweisen, Leistungsengpässe verhindern (z.B. DNS durch
Verteilung), Heterogenität und Transparenz (verbergen der Komplexität)
Heterogen
Unterschiedliche Netzewerke/Rechner/Betriebssysteme In speziellen Fällen
auch unterschiedliche Programmiersprachen/Entwickler/
Implementierungen und unterschiedliche Nutzung. Somit ist auch die interne
Darstellung von Daten unterschiedlich. Zur Homogenisierung von
Heterogenen Systemen wird Middleware verwendet.
Middleware
Middleware ist eine Softwareschicht, welche die Heterogenität beseitigt.
Middleware-Ansätze sind beispielsweise Datenbank-/Transaktionsorientiert,
RPC-Orientiert, Objekt- oder Messageorientiert. Als Alternative kann man
Virtuelle Maschinen nehmen (Java, .NET) mit dynamisch ladbarem
Programmcode.
Offenheit
Offenheit meint, dass sich ein System bei neuen Anforderungen gut
anpassen und erweitern lässt. Mittel zur Schaffung offener System sind
Schnittstellen (publiziert, standartisiert) und einheitliche
Kommunikationsmechanismen (z.B. TCP/IP)
Fehlerverarbeitung
Das System soll Fehler erkennen (z.B. Prüfsumme) und die Fehler maskieren
(verbergen, abschwächen, Meldungen wiederholen) oder tolerieren (durch
Redundanz, Timeout/Leasing). Sollte dennoch ein Fehler auftreten so muss
das System nach Fehlern in einen sicheren Zustand wiederherstellbar sein.
/Fehlertoleranz
Nebenläufigkeit
Mehrere nebeneinander existierende Prozesse innerhalb eines Systems in
evtl. unterschiedlichen Adressräumen. Nebenläufigkeit kann es bei Clients
(Anwendungsprogramme, z.B. Videokonferenz) und Servern (Zugriff auf
Ressourcen, z.B. Datei) geben.
Sicherheit
Beinhaltet
Vertraulichkeit
Daten können nur von dem gewünschten Empfänger gelesen werden
Integrität
Die Daten wurden während der Übertragung nicht verändert
Authenzität
Der Sender ist tatsächlich der der er behauptet zu sein.
Verfügbarkeit
Darf nicht durch eine (DenialOfService) Attacke außer Kraft gesetzt werden.
Transparenz
Definition: Verbergen des inneren Aufbaus in einem verteilten System vor dem Benutzer und dem
Applikationsprogrammierer, so dass das System als Ganzes wahrgenommen wird, und nicht als
Sammlung voneinander unabhängiger Komponenten.
Gemäss ISO und ANSA gibt es folgende 8 Formen:
Zugriffstransparenz
Ermöglicht den Zugriff auf lokale und entfernte Ressourcen unter
Verwendung identischer Operationen.
Positionstransparenz
(Ortstransparenz)
Erlaubt den Zugriff auf die Ressourcen, ohne dass man ihre Position/ihren
Ort kennen muss
Nebenläufigkeitstransp.
Erlaubt, dass mehrere Prozesse gleichzeitig mit denselben gemeinsam
genutzten Ressourcen arbeiten, ohne sich gegenseitig zu stören
Replikationstransparenz Erlaubt, dass mehrere Instanzen von Ressourcen verwendet werden, um
die Zuverlässigkeit und die Leistung zu verbessern, ohne dass die
Benutzer oder Applikationsprogrammierer wissen, dass Repliken
verwendet werden.
Fehlertransparenz
Erlaubt das Verbergen von Fehlern, so dass Benutzer und
Applikationsprogrammierer ihre Aufgaben erledigen können, auch wenn
Hardware- oder Softwarekomponenten ausgefallen sind.
Mobilitätstransparenz
Erlaubt das Verschieben von Ressourcen und Clients innerhalb eines
Systems, ohne dass die Arbeit von Benutzern oder Programmen dadurch
beeinträchtigt wird.
Leistungstransparenz
Erlaubt, dass das System neu konfiguriert wird, um die Leistung zu
verbessern, wenn die Last variiert.
Skalierungstransparenz
Erlaubt, dass sich System und Applikationen vergrössern, ohne dass die
Systemstruktur oder die Applikationsalgorithmen geändert werden
müssen.
02 Systemmodelle
Ein Systemmodell beschreibt die allgemeinen Eigenschaften und das Design eines Systems. Es deckt
die wichtigsten Komponenten des Systems sowie die Art ihrer Interaktion, wie deren individuelles
und kollektives Verhalten beeinflusst werden kann, ab.
Ein Architekturmodell vereinfacht und abstrahiert zunächst die Funktionen der individuellen
Komponenten eines verteilten Systems, um dann die Verteilung der Komponenten auf ein Netzwerk
von Computern und die Beziehung der Komponenten (Rolle in der Kommunikation mit anderen,
Kommunikationsmuster) untereinander zu beschreiben
Hardware- und Software-Servicesschichten
Systemarchitekturen
Client/Server Modell
Reagierender Prozess (Server) welcher Anfragen bearbeitet (evtl.
weiterleitet) und Aufträge erfüllt.
Initiierender Prozess (Client) der Anfragen erstellt, Aufträge erteilt und
Ergebnisse verarbeitet.
Pro Server kann es X-Clients geben.
Peer-to-Peer
Bei Peer-to-Peer sind alle Prozesse gleichrangig und verrichten die gleichen
Arbeiten, zweck von P2P ist eine erhöhte Leistung und Verfügbarkeit zu
erzielen, da kein einzelner Server vorhanden ist.
Häufig existiert ein Leader, der aber austauschbar ist.
Mehrfache Server
Mehrfache Server mischt ein wenig von beiden Systemen. Es gibt mehrere
gleichrangige Server, welche Anfragen von Clients erhalten und Anfragen
auch untereinander austauschen können. Ziel ist eine bessere ServerPerformance gegenüber dem Client/Servermodell und auch eine höhere
Verfügbarkeit. Gleichzeitig wird aber nicht die Kontrolle an Clients
abgegeben wie es bei P2P der Fall ist. Man kann damit Dienste
Partitionieren (Lastverteilung) oder Replizieren (Auf mehreren Ebenen
anbieten wie z.b. DNS lokal, regional etc)
Proxy-Server mit
Cache
Ein Proxy-Server wird vor das Internet gesetzt. Fragt nun z.B. ein Client eine
Seite ab (Nachrichten) läuft diese Anfrage über den Proxy und das Resultat
wird da gecacht für allfälllige weitere Anfragen auf die gleiche Seiten
(durch gleichen oder anderen Client) Damit kann der Traffic auf das
Internet reduziert werden, die Antwortzeit verbessert und indirekt die
Verfügbarkeit verbessert werden. Wobei dann die Verfügbarkeit von jener
des Proxys abhängt.
Applets – dynamische
Die Anfrage des Clients resultiert in einem Download des Applet Code. Der
Erweiterung der
Applikation
Client arbeitet danach mit diesem Applet, wobei dieses je nachdem
zusätzliche Informationen vom Webserver abfragen kann.
Mobile Agenten
Ein Agent ist eine Software-Komponente, welche bestimmte Aufgaben
selbständig erfüllen kann. Beispiele: Einkaufs- oder Reiseagentur-Agent.
Agenten können stationär (agiert in lokalem Wirtsystem) oder mobile
(wandert von Wirtsystem zu einem anderen, in der Regel entfernten
Wirtsystem, Vorteil: es werden nur die augewählten Daten abgeholt) sein.
ThinClients / Schlanke
Clients und
Netzwerkcomputer
Der Thin-Client oder Netzwerk-Computer lädt sein Betriebsystem und
seine Anwendungen vom Server, Vorteil: Benutzer kann an einem
beliebigen Arbeitsplatz arbeiten und seine Session mitnehmen. Mehr dazu
weiter unten.
Entwurfsanforderungen
Leistungsprobleme
durch beschränkte Verarbeitungs- und Kommunikationskapazitäten:
- Die Antwortzeiten wird schnell und konsistent benötigt
- Durchsatz: Verarbeitungs- und Datenübertragungsgeschwindigkeit
- Ausgleich von Rechenauslastung: Nebenläufige Ausführung ohne
Konkurrenz um die Ressourcen
Dienstgüte (Quality of
Service)
Zuverlässigkeit, Sicherheit, Leistung (inkl. Rechtzeitigkeitsgarantie),
Anpassbarkeit
Caching und Replikation
Cache-Konsistenz-Protokoll notwendig
Zuverlässigkeitsprobleme
Fehlertoleranz
Korrekt arbeiten trotz Fehler
Sicherheit
Erzeugen von Vertrauen durch Schutz vor Angriffen!
Korrektheit
aktuelle Forschung???
Ubiquitäre Systeme
Charakteristiken
Unsichtbarkeit
Computertechnologie soll vollständig aus dem Bewusstsein der Nutzer
verschwinden
Lokale Skalierbarkeit
Anstieg der Bandbreite, Energie eines Nutzers und Anstieg der Nutzer in
einem „Dienstraum“. Lokalität ändert sich rasch und es gibt mehr lokale
als entfernte Interaktionspartner
Ausgleich
Unterschiedliche Ausstattung unterschiedlicher Diensträume werden vom
System "homogenisiert
Information Appliance
Rückverlagerung der Funktionalität von Rechnern in die Anwendung.
Grundlegende Systemmodelle
Es gibt folgende drei grundlegende Modelle verteiler Systeme:
Interaktionsmodell
Interaktion auf Grund des Nachrichtenaustausches
Fehlermodell
Eventuell reduzierte Funktionalität / Leistung auf Grund von Ausfällen
(Software- / Hardware- / Kommunikations-Fehler)
Sicherheitsmodell
Sicherheit und Schutz der Nachrichten und des Nachrichtenaustauschs
Interaktionsmodell
Prozesse verarbeiten Informationen und zwischen diesen muss eine Kommunikation und
Koordination/Synchranisation stattfinden. Es gibt zwei Fundamentale Gegebenheiten: 1.
Kommunikationsleistung ist eingeschränkt und 2. eine Globale Zeit gibt es nicht.
Kommunikationsleistung
ist eingeschränkt
Leistung der Kommunikationskanäle wird eingeschränkt:
- Verzögerungen zwischen Senden und Empfangen
- Bandbreite kann je nach Belastung variieren
- Jitter (Variationen in der Übertragungszeit) kann beispielsweise bei
Multimedia Applikationen zu Verzerrungen führen.
Globale Zeit gibt es nicht
Uhren und Timing kann man nicht exakt synchronisieren:
-Ansatz 1: GPS (outdoor überall gleiche Zeit empfangen)
-Ansatz 2: statistische Übertragungszeiten
Beide Ansätze liefern kein zuverlässiges Ergebnis
Varianten
Synchron verteilte Systeme
- Zeitdauer für die Ausführung einer Operation ist in Grenzen
bekannt (obere/untere Grenze).
- Die Übertragungsdauer von/zu Client/Server ist begrenzt.
- Jeder Prozess arbeitet mit seiner lokalen Zeit.
Asynchron verteilte Systeme
- Prozessausführungszeit ist nicht begrenzt.
- Übertragungszeiten zwischen Rechnern ist nicht begrenzt.
- Uhren gelten nur lokal; einzig vorher/nachher ist definiert.
Fehlermodell
Ausfallen können: 1. Prozesse (wegen Hardware, Software [OS, Netz, Applikation]) oder 2. der
Kommunikationskanal.
Bei einer Dienstverweigerung des Prozesses oder Auslassungsfehlern (Omission Failures) kann der
Prozess abstürzen oder die Kommunikation wird so gestört das sie sogar verweigert wird.
Sicherheitsmodel
Die Sicherheit eines verteilten Systems kann durch Sicherung der Kommunikationskanäle (mit deren
Hilfe Prozesse Informationen austauschen) und durch Sicherung der Objekte (welche in den
Prozessen gekapselt sind) vor unautorisiertem Zugriff geschützt werden.
Definition Prinzipal: Berechtigung (Benutzer/Prozess) unter der ein Aufruf/Ereignis ausgeführt
werden darf.
Sicherheit besteht also aus dem Schutz von 1. Prozessen, 2. Objekte, 3. Kanäle.
Prozess-Bedrohung
- Der Serverprozess kann oft nicht eindeutig entscheiden, ob ein
verlangter Aufruf berechtigt ist oder nicht, da er die Identität des Clients
zu wenig genau kennt.
- Der Clientprozess weiss bei einer Antwort nicht, ob diese wirklich vom
Server oder einem "Feind" stammt.
Kanal-Bedrohung
- Ein Feind kann Meldungen stören, verfälschen oder austauschen (siehe
unten)
- Ein Feind kann auch Meldungen zwischenspeichern und zu einem
späteren Zeitpunkt erneut benutzen
Andere Bedrohungen
z.B. Denial of Service
04 Interprozesskommunikation
Damit zwei Prozesse Informationen austauschen können, müssen sie Interprozesskommunikation
(interprocess-communication, IPC) verwenden. IPC basiert auf dem Austausch von Nachrichten sowie
einer eventuellen Synchronisation.
Anforderungen an eine Interprozesskomunikation
Zuverlässigkeit Selbst beim Verlust einzelner Pakete wird die Nachricht als Ganzes verständlich
übertragen.
Ordung
Die Paketreihenfolge bei Empfänger und Sender müssen (idealerweise) gleich sein.
Im Falle von TCP wird dies garantiert (verbindungsorientierte Kommunikation mit
Ack, also mit Overhead). Im Falle von UDP kann nicht davon ausgegangen werden
(verbindungslose Kommunikation ohne Ack, also weniger Overhead)
Externe Darstellung und Marshalling
Die meisten Anwendungen bzw. Middleware-Ansätze nutzen ein gemeinsames Datenformat,
genannt externe Datendarstellung. Dies ist notwendig wegen der Heterogenität der Umgebungen
(unterschiedliche Hardwarearchitektur, Betriebssysteme und Programmiersprachen)
Unter Marshalling versteht man den Prozess der Transformation strukturierter Datenelemente und
elementarer Werte in eine (mit einer Nachricht übertragbaren) externe Datendarstellung
Unter Un-Marshaling versteht man den Prozess der Erstellung elementarer Werte aus ihrer externen
Datendarstellung und der Wiederaufbau der Datenstrukturen
Probleme mit Little-(Intel)/Big-Endian (SPARC)
Integer werden durch die unterschiedliche Byteordnung gedreht, aber Zeichenketten nicht
Ansatz
Idee:
-Definiere eine Menge von abstrakten Datentypen und eine Kodierung (ein genaues Bit-Format) für
jeden dieser Typen
-Stelle Werkzeuge zur Verfügung, welche die abstrakten Datentypen in Datentypen der verwendeten
Programmiersprache übersetzen
-Stelle Werkzeuge zur Verfügung, welche die Datentypen der verwendeten Programmiersprache in
die abstrakten Datentypen und damit in das kodierte Format übersetzen
-Senden (Marshalling): wenn ein bestimmter Datentyp übertragen werden soll, rufe die
Kodierfunktion auf und übertrage das Ergebnis
-Empfangen (Un-Marshalling): dekodiere den Bit-String und erzeuge eine neue lokale Repräsentation
des empfangenen Typs
Existierende Externe Darstellungen:
-Objektserialisierung (z.B. in Java und .Net möglich) oder noch allgemeiner: XML.
Common Data Representation CDR
Java Objektserialisierung
Serializable und Externalizable Interface:
-Serializable: Kontrolle liegt beim System (Serialisierung durch das System).
-Externalizable: Objekt- Serialisierung wird durch die markierte Klasse kontrolliert.
Java 2 XML
Java->XML
XMLEncoder enc=new XMLEncoder(new BufferedOutputStream(new
FileOutputStream(„Testexport.xml“)));
enc.writeObject([OBJEKT]);
enc.close();
XML->Java
XMLDecoder dec = new XMLDecoder(new
BufferedInputStream(newFileInputStream(“Testexport.xml”)));
[KLASSE] o = ([KLASSE])dec.readObject();
dec.close();
Referenzierung von entfernten Objekten
Zur Referenzierung von „entfernten Objekten“ muss ein solche im verteilten System eindeutig
identifizierbar sein. Nach dem Löschen eines solchen Objektes darf die Identifikation nicht wieder
verwendet werden, da eventuell noch ungültige Referenzen auf diese zeigen.
Möglichkeit: Aufbau wie URL => Internet-Adresse des remote-Computers, Port Nummer des
Prozesses zu dem das remote Objekt gehört, Zeitput zudem das Objekt kreiert wurde, eine laufende
Nummer und Informationen zum verwendeten Interface => Ist dann sehr eindeutig, aber auch relativ
gross.
URL (Uniform Resource Locator)
Damit klar ist welcher Server
URN (Uniform Resource Name)
Welche Datei, unabhängig vom Server
URI (Uniform Resource Identifier)
URI=URL+URN (z.B. http://java.sun.com/testpage.html#12)
URI/URL in Java
URI in URL umwandeln und umgekehrt:
uri = new URI("file://D:/Test/Alpha.java");
url = uri.toURL()
uri = new URI(url.toString());
Synchroner vs. Asynchroner IPC
Synchron
Asynchron
Sender und Empfänger blockieren
beim Senden bzw. Empfangen d.h.
wenn ein Senden ausgeführt wird,
kann der Sender erst dann
weiterarbeiten, nachdem das
zugehörige „Empfangen“ im
Empfänger ausgeführt wurde:
Das Senden findet nicht- blockierend statt d.h. der Sender
stellt seine Nachricht in die Ausgabe Warteschlange und
arbeitet weiter;
Das Empfangen kann blockierend oder nicht- blockierend
sein: Blockierend: sobald der Empfänger receive() abgesetzt
hat wird blockiert bis die Nachricht vollständig gelesen
wurde. Nicht- blockierend: nach receive() wird der Buffer
gefüllt; falls dieser voll ist, wird der Empfänger
benachrichtigt.
Vorteil
Leicher zu implementieren
Effizienter
Nachteil
Weniger effizient als Asynchron
Komplexer als synchron (Queues)
Der Trend geht in vielen Anwendungen in Richtung Asynchron. dotNet hat einige sehr gute neue
Konzepte implementiert, welche die asynchrone Kommunikation nutzen.
Java und UDP
DatagramPacket enthält die zu sendende Information. (public DatagramPacket(byte[] buf, int length,
InetAddress address, int port);)
DatagramSocket besitzt vor allem die Methoden send(DatagramPacket) und
receive(DatagramPacket)
Struktur eines UDP Programms
Beispiel
public class UDPSender {
private final String TARGET_HOST=“localhost“;
private fnal int TARGET_PORT = 9191;
public UDPSender() {
try {
socket = new DatagramSocket();
DatagramPacket packet;
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
String message = in.readline();
byte[] data = new byte[message.length()];
data = message.getBytes();
packet = new DatagramPacket(data, data.length,
InetAddress.getByName(TARGET_HOST), TARGET_PORT);
try {
socket.send(packet);
} catch(IOException e) {
e.printStackTrace();
}
socket.close();
} catch(Exception e) {
System.err.println(e);
}
}
public static void main(String[] args) {
new UDPSender();
}
}
public class UDPReceiver {
private final int TARGET_PORT=9191;
private final int BUFFER_LENGTH=256;
public UDPReceiver() {
try {
byte[] inbuf;
DatagramSocket socket = new DatagramSocket(TARGET_PORT);
String msg=null;
do {
inbuf = new byte[BUFFER_LENGTH];
DatagramPacket packet = new DatagramPacket(inbuf, inbuf.length);
socket.receive(packet);
msg=new String(inbuf).trim();
System.out.println(“[UDPReceiver]Message: “ + msg);
} while (!msg.equals(“.”));
} catch (SocketException e) {}
catch (IOException e) {}
}
public static void main(String[] args) {
new UDPReceiver();
}
}
Java und TCP
ServerSocket (Server) ist passiv und wartet nach dem Aufruf der accept-Methode auf
Verbindungsaufbauwünsche (connect-Anforderungen) von Clients.
Socket (Client) wird vom Client genutzt und mittels Konstruktor wird implizit eine Verbindung zu
einem Server aufgebaut.
Bei beiden Klassen kann man sich eine Referenz auf den Ein- bzw. Ausgabedatenstrom geben lassen.
Datenströme können dann nach dem ganz normalen Java-Schema genutzt werden.
RMI: http://de.wikipedia.org/wiki/Remote_Method_Invocation
Struktur eines TCP Programmes
Beispiel
Socket Server (multithreaded)
public class TCPServer {
public static void main(String args[]) {
try {
int serverPort = 7896;
System.out.println(“Server gestartet!”);
ServerSocket listenSocket = new ServerSocket(serverPort);
while (true) {
Socket clientSocket = listenSocket.accept();
System.out.println(“Neue Verbindung! Erzeuge TCPConnection...”);
Connection c = new Connection(clientSocket);
c.start();
}
} catch(IOException e) {
System.out.println(“Listen: “ + e.getMessage());
}
}
}
class TCPConnection extends Thread {
DataInputStream in;
DataOutputStream out;
Socket clientSocket;
public TCPConnection(Socket aClientSocket) {
try {
clientSocket = aClientSocket;
in = new DataInputStream(clientSocket.getInputStream());
out = new DataOutputStream(clientSocket.getOutputStream());
this.run();
} catch(IOException e) {
System.out.println(“Connection: “ + e.getMessage());
}
}
public void run() {
try {
String data = in.readUTF();
out.writeUTF(data+” “ + InetAddress.getLocalHost());
clientSocket.close();
} catch (EOFException e) {
System.out.println(“EOF:” + e.getMessage();
} catch (IOException e) {
System.out.println(“IO:” + e.getMessage();
}
}
}
Socket Client (blocking)
public class TCPClient {
public static void main(String args[]) {
try {
Socket s;
String host, msg;
int serverPort = 7896;
if (args.length<1) {
host=”localhost”;
msg=”Hello World”;
} else {
host=args[0];
msg=args[1];
}
s = new Socket(host, serverPort);
DataInputStream in = new DataInputStream(s.getInputStream());
DataOutputStream in = new DataOutputStream(s.getOutputStream());
out.writeUTF(msg);
String data = in.readUTF();
System.out.println(“Received:” + data);
s.close();
} catch (UnknownHostException e) {
System.out.println(“Socket: “ + e.getMessage());
} catch (EOFException e) {
System.out.println(“EOF: “ + e.getMessage());
} catch (IOException e) {
System.out.println(“IO: “ + e.getMessage());
}
}
}
Socket Client (nonblocking)
public class Socket_NonBlocking {
public static void main(String args[]) {
try {
InetAddress addr = InetAddress.getByName(“localhost”);
int port = 9090;
SocketAddress sockaddr = new InetSocketAddress(addr,port);
Socket sock = new Socket();
int timeoutMs = 2000;
sock.connect(sockaddr, timeoutMs);
} catch (UnknownHostException e) {
} catch (SocketTimeoutException e) {
} catch (IOException e) {
}
}
}
Direkte Netzprogrammierung vs. Middleware
Direkte Netzprogrammierung (Assembler der
Verteilten System-Programmierung)
Middleware (Höhere Sprache der Verteilten
System -Programmierung)
-Direkte Kontrolle aller Transportparameter
-Sehr bequemer Weg zur Entwicklung von
Anwendungen
-grössere Flexibilität bei der Entwicklung neuer
Protokolle
-Kann in vielen Fällen bessere Performance
bringen
-Datenrepräsentation, Objektlokalisierung,
Transaktionsdienst, Fehlerbehandlung,
Sicherheitsdienst, etc. werden angeboten
(verschiedene Anbieter).
-Grosse Probleme:
-Overhead, da allgemein ausgelegt.
-fehlende Datenrepräsentation
-Zusatzanforderungen, wie Verschlüsselung,
Namensdienst, Transaktionsdienst,
Fehlerbehandlung etc. müssen
„eingekauft“ werden
Gruppenkommunikation
Gruppenkommunikation basiert oft auf Multicasting welches Routermässig erlaubt werden muss. Bei
modernen Multimediaanwendungen wie Videokonferenzen oder gemeinsamem Editieren von
Dokumenten wird eine effiziente Gruppenkommunikation immer wichtiger. Für eine
Gruppenkommunikation zwischen n Mitgliedern könnte auch durch den Aufbau von (n-1) 1:1Verbindungen realisiert werden. Das ist sehr ineffizient die Standardlösung heisst deshalb Multicast
und stellt eine 1:n-Verbindung (unterschiedlichster Möglichkeiten) zur Verfügung: Somit muss die
Anwendung nur eine Verbindung pro Gruppe verwalten und die Ressourcen im Netz werden
effizienter genutzt.
IP-Multicast
IP-Multicast verwendet eine spezielle Form von IP-Adressen, um Gruppen zu identifizieren (eine
Klasse-D-Adresse).
Wenn eine Nachricht an diese Adresse geschickt wird, erhalten diese alle Mitglieder, die ihre
Zugehörigkeit zu der dazugehörigen Gruppe erklärt haben.Die Weiterleitung erfolgt mittels
Multicast-Routern. Begrenzung erfolgt durch Angabe der Anzahl durchlaufbarer Router.
Java stellt ein API für IP Multicast zur Verfügung. Es erlaubt
-Beitreten (join) und Verlassen (leave) der Gruppe
- Senden von Paketen
- Empfang von Paketen , die an die Gruppe geschickt wurden.
05 Verteilte Objekte Entfernte Aufrufe
Kommunikationsmöglichkeiten
Kommunikation zwischen Objekten
Prozedurale Programmierung
Procedure Calls
Objekt-Orientierte Programmierung
Methodenaufruf (Method Invocation)
Kommunikation zwischen verteilten Objekten
RPC Remote Call
Entfernte Prozeduraufrufe
RMI Remote Methode Invocation
Entfernte Methodenaufrufe
Transparenz (Anforderung an kommunizierende Objektsysteme)
- Der Benutzer sollte kaum Unterschiede erkennen zwischen einem lokalen und einem remote
Prozeduraufruf!
- Völlige Transparenz ist aber nicht erwünscht, weil die Fehlermodi (Ausfall der Senders, des Kanals,
des Empfängers) zu unterschiedlichem Ausfallverhalten führen können. Und der Entwickler wird
einen Fehler nur schlecht lokalisieren können, wenn er nicht erkennt, ob der Fehler lokal, im
Netzwerk oderremote aufgetreten ist.
Middleware
-Software die oberhalb der Basisprozesse und Nachrichtenübermittlung angesiedelt ist.
Die Hauptaufgaben sind:
- Bereitstellen der lokalen Transparenz (Remote aufrufe sollen so einfach wie lokale realisierbar sein,
der Ort des aufgerufenen Objekts braucht nicht bekannt zu sein.)
- Unabhängigkeit von Kommunikationsprotokollen schaffen (Applikation die auf Middleware
aufsetzen brauchen sich nicht um TCP oder UDP zu kümmern.
- Abstraktion von Betriebssystem, Programmiersprache und Hardware.
RRA Protokoll (Ansatz für Request-Reply Kommunikationsprotokolle)
Definition eines generellen Protokolls für die Client Server Kommunikation. Dies ist kein Standard,
dient aber als Basis für konkrete Definitionen wie RPC, RMI und andere.
Anforderungen an RRA-Protokoll:
- Requests an einen Server senden
- Antworten des Servers zu empfangen
- Allenfalls ein Acknowledge zu senden
R für Request
R für Response
A für Acknowledge
Client-Operation
Sendet eine Anforderung an das entfernte Objekt und erhält die Antwort
zurück. Vorausgesetzt ist, das der Client ein Marshalling für die Argumente in
ein Byte-Array durchgeführt hat und für das zurückgegebene Byte-Array ein UnMarshalling durchführt
public byte[] doOperation (RemoteObjectRef o, int methodId, byte[]
arguments);
Die Argumente spezifizieren:
-die Referenz des entfernten Objekts,
-die aufzurufende Methode bzw. deren ID und
-die Argumente dieses Methodenaufrufs.
Server-Operation
Nimmt eine Client-Anforderung über den Server-Port an.
public byte[] getRequest ();
Sendet die Antwort-Nachricht an den Client mittels Internetadresse und
Portnummer
public void sendReply (byte[] reply, InetAddress clientHost, int clientPort);
Nachrichtenformate des Protokolls
messageType
int (0=Request, 1=Reply)
requestID
int (NachrichtenID, für Anforderungen erzeugt und für Antwort die gleiche
genutzt. Erlaubt Überprüfung der Anforderung-Antwort-Zuordnung)
objectReference
RemoteObjectReferenz
methodID
int oder Methode (Identität der Methode, in Java z.B. Instanz von Method)
arguments
byte array
Beispiel eines RequestReply-Protokolls HTTP
Fehlermodell des Protokolls
Mögliche Fehler aller drei Operationen:
-Dienstverweigerungen;
-Nachrichten werden nicht in der Sendereihenfolge ausgeliefert.
Einfache Fehlerbehandlung durch:
*Timeouts: Aktionen für die doOperation könnten sein:
-Abbruch der Operation mit Fehlermeldung an den Client,
-Wiederholung der Anforderungsnachricht bis Antwort erhalten oder eine bestimmte Anzahl
an Timeouts erfolgt ist.
* Verwerfen doppelter Anforderungen von getRequest:
- bleibt passiv, wenn der Server mit dem Auftrag noch beschäftigt ist
- ruft sendReply mit der zugehörigen Antwort nochmals auf, falls die Aufgabe bereits erledigt
ist,aber die Antwort evtl. nicht beim Client angekommen ist.
Führen einer History der übertragenen Antworten hilft die Rechenzeit zu vermindern, da
Anforderungen bei Nachrichtenverlust nicht nochmals berechnet werden müssen. Um den
Speicheraufwand zu reduzieren kann der Client ein Acknowledge zu einer Antwort senden, die dann
aus der History gelöscht werden kann.
RPC: Remote Procedure Calls (RFC: Remote Function Call)
“A remote procedure call (RPC) is an inter-process communication that allows a computer program
to cause a subroutine or procedure to execute in another address space (commonly on another
computer on a shared network) without the programmer explicitly coding the details for this remote
interaction. That is, the programmer writes essentially the same code whether the subroutine is local
to the executing program, or remote.”
Design Ideen:
- Verteilte prozedurale Programmierung
-Interaktion zwischen (entfernten) Objekten:
-Objekte werden mithilfe von Interfaces spezifiziert.
-Die Implementierung der Objekte bleibt verborgen.
- Der direkte Zugriff auf lokale Variablen des remote Systems ist auf Grund unterschiedlicher
Adressräume (Memory) der verteilten Prozesse nicht möglich (es findet keine
Speicheradressumsetzung statt).
Remote Schnittstellen
-Die Schnittstellen werden abstrakt spezifiziert.
-Der Zugriff auf lokale Variablen kann in den Schnittstellen-Beschreibungssprachen nicht direkt
spezifiziert werden: Es werden deshalb set- und get- Methoden dafür eingesetzt. Diese können auch
synchronisiert werden, damit keine Probleme bei Concurrent Methodenaufrufen geschehen.
-Parameter werden als Input oder Output Parameter gekennzeichnet.
-Zeiger als Parameter machen kaum Sinn, weil remote und lokal unterschiedliche Adressräume
vorhanden sind.
Client Stub Prozeduren entsprechen Proxies und werden Stubs genannt: Sie gestatten dem Client
einen Remote Procedure Call wie einen lokalen Call zu behandeln.
Server Stub Prozeduren entsprechen Proxies und werden Skeletons genannt.
Schnittstellenbeschreibung (IDL = InterfaceDefinitionLanguage)
IDL (Interface Definition Language) waren die ersten Ansätze im RPC Umfeld und wurden
standartisiert. Sie gestattet den Einsatz von unterschiedlichen Programmiersprachen, da aus der IDLBeschreibung Rahmenprogramme und Interfaces für die konkrete Programmiersprache der
Implementierung generiert werden. IDL ist aber sprachneutral definiert.
Auch Sun RPC / XDR, MS RPC / DCOM und OSF DCE IDL verwenden eine (leicht andere) IDL
Andere Ansätze:
- WSDL für WebServices (WebServiceDescriptionLanguage in XML)
- XML basierte Interface Beschreibungen
Aufbau
IDL ist analog zu einer Programmiersprache aufgebaut:
-Module und Namensräume
-Interfaces
-Valuetypes
-Abstract Interfaces
-IDL Datentypen
-Definition eigener Datentypen
-Konstanten
-Konstante Ausdrücke
Beispiel mit Beschreibung
module Bank {
exception UngenuegenderKontostand {
float aktuellerKontostand;
};
interface Konto {
attribute wstring name;
readonly attribute unsigned long ssn;
readonly attribute float kontostand;
void abheben (in float betrag) raises (UngenuegenderKontostand);
void einzahlen (in float betrag);
};
};
Die Methodenbeschreibung spezifiziert die Signatur, den Rückgabewert und allfällige Exceptions
(raises…)
Parameter haben eine bestimmte Richtung:
- in: Nur Eingabe durch den Client
- out: Nur Ausgabe des Objeks an den Client
- inout: Eingabe und Ausgabe (und die Helperklassen ermöglichen dies in Java)
Attribute entsprechen den Objektvariablen (Objekt-Attributen)
RMI: Remote Method Invocation
RMI wird für die Kommunikation zwischen verteilten Objekten verwendet. Das verteilte
Objektsystem sollte sich möglichst gut in das bestehende Objektsystem einfügen:
-Einfach einsetzbar
-Keine exotischen neuen Sprachkonzepte
Ziele von RMI (Remote Method Invocation) in Java:
-Untersützung für unterschiedliche VMs (IBM, Sun, …)
-Security!
-Es soll sichtbar sein, ob eine Methode lokal oder remote einsetzbar ist.
-Typensicherheit
-Unterschiedliche Referenz-Semantiken: z.B. Lazy Activation
Verteiltes Objektsystem
Entfernte und lokale Methodenaufrufe
Jeder Prozess hat einige Objekte, die entfernte Aufrufe erhalten können (entfernte Objekte genannt)
und andere Objekte, die nur lokale Aufrufe enthalten können.
-Objekte müssen die entfernte Objektreferenz eines Objektes in einem anderen Prozess kennen, um
dessen Methoden aufrufen zu können. Wo bekommen sie diese Referenz her?
=> Die entfernte Schnittstelle spezifiziert, welche Methoden entfernt aufgerufen werden können.
ACHTUNG: In Java ist es nicht möglich, dass ein objekt lokale UND entfernte Methoden enthält, es ist
nur entweder lokal oder entfernt erlaubt. Aber der Server kan natürlich lokale Methoden haben.
RMI Komponenten und Aufbau
Das Kommunikationsmodul
Ausführung des Request-/Reply-(Anforderungs/Antwort)-Protokoll
messageType
int (0=Request, 1= Reply)
requestId
int
objectReference
RemoteObjectRef
methodId
int or Method
arguments
array of bytes
Entferntes Referenzmodul
-Übersetzt zwischen entfernten und lokalen Objektreferenzen;
-besitzt meist eine entfernte Objekt-Tabelle, in der diese Zuordnung eingetragen wird.
-Beim ersten Aufruf wird die entfernte Objektreferenz von diesem Modul erzeugt.
Proxy
Macht die entfernten Methodenaufrufe für den Client transparent
-Der Client setzt einen Aufruf lokal an den lokalen Proxy ab (Stub)
-Der Proxy kommuniziert mit der Middleware
-Diese übermittelt die Anfrage (inklusive Marshalling / De-Marshalling) an den remote Server Proxy
(Skeleton)
-Der Server Proxy leitet die Anfrage zum remote Objekt weiter und empfängt eine allfällige Antwort,
die er dann an den Client Proxy weiterleitet
Dispatcher
-Der Server verwendet einen Dispatcher, der die Requests empfängt und an das Skeleton der ServerKlassen weiterleitet.
-Der Dispatcher muss die passende Methoden-ID kennen.
Skeleton (Server Proxy)
-Entfernte Objekte besitzen ein Skeleton (Server Proxy).
-Dieses implementiert die Methoden des entfernten Objekts auf eine eigene Art und Weise.
-Das Server Proxy Objekt (Skeleton) ruft die entfernte Methode auf.
Objektübergabe
Festlegung der Übergabesemantik i.A. durch Typ des formalen Parameters:
-Referenzen und Werte sind zunächst alles Werte! Die Übergabesemantik regelt die Art der
Interpretation.
-Referenzübergabe: wenn der formale Parameter ein bestimmtes Interface (in Java z.B.
java.rmi.Remote) implementiert
- Wertübergabe: in allen anderen Fällen
Bei Wertübergabe sind Komplikationen möglich:
- Wenn das übergebene Objekt direkt oder indirekt andere Objekte referenziert, müssen diese
ebenfalls übergeben werden => Rekursiv
- Sharing von Objekten muss auf der Clientseite rekonstruiert werden
- Wenn das übergebene Objekt ein echter Untertyp des formalen Parameters ist, ist u.U. Upcast
erforderlich
Weitere Begrifflichkeiten
- Binder: Namensdienst, der Clients Objektreferenzen vermitteln kann
- Server-Thread: Um zu verhindern, dass ein entfernter Aufruf einen anderen Aufruf verzögert,
weisen Server der Ausführung jedes entfernten Aufrufs einen eigenen Thread zu!
- Aktivierung: Erzeugung einer Instanz und Initialisierung der Instanzvariablen.
- Persistenter Objektspeicher: Verwaltet persistente Objekte, also Objekte, die zwischen
Aktivierungen weiterbestehen.
- Verteiltes Garbage Collection: Stellt sicher, dass in einem verteilten System garbage collection
durchgeführt wird, sprich auch remote Objekte sollten automatische entsorgt werden können
Problem: Referenzen, die nur in Nachrichten vorhanden sind. Methoden: mithilfe von Leasing
und/oder Referenzenzählern. In Java steht dazu der DGC, distributed garbage collector, zur
Verfügung. Er verwendet Reference Counting und Lease Time, um bestimmen zu können, ob ein
remote Objekt noch benötigt wird.
Java RMI
RMI macht nur Sinn wenn eine reine Java-Umgebung besteht.
Vorteile von RMI
+Der Client benötigt nur den (Platzhalter) Namen des remote Objekts.
+Die Kommunikation unterscheidet sich aus Client Sicht kaum von einem lokalen Prozedur /
Methodenaufruf
+Client und Server müssen sich lediglich über ein (gemeinsam genutztes) Interface einigen.
Ziel
Der Client kann irgendwo vorhandene, nützliche Methoden einsetzen
Vorbedingung
-Die remote Methoden müssen als solche gekennzeichnet sein
-D.h.:
-Es reicht nicht, ein Server-Objekt zu kreieren.
-Dieses kann ohne zusätzlichen Interfaces nicht remote genutzt werden.
-Das Server- Objekt kann durchaus über rein lokalw Methoden verfügen.
Vorgehen Grob
Objekt wird auf dem Server angelegt
Dienst dienst = new Dienst(…);
Server muss den Dienst irgendwie bekannt
geben: er exportiert / publiziert Dienst:
UnicastRemoteObject.export(dienst)
Client beschafft sich eine Referenz auf das
entfernte Objekt:
DienstInterface r_Dienst =
1) über einen (zu ermittelnden) Context.
2) oder mithilfe von einer Registry (lookup)
Client ruft remote Methode auf
context.getRemoteRef(„Dienst“);
(DienstInterface)registry.lookup("Dienst“);
r_Dienst.methode();
Beispiel: Entwicklung einer RMI-Applikation
Schritt 1: Server-Interface
Definition des lokalen und des remote Protokolls (lokale und remote Methoden) Dies geschieht
durch Angabe des „Marker“ Interface „Remote“. Das Interface Remote enthält keinerlei Methoden;
es kennzeichnet das Interface RMIServer als ein Remotes. Jede Remote Methode muss die
RemoteException werfen (können), da bei der Kommunikation diverse Fehler passieren können.
Beispiel:
package rmiInterfaces;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface RMIServer extends Remote {
// Methoden des Servers, die remote
// ausgeführt werden können
void setString(String str) throws RemoteException; //Funktion die wir anbieten möchten.
}
Schritt 2: Server-Implementation
Implementieren des lokalen und des remote Protokolls (lokale und remote Methoden) im Server (in
den Server-Klassen)
Beispiel:
package rmiServers;
import java.net.MalformedURLException;
import java.rmi.Naming;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.server.UnicastRemoteObject;
import rmiInterfaces.RMIServer;
public class RMIServerImpl extends UnicastRemoteObject implements RMIServer {
public RMIServerImpl() throws RemoteException { // Konstruktor
try {
// Registry starten
try {
LocateRegistry.createRegistry(1099);
System.out.println( "[Server]Die Registry wurde kreiert");
} catch (RemoteException e) {
System.err.println(
"[Server]Registry konnte nicht "+ "gestartet werden...");
e.printStackTrace();
}
// Registrieren des Servers bei RMIRegistry
Naming.rebind("rmi:///Server", this);
System.out.println("[Server]Server gebunden");
} catch (MalformedURLException e) {
// Wenn die URL falsch angegeben wurde ...
System.out.println("[Server]URL ungültig:\n" + e.getMessage());
}
}
// Methode, die remote ausgeführt werden kann
public void setString(String str) {
// Ausgabe des vom Client gesendeten Strings
System.out.println("[Server]"+str);
}
public static void main(String[] args) {
try {
// Instanziieren des Remote-Objektes // den Rest haben wir im den Konstruktor
RMIServerImpl server = new RMIServerImpl();
} catch (RemoteException e) {
// Wenn Remote-Objekt nicht erzeugt werden kann ...
System.out.println( "[Server]Fehler beim Instanziieren des "
+ "Remote-Objektes:\n" + e.getMessage());
}
}
}
Schritt 3: Client-/Server-Stub generieren
- Übersetzen der Server Klasse(n), des Interfaces
- Gegebenenfalls generieren von Stub (Client-seitige Proxy-Objekte) und Skeleton (Server-seitige
Proxy-Objekte) aus der ServerImpl.class mithilfe des rmic (RMI Compiler) aus J2SDK1.x...\bin (In den
neueren Java-Versionen >1.5 werden diese Klassen mithilfe von Inspection (in Java Reflection
genannt) automatisch generiert (und nicht physische abgespeichert).)
Schritt 4: Client erstellen
Entwickeln und übersetzen des Clients (anhand des server-seitigen Interfaces NICHT Server-seitiger
Klassen)
Beispiel:
package rmiClients;
import java.net.MalformedURLException;
import java.rmi.Naming;
import java.rmi.NotBoundException;
import java.rmi.RemoteException;
import rmiInterfaces.RMIServer;
public class RMIClient {
public static void main(String[] args) {
try {// Suchen des Servers in RMIRegistry
System.out.println("[Client]RMI Registry Lookup");
RMIServer server = // Server INTERFACE
(RMIServer) Naming.lookup("rmi://localhost/Server");
// Ausführen einer Methode im Server
System.out.println("[Client]Aufruf der Server Methode");
server.setString("[Client]Hallo Server");
} catch (NotBoundException e) {...
} catch (MalformedURLException e) {
} catch (RemoteException e) {}
}
}
Schritt 5: Registry starten
Starten der RMI Registry
-In der Regel wird diese als Standalone Programm gestartet.
-Sie muss im selben Verzeichnis gestartet werden, in dem sich die Server Klassen befinden
Die Registry hat die Funktion eines „Lookup-Servers“
- Server trägt die verf. remote Objekte (Servants) dort unter einem festgelegten Namen ein.
-Der Client erhält darüber Zugriff auf das remote Objekt
In unserem Beispiel gehen wir einen andern Weg und starten die Registry direkt aus dem Server mit:
// Registry starten auf dem Port 1099
LocateRegistry.createRegistry(1099);
06 Indirekte Kommunikation – Messaging
Definition
Geschieht über einen Vermittler
Es findet in der Regel keine direkte Kopplung des Consumers an den Producer der Nachricht
statt
Modell-Ansatz
Wir können die Kommunikation räumlich und zeitlich betrachten
In beiden Dimensionen können Systeme gekoppelt oder entkoppelt sein
Räumlich
o Gekoppelt: der Sender und der Empfänger sind eng aneinander gekoppelt
o Entkoppelt: der Sender und der Empfänger brauchen sich nicht zu kennen
Anwendungsfälle
Zuverlässige Verteilung von Information an mehrere Kunden.
Kollaborative Anwendungen
Fehlertolerante Anwendungen
System Überwachung z.B. Lastenausgleich (Load Balancing).
Gruppen-Kommunikation
Empfänger treten einer Gruppe bei:
o wie benötigen eine join()/leave() Operation.
Multicast:
o Senden einer Nachricht an eine Gruppe;
Broadcast:
o Senden an «alle» (Radio-Sender);
Unicast:
o Senden an einen bestimmten Empfänger.
Schema:
o meineGruppe.join()
o meineGruppe.send(meineNachricht);
Vorteil:
o Reduzierter Netzwerk-Verkehr
Beispiel: senden eines Videos an Kunden in einem andern Kontinent
Prozess-Gruppen und Objekt-Gruppen
Prozess-Gruppen sind low level Gruppen, bei denen die Kommunikation zwischen Prozessen
einer Gruppe stattfinden.
o Der Level ist fast vergleichbar mit einer einfachen Socket-Kommunikation.
o Die meisten Gruppen-Kommunikationssysteme sind auf dieser Stufe.
Objekt-Gruppen versuchen Marshalling und Unmarshalling und ähnliche Aufgaben zu
übernehmen.
o Diese Art der Kommunikation wurde in einzelnen experimentellen Systemen,
beispielsweise CORBA Erweiterungen, ausprobiert, vor allem im Rahmen von
Forschungsprojekten.
o Eine grössere Verbreitung hat nicht stattgefunden.
Offene und geschlossene Gruppen
Überlappende Gruppen
In überlappenden Gruppen kann ein Mitglied mehreren Gruppen angehören
Synchron und Asynchrone Systeme
Die Gruppen-Kommunikation ist in beiden Kommunikations-Modellen (synchron und asynchron)
möglich.
Implementation
Zuverlässigkeit und Ordnung von Multicast
Zuverlässigkeit bei 1-zu-1 Kommunikation:
o
1.Integrität:
Die versendete und die empfangene Nachricht sind identisch.
o 2.Validität:
Jede ausgehende Nachricht wird eventuell abgeliefert.
o Zuverlässigkeit bei Multicasting Systemen:
1.Integrität
2.Validität
3.Agreement
Falls eine Meldung an ein Mitglied der Gruppe ausgeliefert wird,
wird sie an alle Mitglieder ausgeliefert.
Gruppen-Kommunikation bietet in der Regel «geordnetes» Multicasting:
o FIFO Ordnung
First-In-First-Out Auslieferung
Die Nachrichten werden an alle in der gleichen Reihenfolge ausgeliefert.
o Kausale Ordnung
Kausale Abhängigkeiten werden bei der Auslieferung berücksichtigt
(«happended-before» Relation).
o Totale Ordnung
Falls die Nachricht a vor der Nachricht b ausgeliefert wird, dann wird a an
alle vor b ausgeliefert
Mitgliederverwaltung
Service API:
o Gruppen-Mitgliedschaft:
beitreten und verlassen: group.join(), group.leave()
o Fehlerfindung:
Ein Monitor-Prozess überwacht die Erreichbarkeit und Lebendigkeit der
Prozesse in der Gruppe und isoliert allfällig ausgefallene Prozesse, im
Idealfall (oft ist diese Funktion nicht vorhanden).
o Notifikation:
Dieser Prozess informiert die Gruppenmitglieder über allfällige Änderungen
(neues Mitglied, nicht mehr aktives Mitglied, …).
o Adressen-Expansion:
Dieser Prozess sorgt dafür, dass Nachrichten an die Gruppe an alle
Gruppenmitglieder versendet werden.
Dazu muss bekannt sein, wer Mitglied der Gruppe ist.
o Die Gruppenadresse wird "expandiert".
JGroups Toolkit
JGroups ist ein Gruppen-Kommunikations-Tool
o Welches zuverlässig ist
o In Java geschrieben ist und einfach ist (fast wie Sockets).
o Auf IP Multicast aufbaut, aber viele zusatzliche Möglichkeiten und Protokolle einsetzt
(dabei muss Multicast nicht vorhanden sein).
Hauptziele:
o Zuverlässigkeit
Keine Nachrichtenverluste
Zerlegen grosser Nachrichten in kleine und wieder zusammensetzen beim
Empfänger.
Ordnung der Nachrichten nach FIFO (für alle Empfänger)
Atomizität (Nachrichten werden entweder von allen von von keinem in der
Gruppe empfangen).
o Aktive Verfolgung der Gruppen-Mitgliedschaft
Verfolgung der Mitgliedschaften und Notiz bei neuen Mitgliedern.
Management Information über den Channel:
o Mit getView() erhält man die aktuelle Memberliste.
o Mit getState() erhält man den vergangenen Zustand des Channels und als neues
Member könnte man damit erfahren, was bisher geschah.
Building Blocks
o Message Dispatcher
Implementiert blocking/non-blocking Kommunkikation und korrelieren von
Nachrichten
Nachrichten können synchron oder asynchron gesendet werden und falls
nödtig mit Request-Response Korrelation.
o RpcDispatcher
Ist abgeleitet von MessageDispatcher
Seine Aufgabe ist es Methoden aufzurufen und die korrespondierende
Antwort zu erkennen
Der RpcDispatcher korreliert also Request-Response
Methodenaufrufe: der Message Dispatcher korreliert Nachrichten
Channels
Der Protokoll-Stack wird gestartet sobald eine Applikation sich mit dem Channel verbindet
und zerstört, sobald der Channel geschlossen wird.
Die Architektur lehnt sich an die Gruppen-Kommunikations-Systeme Horus und Ensemble an:
man kann von Layer zu Layer wechseln.
o Jeder Protokoll-Layer bietet zwei Methoden an:
public Object up(Event evt);
public Object down(Event evt);
Die Protokoll-Layer:
o UDP : ist in der Regel der eigentliche Transport-Layer.
o FRAG : ist für das Packaging verantwortlich;
o MERGE: ist für das Zusammenfassen mehrerer Sub- Netzwerke zuständig.
o GMS: ist für die "Group MemberShip" verantwortlich;
o CAUSAL: ist für die Paketordnung zuständig.
JGroups Toolkit Codebeispiel
Producer
Consumer
Publich-Subscribe System 1:n
Publisher:
o Publizieren strukturierte Ereignisse an einen Ereignis-Service.
Subscriber:
o Interessieren sich für bestimmte Ereignisse und abonnieren diese.
Beispiel:
o Ereignis = Netzwerk-Dienst (Badge-System) nicht verfügbar
o Ereignis Notifikation: das System warnt Subscriber und informiert diese, sobald das
Problem behoben ist.
Typische Kennzeichen / Eigenschaften
o Heterogen:
Die Infrastruktur kann ohne grössere Probleme sehr heterogen sein.
o Asynchron:
Ereignisinformationen werden sofort generiert, oft später gelesen.
Beobachter-Objekte übernehmen wichtige Aufgaben:
o Weitergabe (Ereignisdienst wird entlastet.
o Benachrichtigungsfilter
o Ereignismuster:
Der Subscriber kann mithilfe eines Ereignismusters festlegen, welche
Nachrichtenklassen übermittelt werden.
o Benachrichtigungs- Mailboxen
Publisher
Sobald ein Ereignis e eintritt, wird dieses publiziert: publish(e);
Falls der Publisher zukünftige Ereignisse bereits voranmelden kann, wird eine Methode
advertize(f) und unadvertize(f) benötigt.
Subscriber
Interessierte melden sich (eventuell mit einem zusätzlichen Filter) beim Publisher an:
subscribe(f) (f steht für Filter).
Falls der Empfänger nicht mehr an den Nachrichten interessiert ist, kann er sich abmelden:
unsubscribe(f):
Idealerweise verfügt das System über einen Callback Mechanismus: notify(e);
Varianten
Channel-basiert; Topic-basiert
Content-basiert; Typen-basiert
Message Queues 1:1 (P2P)
Producer:
o Sendet eine Nachricht an die Warteschlange: send();
Receiver:
o Empfängt die Nachricht, indem er sie aus der Warteschlange liest
o Drei Lösungsansätze:
Blockierendes Lesen:
Der Receiver wird solange blockiert, bis die Nachricht in der
Warteschlange ist.
o Nicht-blockierendes Lesen: polling
Überprüfen der Warteschlange, ob eine Nachricht eingetroffen ist.
Lesen der Nachricht oder einer Meldung, dass nichts da ist.
o notify():
Messaging
einem Messaging Service
dieser Service umfasst: den Message Server (auch Message Router oder Message Broker
genannt), administrierte Objekte (typischerweise Topics und Warteschlangen, aber auch
Channels) und ein Message Protokoll Kommunikation geschieht asynchron!
Clients
Messages
Daten Distributions Architekturen
Da jeder Prozess eine Verbindung mit jedem andern Prozess hat, kann jeder Prozess
Informationen von einem andern Prozess lesen oder schreiben.
Eine Applikation in einem solchen Umfeld muss also geöffnete Dateien für jeden andern
Prozess besitzen.
Dies generiert einen entsprechenden Overhead, das System wird anfällig und ist komplex.
Virtuell vollverknüpfte Netzwerke
Java Message Systeme implementieren virtuelle, vollverknüpfte Netzwerke.
JMS nimmt der Applikation die Aufgabe ab, die Verbindungen der Prozesse untereinander zu
regeln. Dies geschieht mit Hilfe eines eigenen speziellen Prozesses, dem Router, der die
Verbindungen aufrecht erhält und managed.
Ein Anwendungsprogramm hat somit nur noch eine einzige Verbindung – mit dem Java
Message Router.
Damit reduziert sich die Komplexität und erhöht sich die Performance.
Kommunikations-Pattern P2P
Kommunikations-Pattern Publish-Subscribe
Kommunikationsmodelle
Message-Struktur
Header (zwingend)
Properties (Erweiterungen des Headers) (optional)
Body (zwingend)
Message Selektor
Ein JMS Message Selector erlaubt es einem Client mit Hilfe des Message Headers zu
spezifizieren, an welchen Messages er interessiert ist.
o Nur Nachrichten, deren Header und Properties dem Selektor entsprechen, werden
abgeliefert.
o Dabei muss der Begriff "nicht abgeliefert" geklärt werden:
es werden nur jene Nachrichten akzeptiert, bei denen die Header und
Property Felder mit jenen des Selektors identisch sind.
Message Selector Syntax
o Der Message Selektor ist eine Zeichenkette String, deren Syntax auf einem Subset
von SQL92 Conditional Expression Syntax basiert
Einfacher Queue Sender und Receiver – Codebeispiel
Publish Suscribe Codebeispiel
Message Delivery
NON_PERSISTENT Mode : Vorteil dieses Modus ist der geringe Overhead. Die Nachrichten
werden nicht gelogged oder gespeichert. Falls ein JMS Provider ausfällt, kann eine solche
Meldung verloren gehen.
PERSISTENT Modus : instruiert den JMS Provider, dass dieser sich darum kümmern muss,
dass die Nachrichten nicht verloren gehen. Der JMS Provider muss solche Nachrichten auch
garantiert maximal einmal abliefern. Eine Nachricht kann also verloren gehen, darf dann aber
garantiert nur einmal abgeliefert werden. Ein JMS Provider muss eine PERSISTENT Message
einmal-und-nur-einmal abliefern. Dadurch wird die Performance verschlechtert.
Distributed Shared Memory
Parallelisierungs-Anwendungen
Multiprozessor-Anwendungen
JavaSpaces
Verteilter, gemeinsam genutzter „dynamischer Speicher“
hilft ein Netzwerk von (J)VMs zu föderieren
erlaubt eine einfache dynamische Persistenz / Speicherung
basiert auf dem verteilten Transaktionsprotokoll
benutzt verteilte Lease und Ereignis-Protokolle
Eigenschaften von Spaces
o mehrere entfernte Prozesse können mit einem Space kommunizieren
o Spaces sind persistent
o Spaces sind assoziativ
o Transaktionen sind safe
o Spaces erlauben den Austausch ausführbarer Inhalte
Elementare Operationen von Spaces
o write()
o read()
o take()
o notify()
o Das Modell
Definitionen
Spaces
o sind Speicherbereiche für Objekte (rein passive Daten)
Entries
o sind Objekte, die mit einem Space in Kontakt treten können
Templates
o
sind spezielle Entry Objekte, die zur assoziativen Suche in Spaces eingesetzt werden
können.
Voraussetzungen
o Java Virtual Machine
o Jini Technologie (Starter Kit)
o Java Spaces Technologie (Java Spaces Technology Kit)
JavaSpaces ist ein Jini Service (net.jini.space)
Spaces erlauben nur folgende Operationen
o read, readIfExists
o take, takeIfExists
o notify, snapshot, write
JavaSpace Codebeispiel
Transaktionen
JavaSpaces verwendet den Jini Transaktionsmanager:
o two phase commit (2PC) Protokoll
o implementiert das ACID Prinzip
atomar
consistent
isolation
durability
o Space koordiniert nebenläufige Zugriffe
Synchronisation wird von Space erledigt.
JavaSpaces
o speichert (passiv) Java Objekte
o die Suche geschieht assoziativ
inhaltsbasierte Suche
o soll Netzwerkprogrammierung vereinfachen
08 Verteilte Dateisysteme
Eigenschaften von Dateisystemen / File System Design / Dateisystem
Architektur
Hauptziel: Gemeinsame Nutzung von Ressourcen (also auch Daten, Informationen => Dateiserver)
Dateisystem-Verwendungsstufen
Level 1:
Ein User, ein Prozess greift auf lokale Daten zu
Beispiel:
MS/IBM-DOS ((Disk Operating System)
Themen:
Namensgebung / API / Mapping der Dateiabstraktion / Integrität der Daten
Level 2
Ein User, mehrere Prozess greift auf lokale Daten zu
Beispiel:
MS/IBM-DOS („half an operating system“)
Themen:
Namensgebung / API / Mapping der Dateiabstraktion / Integrität der Daten /
Concurrency (Nebenläufigkeiten)
Level 3
Mehrere User, mehrere Prozess greift auf lokale Daten zu
Beispiel:
Time-Sharing OS, Unix („tu nix mit Unix“)
Themen:
Namensgebung / API / Mapping der Dateiabstraktion / Integrität der Daten /
Concurrency (Nebenläufigkeiten) / Security
Level 4
Mehrere User, mehrere Prozess greift auf verteilte (auf mehreren Rechnern) Daten zu
Beispiel:
Cedar (Xerox), DEC RMS, Sun NFS, CMU Andrew und Coda File System
Themen:
Namensgebung / API / Mapping der Dateiabstraktion / Integrität der Daten /
Concurrency (Nebenläufigkeiten) / Security / File Location und Verfügbarkeit (zudem
Effizienz, Sicherheit und Robustheit)
AIP-Zugriffe:
Zugreiffbar:
Eigentümer / Dateityp / Zugriffskontrolliste
Nicht Zugreiffbar (In der Regel):
Verweisezähler / Attribut-Zeitstempel / Zeitstempel
(CRUD) / Dateilänge
Bsp. Linux
o Open/close/read/write/lseek/unlink/link/stat
Varianten verteilter Dateizugriff
V1:
Transparenter Dateizugriff
o Synonym: Das entfernte Zugriffsmodel
o Client weiss nicht, wo sich die Daten befinden
V2:
Intransparenter Dateizugriff
o Synonym: Das Upload/Download-Zugriffsmodel
o Der Client kopiert manuell vom Server und schiebt
es nach der Verwendung wieder manuell an den
Ursprungsort zurück (veraltet!)
Anforderungen an verteilte Dateisysteme
Transparenz
o System kennt den Unterschied zwischen lokalem und entferntem System nicht.
o Client sieht einen einheitlichen Namensraum
o Programm nach verschieben der Datei ohne Neuprogrammierung lauffähig
o Zugriff / Ort / Mobilität / Leistung / Skalierung
Concurrency / Nebenläufigkeit
o Keine Störung durch multiplen Zugriff
o Lastenverteilung durch Dateireplikation
Offenheit
o Unterstützung diverser HW/SW/OS/Programmiersprachen
Fehlertoleranz
o idempotent: Kontostand(600) -> OK / Einzahlen (100) -> NOK
Wenn etwas ausgeführt wird, muss es auch immer im selben resultieren.
Konsistenz
Sicherheit
o Zugriffskontrolle (Verschlüsselung, Benutzer- ID)
Effizienz
Sun NFS (Network File System)
Architektur
o
o
o
NFS-Server-Modul (Im Kernel)
o Verwaltet Zugriffe
o Anfragen via TCP oder UDP
(Auch verschlüsselt möglich)
Virtuelles Dateisystem
o Einbindung verschiedener Dateisysteme
o Bsp: DateiHandle bei Unix
Client- Integration / Modul
o NFS-Schnittstelle (API)
o Authentifizierung / Caching
Caching (Performancesteigerung)
o
o
o
Client Caching
o Memory Cache + Disk Cache
o Wenn Daten gelesen werden -> Validierung
o Wenn Modifizierung der Daten -> zurück an den Server senden
Dateidelegation (V4)
o
o
o
o
o
Server-Caching
o Read-Ahead -> Lesezugriffe im Voraus ausgeführt
o Buffer-Cache -> Daten bleiben im Cache bis Puffer benötigt wird
o Delayed-Write -> Änderungen werden erst geschrieben, wenn Puffer anderweitig
benötigt wird / Zur Sicherheit werden alle 20 sek Daten auf Disk geschrieben
o Write-Threough -> Schreibbefehle werden vom Cache und Memory und auf Disk
o Commit Write -> ab V.3 -> werden erst bei „Commit“-Befehl geschrieben. (Wie DB)
o
Andrew File System (AFS)
Grundüberlegung: Entgegen einer DB gibt es hier andere „Variablen“. Datei meist klein/ Mehr
schrieben als lesen (1:6) / Meist nur von einer Person verwendet / usw.
Software-Komponenten
o
Vice:
o
Serverprozess auf jedem AFS-Server
o
Venus:
o Entspricht dem Clientmodul des abstrakten
Modell (Läuft auf jedem Client /
Verwaltet Cache)
Callbacks
o
o
o
Damit der Server(Vice) den Client(Venus) über Änderungen informieren kann, wenn ein
anderer Client eine Änderung vorgenommen hat. (callback promise Token)
Zustände der Tokens
o Valid: Datei ist aktuell
o Canelled: Ein Client (Venus)-Prozess hat eine Aktualisierung angefordert
Einsatz des Tokens
o Beim Lesezugtiff prüft der Client den Token. Falls gecancelled= neue Version
anfordern / sonst -> mit der lokalen Kopie arbeiten
o Beim einem Neustart: Der Server prüft dann anhand der Tokens die Aktualität der
Daten.
Sicherheit in AFS
o
o
o
Sicherheitskritische Software läuft lediglich auf den Servern, die als vertrauenswürdig
betrachtet werden.
Zugriffsrechte werden an einzelne Benutzer oder an Gruppen von Benutzern vergeben.
o Ein Benutzer in mehreren Gruppen summiert die Rechte
o Rechte: read, write, lookup, insert, administer, lock, delete
AFS wird standardmässig mit Kerberos gespeichert.
Zusammenfassung
o
Wichtige Entworfspakete
o Effiziente Nutzung des Client-Cachings
o Leistung vergleichbat mit lokalen Dateisystemen
o Konsistenzwahrung
o Wiederherstellung bei Abstürzen und Ausfällen
o Hoher Durchsatz
o Skalierbarkeit
09 Namensdienste
„Namensdienst“ = Dienst, welcher von Clients benutzt wird, um Attribute (Adressen von Ressourcen,
Objekten, Benutzern, …) zu verwalten.
Definitionen
Bindung
Context
Namespace
Verzeichnisdienst
Assoziation eines Namens zu einem Objekt
Ein Set von Namens <-> Objekt Bindungen
Besteht aus den erlaubten Namen des
Namensystems (Bsp: c:\ ist der Namensraum im
Dateisystem, welcher alle Dateien des Laufwerks
c: umfasst)
Erweiterung des Namensdienstes: Stellt
Filterfunktionen und Zuordnungen zur
Verfügung
Alternative Namen
Uniform Resource Identifier
Uniform Resource Locator
Uniform Resource Name
Aliase
URI
URL
URN
Anforderungen an Verzeichnisdienste
-
Verwalten einer grossen Anzahl von Namen
Lange Lebensdauer des Dienstes
Hohe Verfügbarkeit
Isolierung von Fehlern
Tolerierung von Misstrauen
Strategien zur Namensauflösung
Iterativ
Der Client liefert dem Server immer die ganzen Informationen zum Namen. Falls dieser den Namen
nicht auflösen kann, wird der Client zum nächsten Server weitergeleitet und die Anfrage beginnt von
neuem.
Rekursiv
Der Client liefert dem Server den ganzen Namen. Falls dieser den Namen nicht auflösen kann, wird
der Server den nächsten Server kontaktieren und dieser den nächsten Server, bis der Name aufgelöst
werden kann (bis zu einem Max.Hop-Wert).
Server-kontrolliert
Der Server entscheidet selbst, ob er weitere Anfragen Rekursiv oder Iterativ bearbeitet.
DNS
Aufgaben
- Übersetzung Name <-> IP
- Caching der Ergebnisse vorangegangener Abfragen (TTL beachten!)
- Mailhost einer Domäne bestimmen
- Bekannte Dienste auflisten
- Optionale Attribute verwalten
Ressourcen Records
Datensatztyp
A
NS
CNAME
SOA
WKS
PTR
HINFO
MX
TXT
Beschreibung
Computeradresse
Autoritativer Name-Server
Aliasname
Markiert den Anfang der Daten
einer Zone
Bekannte Dienste
Domainnamenzeiger
(umgekehrtes Nachschlagen)
Host-Informationen
Mail
Text
Inhalt
IP
Domainname des Servers
Domainname für Alias
Parameter für die Verwaltung
der Zone
Liste mit Dienstnamen und
Protokollen
Domainname
Host-Architektur und OS
List mit <Prio,Host>-Paaren
Beliebiger Text
Directory-, und Discoveryservices
Directory Service: Liefert ein Set von Namen, welche der vorgegebenen Beschreibung entsprechen.
Discovery Service: Directory + Netzwerkkonfig. Wird automatisch aktualisiert; Clients können sich
spontan vernetzen; Services werden automatisch aktualisiert.
LDAP (Lightweight Directory Access Protocol)
-
Ein Protokoll für Standard und erweiterbare Verzeichnisse.
LDAP ist im ISO/OSI Modell in der vierten Schicht angesiedelt.
Jeder Eintrag ist über einen eindeutigen „Distinguished Name (DN)“ identifiziert
Ein Entry beschreibt ein Objekt in einem LDAP-Directory
Eine Objektklasse enthält zwingende und nicht zwingende Attribute
Beispiel eines LDAP Strings: LDAP://cn=Matter,sn=Mani,ou=Rechtsdienst,o=Stadt Bern,c=ch
Typische Attribute laut RFC2256
Attribut
Bedeutung
C
Country
O
Organisation
Ou
Organisation Unit
Cn
Common Name
Uid
User ID
Sn
Surname
L
Location
Dc
Domain COmponent
Vollständige Liste für Active Directory: http://www.selfadsi.de
Ablauf LDAP Kommunikation
1. Client öffnet Session mit einem Server
a. Spezifikation des Servers
b. Authentifizierung beim Server
2. Absetzen der Operationen
3. Unbinding
Wird die Information beim Lesen nicht in lokalen LDAP-Servern gefunden, so wird auf weitere Server
(referenzierte) ausgewichen.
Schema
Standardisierte Objekte, welche die Zusammenarbeit mit Servern gewährleisten.
-
Stellt eine Sammlung von Strukturdefinitionen dar
o Welche Attribute verwendet werden
o Welche Objekte verwendet werden
o Filter / Matching Regeln
o Welche Berechtigungen nötig sind für die Operationen
JNDI (Java Naming & Directory Interface)
-
Vereinheitlicht den Zugriff auf Verzeichnisdienste.
Teil der Java Standard Edition
Einheitliche API
Beliebiger gerichteter Baum
Jeder interne Knoten repräsentiert einen Context (javax.naming.Context)
Der Context stellt die Methoden zur Verfügung:
-
Bind
Rebind
Lookup
createSubcontext
-
listBindings
10.1 Peer 2 Peer Systeme
-
-
Grosse Anzahl aktiver Teilnehmer
Daten und Ressourcen sind aufgeteilt
Keine dedizierten Server
Skalierbarkeit: P2P ist nicht limitiert durch einen ServiceProvider
Vergleich Client – Server:
o In der Regel hierarchisch (Ein Server, Mehrere Clients)
o Zentrale Zugriffskontrolle
o Zentrales Management
Dynamisch Balanciert
Routing Overlays
-
Ein verteilter Algorithmus für einen P2P-Middleware Layer, der die Anfragen eines Clients an
die unterschiedlichen Hosts weiterleitet
Jeder Knoten kann auf jedes entfernte über mehrere Zwischenknoten zugreifen
Identifizierung über GUIDs (Globally Unique Identifier)
Routing Problem
Ansatz: Jeder Knoten enthält Informationen über die Informationsobjekte, welche redundant sein
können.
API für verteilte Hashtabelle (DHT)
- Put(GUID, data)
o Die Daten werden repliziert abgespeichert, auf allen Nodes welche für die GUID
verantwortlich sind
- Remove(GUID)
o Löscht alle Referenzen
- Value = get(GUID)
o Liefert die Daten von irgend einem Knoten der für die GUID zuständig ist
Replikation (DHT)
- Daten der GUID x werden auf Knoten repliziert, welche nummerisch nahe bei der GUID x sind.
DOLR Api
- Publish(GUID)
o GUID kann aus dem Objekt berechnet werden
- Unpublish(GUID)
o Objekt mit GUID ist nicht mehr verfügbar
- sendToObj(mag, GUID, [n])
o Nachricht an Objekt senden; [n]: die Nachricht wird an n Replikate des Objektes
versendet
Replikation (DOLR)
- Separate Funktion zur Bestimmung der Lokation ausserhalb des Routing Layers
Pastry, Tapestry
- Pastry kennzeichnet jeden Knoten mit einer zufälligen ID (aus zirkulärem ID-Raum)
Routing (Pastry, Tapestry)
- Jeder Knoten kennt L direkte Nachbarn (nummerisch nahe). Diese werden im Leaf-Set
festgehalten
- Jeder Knoten informiert die Applikationen über neue oder nicht mehr erreichbare Knoten
aus seinem Leaf-Set
- Theoretisches Verhalten von 𝑂(log(𝑁)) um in einem Pastry Netz mit N Knoten eine
Nachricht abzuliefern
- Jeder Knoten kann bestimmte Funktionen übernehmen
Zirkuläres Routing
- Punkte repräsentieren aktive Knoten. Knoten 0 und der letzte Knoten (2128 − 1) sind
benachbart
- Eingezeichnet ist das Routing von 65A1FC zu D46A1C (l = 4)
- Algorithmus skaliert schlecht und wird in der Praxis nicht verwendet
Pastry Routing Beispiel
- Routing von 65A1FC nach D46A1C
- Mithilfe einer optimalen Routingtabelle kann die Nachricht nach log16(𝑁) Hops abgeliefert
werden
- Ablauf: 65A1FC => D13DA3; D13DA3 => D4213F; D4213F => D462BA; D462BA => D46A1C
Lokalität in P2P Systemen
-
Ermittlung mittels Netzwerk-Latenzzeiten
Vorteile:
o Das Netzwerk darunter ist nicht 100% zuverlässig; Nahe Knoten sind besser
erreichbar als weiter entfernte
o Nachrichten haben kürzere Wege
o Weniger Bandbreite benötigt
o Nachrichten schneller am Ziel
Lokalität in Tapestry / Tapistry’s Routing Algorithmus
- Existiert von einem Objekt eine oder mehrere Kopien, so wird die nächstgelegene Kopie
retourniert
- Datenobjekte besitzten eine eindeutige Object ID
- Jeder Knoten kann Objekte bereitstellen; Kopien der Objekte können auf mehreren Knoten
vorhanden sein
- Root Node: für jedes Objekt eindeutig bestimmter (berechneter) Knoten welcher das Original
enthält und die Objektverweise auf Kopien verwaltet
- Sucht ein Knoten ein Objekt, schickt er einen Request an den Root Node
- Passiert der Request einen Objektverweis wird der Request dorthin weitergeleitet
- Je näher ein Knoten einer Kopie ist, desto eher kreuzen sie sich (hohe Wahrscheindlichkeit)
10.2 Zeit und globale Zustände
Zeit bzw. eine Uhr ist wichtig, da es eine natürliche Reihenfolge definiert
Uhren, Ereignisse und Prozesszustände
Begriffe
Jeder Prozess p(0i-n) läuft auf einem eigenen Prozessor
Operationen der Prozesse werden Ereignisse genannt
𝐻(𝑡) =Hardwarezeit des Prozessors / 𝐶𝑖 (𝑡) = Uhrzeit intern in Registern/ 𝛼 =ist eine
Skalierung / 𝛽 =ist ein Offset
𝐶(𝑡) = 𝛼 ∗ 𝐻𝑖 (𝑡) + 𝛽
UTC
Koordinierte Universalzeit (UTC) berücksichtigt die schaltsekunden
Signale zur Einstellung stammen von Sateliten (GEOS/GPS/Rundfunksendern
Genauigkeit
o Rundfunk:
+/- 1 msec +/- 10 msec durch atmosphärische Störungen
o Sateliten:
GEOS:
+/- 1 msec
GPS:
+/- 1 msec
Synchronisierung physischer Uhren
Externe Synchronisation
o Zeit-Synchronisation via externer Ressource, wie Zeitserver
o Falls gilt |𝑆(𝑡) − 𝐶(𝑡)| < 𝐷 für alle i und eine Referenzzeit 𝑆(𝑡), dann sind die Uhren
der Prozesse 𝐶𝑖 genau innerhalb des Grenzwerts D
Interne Synchronisation
o Uhren in einem verteilten System untereinander ohne Bezug auf eine Referenzzeit
synchronisiert.
o In diesem Fall messen wir lediglich die Differenzen |𝐶𝑖 (𝑡) − 𝐶𝑗 (𝑡)| < 𝐷 die Uhren
stimmen innerhalb des Grenzwerts D überein.
o Interne Synchronisation impliziert nicht externe!
Cristian‘s Methode zur Synchronisation von Uhren
o Da RoundtripZeit relativ klein und bei hin und Rückweg ca. gleich gross ist, wird
einfach die Zeit + die halbe RoundTripZeit genommen.
o Zeitschätzung
o
𝑇𝑟𝑜𝑢𝑛𝑑𝑇𝑟𝑖𝑝
2
Realistisch geschieht die Übertragung in der Zeit zwischen „min“ und „max“
Aus Serversicht
S kann frühestens zum Zeitpunkt 𝑡𝑃𝑟𝑜𝑧𝑒𝑠𝑠 + 𝑚𝑖𝑛 (𝑡𝑃𝑟𝑜𝑧𝑒𝑠𝑠 =
𝑆𝑒𝑛𝑑𝑒𝑧𝑒𝑖𝑡𝑝𝑢𝑛𝑘𝑡 [𝑣𝑜𝑛 𝑃𝑟𝑜𝑧𝑒𝑠𝑠 𝑃] 𝑣𝑜𝑛 𝑚𝑟 𝑎𝑛 𝑑𝑒𝑛 𝑆𝑒𝑟𝑣𝑒𝑟 𝑆) seine Zeit in
eine Antwortnachricht legen und 𝑚𝑡 senden.
S muss spätestens zum Zeitpunkt 𝑡𝑟𝑒𝑐𝑒𝑖𝑣𝑒 − 𝑚𝑖𝑛 (𝑡𝑟𝑒𝑐𝑒𝑖𝑣𝑒 =
𝐸𝑚𝑝𝑓𝑎𝑛𝑔𝑠𝑧𝑒𝑖𝑡𝑝𝑢𝑛𝑘𝑡 [𝑏𝑒𝑖𝑚 𝑃𝑟𝑜𝑧𝑒𝑠𝑠 𝑃] 𝑣𝑜𝑛 𝑚𝑡 ) seine Zeit in eine
Antwortnachricht legen und 𝑚𝑡 senden.
Die Zeit auf S beim Empfangen von 𝑚𝑡 in P liegt also im Intervall
𝛥𝑇 = [𝑡𝑆𝑒𝑟𝑣𝑒 𝑟 + 𝑚𝑖𝑛, 𝑡𝑆𝑒𝑟𝑣𝑒𝑟 + (𝑇𝑟𝑜𝑢𝑛𝑑𝑇𝑟𝑖𝑝 – 𝑚𝑖𝑛)]
P setzt seine Zeit auf 𝑇 = 𝑡𝑆𝑒𝑟𝑣𝑒𝑟 +
Genauigkeit:
𝑇𝑟𝑜𝑢𝑛𝑑𝑇𝑟𝑖𝑝
+/- (
2
– 𝑚𝑖𝑛) (die Hälfte des Intervalls
Δ 𝑇: 𝑇𝑟𝑜𝑢𝑛𝑑𝑇𝑟𝑖𝑝 – 2 𝑚𝑖𝑛).
o Diskussion:
Interne Uhr (10^-8) muss um ein Vielfaches genauer sein, als die Laufzeit
durchs Netzwerk (1-10 msec)
Die Laufzeit im Netz muss kurz gegenüber der geforderten Genauigkeit sein.
(z.B. Laufzeit bei 1-10 msec, Genauigkeit von 1 sec)$
Berkeley Algorithmus (interne Synchronisation)
o Berkeley (UNIX) Algorithmus (1989): Ein Rechner ist der Koordinator:
Zeit-Server (= Koordinator) fragt periodisch alle Rechner nach ihrer Uhrzeit
Aus den geschätzten + der lokalen Zeiten wird das arithmetische Mittel
gebildet. Die jeweiligen Abweichungen vom Mittel werden als neuer
aktueller Uhrenwert den Rechnern zurückgesendet
Network Time Protocol NTP
o Hohe Zuverlässigkeit (durch Fehlertoleranz): Redundante Server
o Hohe Verfügbarkeit: Sind auf hohe Zugriffszahlen ausgelegt
o Schutz gegen Verfälschungen: z.B. Authentifizierungstechniken
o Primary Server (PS) besitzen UTC-Empfänger
o Secondary Server werden von PS synchronisiert
o Die Blätter bestehen aus Workstations
o Genauigkeit nimmt von oben nach unten ab
o SyncModi (alle verwenden UDP-Transportprotokoll)
MultiCast-Mode
Für schnelle lokale Netze / nur geringe Genauigkeit / keine Infos über
Laufzeiten / Server schickt periodisch aktuelle Zeit per Multicast
Procedure-call-mode
Ähnlich wie christian’s Alforithmus / Wir eingesetzt, falls Multicast zu
ungenau, oder nicht möglich / erzielt mittlere Genauigkeit / Server
beantwortet Zeitanfragen mit aktuellem Zeitstempel
Symmetric-mode
zur Synchronisation zwischen Zeit-Servern (erzielt hohe Genauigkeit)
/ auf anderer Ebene, falls hohe Genauigkeit gefordert /
Wechselseitiger Austausch von Zeitstempeln. / Messen der
Netzwerkverzögerung und Uhrengenauigkeit
o Abgesehen von Multicast werden Nachrichten in Paaren ausgetauscht.
Logische Zeit und logische Uhren
Wenn zwei Ereignisse 𝑒𝑖1 𝑢𝑛𝑑 𝑒𝑖2 𝑖𝑚 𝑃𝑟𝑜𝑧𝑒𝑠𝑠 𝑝𝑖 𝑎𝑢𝑓𝑡𝑟𝑒𝑡𝑒𝑛, 𝑠𝑡𝑒ℎ𝑒𝑛 𝑠𝑖𝑒 𝑖𝑛 𝑒𝑖𝑛𝑒𝑟 𝑅
𝑒𝑙𝑎𝑡𝑖𝑜𝑛 →𝑖 (𝑒𝑖1 →𝑖 𝑒𝑖2 ) Mit anderen Worten. Das Senden der Nachricht GESCHIET VOR (HappendBefore) dem Empfangen der Nachricht.
Lamport
Bei dem Lamport-Algorithmus wird also genau nach dem Schema 𝐿𝑖 =
max(𝐿𝑖(𝐴𝑏𝑠𝑒𝑛𝑑𝑒𝑛) , 𝐿𝑘(𝐸𝑚𝑝𝑓𝑎𝑛𝑔𝑒𝑛) ) + 1 vorgegangen.
Bsp: bei Zahl 34 max(33, (25+5=)30)+1 = 33+ 1 = 34
Aus a vor b folgt C(a) vor C(b) // ABER ACHTUNG // Aus C(a) vor C(b) folgt NICHT a vor b
VektorZeit
Da das oben beschriebene Problem besteht, wird mit der VektorZeit versucht dieses Problem zu
lösen.
Die Vektorzeit charakterisiert die Kausalbeziehung in dem Sinne, dass Ereignisse, die in einer
Kausalrelation stehen, auch bezüglich der Vektorzeit geordnet sind, und dass bezüglich der
Vektorzeit geordnete Ereignisse auch in einer Kausalrelation stehen.
Die Vektorzeit bildet die aufgrund des lokalen Wissens „beste Schätzung“ der globalen
Reihenfolgeverhältnisse.
Die Vektorzeit liefert nicht mehr Informationen über zeitliche Zusammenhänge, als
Lamport‘s Zeit!
Globale Zustände
Im Weiteren konzentrieren wir uns auf die Lamport Halbordnung.
Beispiele wo der globale Zustand eine wichtige Rolle spielt:
Garbage Collectors (Welche Objekte löschen)
DeadLock
Terminierung
Schnappschuss - Algorithmus
Startzustand
P1 -> Konto: 1000$, Waren: 0
wobei bereits 5 Bestellt
und bezahlt!
P2 -> Konto 50$, Waren: 2000
P2 verkauft Ware, 10$ das Stück, P1
kauft. P1 bestellt 10 Waren bei P2
Sendet Marker zusammen mit
Auftrag (10, 100$)
P2 sendet die 5 Waren der
vorangegangen vor der Ankunft des
Markers.
Gleichzeitig ist der neue Auftrag noch
in der „Pipeline“
Beim Eintreffen notiert P2 den
Zustand <50, 1995>
- P1 empfängt nun zuerst die 5 Waren
und
anschliessend
die
Markernachricht M von P2.
- P1 weiss damit, dass die
Aufzeichnung abgeschlossen ist.
- P2 hat zwar auf c2 nach der MarkerNachricht noch die Bestellung
empfangen. Aber gemäss Algorithmus
wurde diese Nachricht aufgezeichnet
(sie fand nach dem Cut statt).
Der Algorithmus terminiert, wenn der aussende Prozess alle Marker der anderen Prozesse erhalten
hat. Voraussetzung: Alle Prozesse müssen erreichbar sein und in endlicher Zeit reagieren.
Anderer Ansatz zur Darstellung des Ablaufes bei der globalen Zustandsfindung
Es ist nicht möglich den Zustand aller Geräte gleichzeitig zu bestimmen! Weil:
o Es gibt keine globale Uhr.
o Zufällige Verzögerungen im Netzwerk.
Deterministisches Verhalten Es ist jederzeit bekannt, welches Ereignis das nächste ist.
Nicht-Deterministisches Verhalten Der Zeitablauf erlaubt mehrere Varianten/Folgezustände.
Deterministisch
Producer code
while (1)
{
produce m;
send m;
wait for ack;
}
Gibt also immer eine strikte Abfolge.
Consumer code
while (1)
{
recv m;
consume m;
send ack;
}
Nicht-Deterministisch
Alle Abläufe sind möglich, aber einer davon wird gewählt.
Deterministisches Verhalten:
o Ein lokales Ereignis enthält die Informationen, die für die Bestimmung des globalen
Zustandes benötigt werden.
o Ein Prozess kennt den Zustand eines andern Prozesses/ kann diesen bestimmen
Konsistent
1.
2.
3.
4.
Konsistent, aber
unwarscheinlich
Nicht konsistent.
Q sendet den Marker an p
Q erfasst seinen Zustand Sq1
P erfasst seinen Zustand als Sq2, der Kanalzustand {} ist noch leer.
Q empfängt m3, m3 ist der Kanalzustand (in-Kanal), m3 fehlt in q und bei p bei dessen
Zustandsaufnahme, m3 ist „in transit“ (im Kanal)
S* ist aus Si erreichbar / Sf ist von S* aus erreichbar
Zusammenfassung
Die Bestimmung des globalen Zustandes ist in verteilten Systemen eine schwierige Aufgabe.
Snapshot Algorithmen liefert nicht genug Informationen, um den globalen Zustand zu bestimmen
11.1 Koordination und Übereinstimmung
Verteilter wechselseitiger Ausschluss
Mehrere Prozesse nutzen Ressourcen gemeinsam -> muss koordiniert werden
Kritischer Bereich: Zeitabschnitt, während dem mehrere Prozesse auf eine gemeinsame Ressource
zugreifen möchten.
Lösungsansatz lokal
Semaphore, Monitore
Lösungsansatz im Netzwerk
Mithilfe von Nachrichtenaustausch
Verteilte Synchronisation
Mutual Exclusion (ME)
Leistungsbewertung der Ausschlussalgorithmen
Verbrauchte Bandbreite für die Koordination
o Proportional zur Anzahl Nachrichten in den enter(), exit() Operationen (wie viele
Nachrichten brauchen wir für die Koordination).
Client-Verzögerung für Ein- und Austritt
o durch die enter(), exit() Operationen
Systemdurchsatz-Auswirkung
o Verzögerungen durch Koordination : t.exit(i) – t.enter(i+1)
Lösungsansatz Zentraler Server
Lösungsansatz Ring
Sicherheit und Lebendigkeit sind erfüllt:
o Sicherheit ist leicht zu sehen: Nur ein Prozess hat das/den Token zur selben Zeit.
o Kein Prozess wird ausgehungert, da die Reihenfolge durch den Ring bestimmt ist.
Die Happened-before Relation ist nicht erfüllt: Maximal muss ein Prozess warten, bis alle
anderen Prozesse einmal im kritischen Bereich waren.
Verlorene Token erfordern Neugenerierung durch Koordinator.
o Verlust eines Tokens ist schwer zu erkennen, da es sich auch um einen sehr langen
Aufenthalt in einem kritischen Bereich handeln kann.
Ricard und Agrawala’s Algorithmus
Abstimmungsverfahren als verteilter, symmetrischer Algorithmus basierend auf Lamport‘s
logischer Zeit, d.h. jeder Prozess besitzt eine logische Uhr.
Prinzip: alle beteiligen Prozesse entscheiden gemeinsam über den Eintritt eines einzelnen
Prozesses in den kritischen Abschnitt
Alle Prozesse verständigen sich über Multicast-Nachrichten.
Annahme: jeder Prozess kennt drei Zustände
o released: Der Prozess befindet sich nicht im kritischen Abschnitt.
o wanted: Der Prozess verlangt den Eintritt in den kritischen Abschnitt.
o held: Der Prozess befindet sich im kritischen Abschnitt.
Nachrichten: zwei Arten von Nachrichten:
o request, beinhaltet eignen (logischen) Zeitstempel und ID
o reply, gibt kritische Region für Anforderer frei.
Beispiel R&A
Multicast Synchronisation Beispiel
Verteilte Lösung Beispiel
Alle drei Basisbedingungen werden erfüllt. Aber:
Der single-point-of-failure wurde ersetzt durch n points-of-failure. Wenn ein Prozess (mit
Warteschlange) nicht mehr arbeitet, funktioniert das System nicht mehr.
o Verbesserung: Dieses Problem könnte durch explizite Verwendung eines RequestReply-Protokolls ersetzt werden (jede Nachricht wird sofort bestätigt). Wenn keine
Bestätigung kommt, ist der Prozess nicht mehr aktiv.
Jeder Prozess muss immer bei der Entscheidung mitwirken, obwohl er evtl. gar kein Interesse
an der kritischen Region hat.
o Verbesserung: eine einfache Mehrheit genügt.
Der Algorithmus ist insgesamt langsam, kompliziert, teuer und wenig robust, aber, wie A.S.
Tanenbaum sagt: „Finally, like eating spinach and learning Latin in high school, some things
are said to be good for you in some abstract way.”
Maekawa’s Algorithmus
Idee
o Jedem Prozess pi wird eine Wählermenge Vi zugeordnet (Vi ist Teilmenge {pi| für
i=1..N})
o pi ist Element von Vi
o Vi und Vj sind nicht disjunkt
o Die Mächtigkeit aller Vi ist gleich K
o pi ist Element von M Vj‘s (M<=N)
o Die Wähler bestimmen, ob pi in CS eintreten darf
Problem
o Bestimmung der Vj
o Der Algorithmus ist Deadlock gefährdet.
Resume
Keiner der beschriebenen Algorithmen toleriert einen Nachrichtenverlust
Prozessabsturz:
Zentrale Lösung: Absturz eines Clients, der das Token weder besitzt noch angefordert hat,
kann toleriert werden.
Verteilte Lösung: Kann Absturz tolerieren, wenn Request-Reply-Protokoll verwendet wird.
Token-Ring: kein Prozess darf abstürzen
Wahlen Algorithmen
In vielen verteilten Algorithmen benötigt man einen Prozess, der eine irgendwie geartete
besondere Rolle spielt, z.B. als Koordinator, Initiator oder Monitor.
Die Aufgabe eines Wahl-Algorithmus (Election-Algorithmen) ist es, einen Prozess unter vielen
gleichartigen Prozessen durch eine kooperative, verteilte Wahl eindeutig zu bestimmen, der
diese Rolle übernimmt.
Die Wahl (Election) wird dabei meist durch die Bestimmung eines Extremwertes auf einer
Ordnung der beteiligten Prozesse durchgeführt:
o Jeder Prozess hat eine Nummer, die allen anderen Prozessen bekannt ist
o Kein Prozess weiss, welcher andere Prozess gerade funktioniert
o Alle Algorithmen wählen den Prozess mit der höchsten Nummer aus.
Nach Ausfall gliedert sich ein Prozess beim Neustart wieder in die Menge der aktiven
Prozesse ein
Voraussetzungen
Leistungsbewertung der Algorithmen
Anzahl Nachrichten für die Wahl
Umschlagszeit : t.abschlussDerWahl() - t.startDerWahl()
Ring Algorithmus
Annahme:
o alle Prozesse haben eine eigene Identifikation
o Prozesse sind in einem gerichteten logischen Ring angeordnet
o jeder Prozess kennt seinen direkten Nachbarn, aber auch die weiteren Knoten des
Rings, so dass er bei Nichterreichbarkeit seines Nachfolgers dessen Nachfolger
adressieren kann.
o alle Prozesse sind aktiv.
o Das System ist asynchron.
o Es treten keine Fehler auf.
Es werden zwei Sorten Nachrichten verschickt:
o election: Auslösen der Wahl
o coordinator: Mitteilung, wer der neue Koordinator ist
Ziel
o Wahl des sogen. Koordinators (max Prozess-ID)
Vorgehen
o Jeder Prozess ist zuerst Nichtwähler.
o Jeder Prozess kann eine Wahl veranlassen.
Fall ein Prozess eine Wahl initialisieren will oder muss, sendet er eine
election (Wahl-) Nachricht an seinen Nachbarn. Diese enthält seine Prozess
ID.
Empfänger:
ist die Wahl-Prozess-ID grösser als seine dann sendet er die
Nachricht weiter.
falls kleiner, dann trägt er seine Prozess-ID ein und wird
Wahlteilnehmer
sonst (Prozess-ID auf dem Wahlzettel = eigene Prozess-ID) Prozess
wird zum Koordinator
Probleme
o Fehler-Intoleranz und worst case: O(N) (der Ring-Vorgänger ist Koordinator: alle
werden besucht)
Bewertung
worst case: 2(n-1) Nachrichten:
o n-1 Wahl-Nachrichten
o n-1 Gewählt-Nachrichten
o ein logischer Ring muss aufgebaut werden
Bully-Algorithmus
Ziel: Bei Ausfall des bisherigen Koordinators ist der Prozess zu finden, der noch aktiv ist und den
höchsten Identifikator trägt. Dieser wird dann als neuer Koordinator (Bully = Tyrann) eingesetzt und
allen bekannt gemacht
Der Auswahlalgorithmus wird durch einen beliebigen Prozess P ausgelöst (evtl. sogar nebenläufig!),
z.B. durch denjenigen, der den Ausfall des bisherigen Koordinators bemerkt hat.
Es werden drei Sorten Nachrichten verschickt:
election: Auslösen der Wahl
answer: Bestätigung des Erhalts einer election-Nachricht
coordinator: Mitteilung, dass der Sender der neue Koordinator ist
Algorithmus:
o Wenn ein Prozess feststellt, dass der augenblickliche Koordinator nicht mehr reagiert,
startet er den Auswahlprozess:
o P schickt eine ELECTION Nachricht an alle Prozesse mit höherer Nummer.
o Bekommt er keine Antwort, ist er der neue Koordinator.
o Bekommt er eine Antwort, ist seine Aufgabe erledigt:
o Der Antwortende übernimmt seine Arbeit!
Bewertung
hohe Nachrichtenkomplexität
o worst case O(n2) Nachrichten.
o best case (n - 2) Nachrichten
alle Prozesse mit ihren Identifikatoren müssen allen bekannt sein.
Multicast
IP-Multicast
IP Multicast – eine Implementierung der Gruppenkommunikation
o Basiert auf IP
o Erlaubt das Senden eines einzigen IP Packets an ein Set von Rechnern, welche
zusammen eine Multicast Gruppe bilden (Class D Internet Adresse mit den ersten 4
bits 1110)
o Die Mitgliedschaft ist dynamisch:
o Man kann an eine Gruppe senden mit oder ohne deren Mitglied zu werden.
o Mitglied werden:
Socket tritt einer Gruppe bei (s.joinGroup(group) )
Damit kann der Socket Multicast-Nachrichten der Gruppe erhalten.
o Multicast:
senden eines UDP Datagrams mit einer Multicast Adresse.
o Broadcast:
Senden eines (UDP) Datagrams an alle Prozesse
Multicast Routers
o Lokale Messages nutzen die lokalen Multicast-Möglichkeiten.
o Router optimieren die Multicast-Kommunikation.
Ausfallmodell
o Auslassfehler
Einige, aber nicht alle Mitglieder der Gruppe erhalten die Nachricht
Ein Router kann ausfallen und Nachrichten verloren gehen.
o IP Pakete können in falscher Reihenfolge eintreffen.
Implementierungen: es lassen sich 3 Ordnungsstufen definieren
o FIFO Ordnung, d.h. alle Nachrichten eines Senders kommen bei der Gruppe in der
gesendeten Reihenfolge an: Jeder Sender verwendet (prozessspezifische)
Folgenummern für seine Nachrichten.
o Kausale Ordnung, d.h. FIFO Ordnung und kausal abhängige Nachrichten kommen in
der richtigen Reihenfolge an: Verwendung kausalspezifischer Folgenummern z.B.
durch Vektorzeit.
o Totale Ordnung, d.h. kausale Ordnung und alle anderen Nachrichten werden von
allen Mitgliedern der Gruppe in der gleichen Reihenfolge empfangen: Verwendung
gruppenspezifischer Folgenummern.
Reliable Multicast
Voraussetzungen wie B-Multicast.
Ein Prozess kann immer noch gleichzeitig mehreren Gruppen angehören.
R-Multicast bietet:
o Integrität: Empfängerprozess ist korrekt und Gruppenmitglied, empfangene
Nachricht wurde an Gruppe gesandt, Nachricht wird höchstens einmal zugestellt
o
Gültigkeit: Ein korrekter Prozess, der eine Multicast-Nachricht sendet, erhält diese in
endlicher Zeit zugestellt
o Übereinstimmung: Wenn ein korrekter Prozess eine Nachricht m zugestellt bekommt,
dann erhalten alle korrekten Prozesse der gleichen Gruppe diese Nachricht in
endlicher Zeit zugestellt
Primitive / Basisoperationen
o R-multicast(g, m)
o R-deliver(m)
Beispiel: ISIS Algorithmus
Der Algorithmus verwendet im Prinzip Lamport‘s Zeitstempel:
o Prozess P sendet per Multicast eine Nachricht <m,i>, wobei i ein eindeutiger
Identifier ist (Prozess-ID + Zeitstempel).
o Alle Prozesse fügen die Nachricht in die Hold-Back-Queue ein und antworten mit
einem Vorschlag für eine von ihnen akzeptierte Sequenznummer a.
o P sammelt diese Vorschläge, wählt den höchsten Wert aus (der ist dann sicher von
allen anderen Prozessen noch nicht vergeben) und schickt die Nachricht <i,a> an alle
Prozesse zurück.
o Die Prozesse verwenden a als die neue Sequenznummer für die Nachricht mit
Nummer i.
o Wenn die Nachricht am Anfang der Hold-Back-Queue ist, wird sie zur Delivery-Queue
transferiert.
Konsens und verwandte Probleme
z.B. 2 Ergebnisse für die selbe Aufgabe, es muss entschieden werden was richtig ist.
Definition des Konsens-Problems
o Prozesse pi befinden sich in einem nicht-dedizierten Zustand zi
Jeder Prozess schlägt einen Wert vi aus D vor (i=1,…N)
o Der Prozess wechselt in den dediziertern Zustand zj
Jeder Prozess setzt den Wert einer Entscheidungsvariable di.
di ist fix und darf nicht verändert werden.
o Konsens-Bedingungen:
Terminierung: jeder Prozess setzt irgendwann seine Entscheidungsvariable.
o
Einigung: der Entscheidungswert aller korrekten Prozesse ist gleich: di=dj
falls pi und pj korrekt sind und in den dedizierten Zustand übergegangen sind.
Integrität: wenn alle korrekten Prozesse denselben Wert vorgeschlagen
haben, dann hat jeder pi im dedizierten Zustand diesen Wert gewählt.
Konsensfindung:
Geschieht beispielsweise durch majority-Voting, indem jeder Prozess seine
Entscheidung jedem andern Prozess mitteilt und dann einen
Mehrheitsentscheid akzeptiert.
Byzantinische Generäle
Problemstellung (Lamport)
o Drei oder mehr (byzantinische) Generäle müssen sich darauf einigen anzugreifen
oder sich zurück zu ziehen.
o Einer der Generäle gibt die Befehle / den Auftrag; die andern melden den Auftrag
weiter und führen aus.
o Einer oder mehrere der Generäle handeln „betrügerisch“ (bzw. melden falsche
Bestände):
Es wird ein falscher Befehl weitergegeben.
Falls der Befehl „Angriff“ lautet wird „Rückzug“ weitergemeldet oder
umgekehrt.
Forderungen
o Terminierung:
Irgendwann setzt jeder korrekte Prozess seine Entscheidungsvariable.
o Einigung:
Der Entscheidungswert aller korrekten Prozesse ist gleich (falls pi und pj
korrekt sind, dann gilt di=dj).
o Integrität:
Wenn der Befehlshaber korrekt ist, einigen sich alle korrekten Prozesse auf
den von ihm vorgeschlagenen Wert.
Lösung nach Lamport (1982)
o Jeder General teilt allen andern sein Wissen mit (Truppenstärke und evtl. weitere
Informationen wie „Angriff / „Rückzug“).
o
o
Die Guten sagen die Wahrheit.
Die Bösen sagen irgend etwas.
Jeder General teilt allen andern seine Ergebnisse aus der vorherigen Runde mit.
Jeder General nimmt als i-tes Element seines Entscheidungsvektors die Mehrheit der
gelesenen Werte.
Falls keine Mehrheit bestimmt werden kann, dann wird der Wert auf
„unbekannt“ gesetzt.
Die byzantinischen Systeme setzen synchrone Kommunikation voraus:
o Der Nachrichtenaustausch geschieht in einzelnen Runden.
Fisher et al haben 1985 gezeigt, dass es in asynchronen Systemen nicht möglich ist, Konsens
zu garantieren.
Grund:
o Sie können nicht unterscheiden, ob in einem asynchronen System eine Nachricht
überhaupt nicht eintrifft oder sehr verspätet.
Damit ist eine (schnelle) Entscheidungsfindung nicht mehr möglich.
PAXOS
Voraussetzungen
Safety
o Es kann nur ein Wert ausgewählt werden, welcher vorgeschlagen wurde.
o Es kann nur genau ein Wert ausgewählt werden.
o Ein Knoten / Systemteilnehmer weiss erst dann, dass ein bestimmter Wert gewählt
wurde, wenn dies auch wirklich geschehen ist.
Liveness
o Ein vorgeschlagener Wert wird eventuell ausgewählt.
o Falls ein Wert ausgwählt wurde, kann ein Knoten diesen Wert als den ausgewählten
Wert erkennen.
Agenten-Klassen:
o Das Modell enthält die folgenden drei Agenten-Rollen:
Proposers
Acceptors
Learners
o Die Rollen können alle mehrfach besetzt sein.
o Ein Knoten/Prozessor kann mehr als eine Client Rolle haben, also gleichzeitig
Proposer und Acceptor …. sein.
Algorithmus
Phase 1 (prepare):
o Ein Proposer selektiert eine Proposal Nummer n und sendet einen "Prepare Request"
mit der Nummer n an mindestens ein Acceptor Quorum.
o Falls ein Acceptor einen "Prepare Request" mit einer Nummer n erhält, mit n > als
alle bisherigen Requests, dann antwortet er mit "YES" und verspricht, keinen
weiteren Wert mehr < n zu akzeptieren.
o Falls er bereits einem höheren n' zugestimmt hat, sendet er eine NACK "nonacknowledge" Nachricht.
o Die Antwort-Nachricht enthält den höchsten akzeptierten Wert (n und den
dazugehörenden Wert v).
Phase 2 (accept):
o Sobald der Proposer von den meisten Acceptoren ein "YES" als Antwort bekommen
hat, sendet der Proposer eine "Accept Request" Nachricht an alle Acceptors
zusammen mit <n,v> (höchster akzeptiertes n und zueghörender Wert v).
o Der Acceptor muss diesen Wert akzeptieren, sofern er nicht einem höheren n bereits
zugestimmt hat.
11.2 Petrinetze
Formale Definitionsart, zur Modellierung von nebenläufigen Systemen, mit folgenden Eigenschaften:
-
Aufzeigen von Systemübergängen, bei denen gemeinsame Ressourcen konsumiert und neu
erzeugt werden
Modellierung von räumlicher Verteilung von Ressourcen, Nebenläufigkeit und
(Zugriffs)Konflikte
Intuitive graphische Darstellung
Nebenläufige Systeme
-
Systeme bei denen mehrere Komponenten / Prozesse nebeneinander auftreten und arbeiten
Typischerweise kommunizieren die Prozesse untereinander mit Nachrichten
Nebenläufigkeit versus Parallelität:
o Parallelität:
o
o
2 Ereignisse finden parallel statt, wenn sie gleichzeitig ausgeführt werden
Nebenläufigkeit:
2 Ereignisse sind nebenläufig, wenn sie parallel ausgeführt werden können
(jedoch nicht müssen)
Nebenläufigkeit: der allgemeinere Begriff
Grafische Komponenten
-
Stellen oder Plätze (Kreise):
-
Transaktionen / Transitionen (Rechtecke oder fette Striche):
Kanten / Bögen (Pfeile); Stellen können nur mit Transactions verbunden werden (vice versa):
-
Tokens / Marken (kleine ausgefüllte Kreise):
Statische Modellbildung
Regeln
- Eine Kante verbindet jeweils eine Stelle mit einer Transition (vice versa); niemals zwei Stellen
-
oder zwei Transitionen:
Eine Kante kann ein Kantengewicht haben (wie viele Tokens werden beim Schalten entfernt /
-
hinzugefügt); ist keine Zahl angeben, so ist das Gewicht 1:
Von einer Stelle können beliebig viele Kanten abgehen und eintreffen:
-
Von einer Transition können beliebig viele Kanten abgehen und eintreffen:
Ein Token kann nur auf Stellen verteilt werden; die Verteilung auf die Stellen eines Netzes
nennt man Markierung
Eine Stelle kann beliebig viele Tokens aufnehmen (falls keine Angabe vorhanden)
Dynamische Modellbildung
Definitionen
- Vorbereich: Der Vorbereich einer Transition umfasst alle Stellen, die auf diese Transition
einmünden (Pfeil auf diese Transition)
- Nachbereich: Der Nachbereich einer Transition umfasst alle Stellen, die von dieser Transition
entspringen (Pfeil auf die Stelle von dieser Transition)
- Konzession: Alle Stellen im Vorbereich besitzen mindestens so viel Tokens wie das
Kantengewicht der Kante, welche die Stelle mit der Transition verbindet und das im
Nachbereich keine der Stellen seine Kapazität überschreitet
o Sind beide Bedingungen erfüllt hat die Transition Konzession zum Schalten.
Beispiel Petrinetz
Notation
- Stellen (Kreise): Mögliche Plätze für Ressourcen
- Marken (kleine ausgefüllte Kreise): Ressourcen
- Transitionen (Rechtecke): Systemübergänge
Darstellung einer Transition
-
Vorbedingungen (Marken, die konsumiert werden)
Nachbedingungen (Marken, die erzeugt werden)
Die Entfernung der Marken der Vorbedingungen und Erzeugung der Marken der Nachbedingung
nennt man „Schalten“ / „Feuern“ der Transition.
Beispiel-Simulation
Erste Transaktionen
Die Vorbedingungen für die rote Transition sind erfüllt.
Die Nachbedingungen werden „wahr“
Weitere mögliche Transaktionen
Beispiel: Dining Philosopher
Erklärung, warum zum Teufel aus 3 mach 1 und aus 1 mach 3:
Tranitionen sind aktiv wenn:
-
Auf ALLEN Plätzen im Vorbereich eine Marke liegt.
Auf ALLEN Plätzen im Nachbereich eine Marke aufgenommen werden kann.
Aus obigem Beispiel erfolgt:
Strukturelemente
Löschen von Objekten
Erzeugen von Objekten
Weitergabe / Verarbeitung
Aufspaltung eines Objektes
Verschmelzen von Objekten
Archivierung von Objekten
Reservoir für Objekte
Zwischenablage
Verzweigung / Beginn Nebenläufigkeit
Gemeinsamer Speicher /
Synchronisationsschnittstelle
Strukturkombinationen
Sequenzverarbeitung
Nebenläufigkeit
Synchronisation
Wechselseitiger Ausschluss (Semaphore)
Erreichbarkeitsgraph
Der Erreichbarkeitsgraph bildet alle möglichen Markierungen (Systemzustände) ab, welche ein
System annehmen kann, ausgehend von einem Startpunkt m0. Voraussetzung dafür ist: Das Netz
muss beschränkt sein.
Definition Erreichbarkeit
„Ist vom Startpunkt (m0) eine weitere Markierung (m1) über eine unbestimmte Anzahl
Transaktionen erreichbar, so ist der Punkt erreichbar.“ – Cpt. Obvious
Beispiel Erreichbarkeitsgraph
Petrinetz
Erreichbarkeitsgraph
Beschränktheit
Wenn die Zahl der Tokens in einer Stelle endlich ist. Beispiel einer unendlichen Anzahl:
Die Anzahl Tokens wächst stetig und ist somit unendlich Graph nicht Beschränkt!
Unabhängigkeit
Zwei Transitionen sind unabhängig, wenn sie sich nicht gegenseitig die Tokens im Vorbereich klauen
und nicht um Platz im Nachbereich streiten müssen. Dann gelten die Regeln der concurrency. Sie sind
also Unabhängig.
Konflikt
Eine Transition klaut einer anderen Transition im Vorbereich einen Token, beziehungsweise sie
streiten sich im Nachbereich um einen Platz. Dann liegen diese zwei Transitionen im Konflikt.
Deadlock Situation
Tote, aktivierbare und lebendige Transitionen
-
Tot: T kann nicht aktiviert werden, auch nicht unter Folgetransitionen (hat keinen Pfeil zu
sich)
Aktivierbar: U kann und wird mit einer Folgetransition aktiviert
Lebendig: Die Transition wird in jeder erreichbaren Markierung aktiviert
Petri-Netz als Matrix
-
Die Zeilen entsprechen den Stellen
Die Spalten entsprechen den Transitionen
Nun wird die Matrix aufgebaut und jeweils eine Schaltung abgebildet. Beim Schalten von 𝑇1 nimmt
die Anzahl Tokens in 𝑃1 um 2 ab. Somit wird an Stelle 1,1 „-2“ eingetragen, in 𝑃2 𝑢𝑛𝑑 𝑃4 kommen
jeweils 1 Token dazu Stelle 1,2 = 1 und Stelle 1,4 = 1. Usw.
Invarianten von Netzen
Ist eh nicht prüfungsrelevant; Falls doch noch fertig zusammenfassen. Invarianten wurden
ausgelassen
Standardaufgabe Petrinetze
Zwei Prozesse wollen gleichzeitig auf einen Zeitkritischen Bereich zugreifen; wie modellieren Sie das
am besten in einem Petrinetz?
Ergänzen Sie das folgende Diagramm:
Lösung:
Petrinetze Aufgabe 2
11.3 Messagebased Concurrency
Begriffe
Multiprogramming
Multiprocessing
Distributedprocessing
Syntax
Semantik
1 Prozessor, n Prozesse
n Prozessoren, m Prozesse, gemeinsamer Speicher
n Prozessoren, m Prozesse, über ein Netzwerk
Beschreibt die grammatikalische Struktur eines Programms.
Beschreibt die Bedeutung eines korrekten Programms. (bzw. was das
Programm macht)
Interprozesskommunikation
Sobald mehrere Prozesse am gleichen Bereich arbeiten ist die Interprozesskommunikation gefragt.
Diese geschieht oft mithilfe von Variablen, welche von mehreren Prozessen referenziert werden
('shared variables') oder aber mithilfe von Nachrichtenaustausch ('messaging').
Bei der Prozess-Prozess-Kommunikation benötigen wir eine Synchronisation. Die Prozessausführung
geschieht mit unterschiedlichen Ausführungsgeschwindigkeiten. Die kausale Abfolge von Aktionen
("perform an action" und "detect an action") setzen Existenz einer logischen Zeit voraus.
Semantik
Es gibt 3 Arten von Semantik.
Operationale Semantik Beschreibt WIE ein Konstrukt die Berechnungen durchführt.
Denotationale Semantik Beschreibt WAS am Schluss eines Konstrukts resultiert. Dies wird mithilfe
mathematischer Objekte gemacht.
Axiomatische Semantik Die Bedeutung eines Konstrukts wird mithilfe von Assertions beschrieben:
Vorbedingungen und Nachbedingungen
Unterschied Operationale und Denotationale Semantik
Die denotationale Semantik legt die Bedeutung über den Aufbau von Programmen fest, die
operationale über den Ablauf von Programmen.
Beispiel für die operationale Semantik
Beispiel für die denotationale Semantik
Beispiel 1: (Leere Anweisung =>Verändert den Zustand z nicht)
Beispiel 2: (Nichtleere Anweisung)
Beispiel 3:
Beispiel für die axiomatische Semantik
=> Folgerung: Falls x≥0 ist und y die Wurzel aus x ist, dann muss y*y = x sein.
Hoarsche Regeln für die Axiomatische Semantik
Hoare Regeln haben das Format {P}S{Q} wobei P die Vorbedingungen sind und Q die
Nachbedingungen, beide mit Assertions beschrieben. Das S dazwischen ist der zu beschreibende
Ausdruck.
Kompositions- oder Sequenz-Regel
Bsp:
Auswahlregel (if then else)
Bsp:
Iterationsregel (while-Regel):
Bsp:
Hoarscher Ableitungsbaum
Semantik in Concurrent Programmen
Wenn mehrere Prozesse concurrent ablaufen ist das Resultat ohne Koordination in der Regel
unbestimmt. Den man weiss nicht wann welcher Prozess für wie lange die CPU erhält. Bsp: Setzt ein
Prozess 10mal x=5 und ein anderer jeweils x=x+1 weiss man nicht was am Schluss resultiert.
Mithilfe von Prädikaten können wir bestimmen, ob zwei Prozesse bestimmte Anweisungssequenzen
atomar, unabhängig voneinander (interferenzfrei) ausführen können.
Annahme, wir haben die Prozesse P1 und P2.
P2 hat keinen Einfluss auf P1, falls die Ausführung von P2 (S2) keinen Einfluss auf die Prädikate von
P1 hat.
Aber:
- Die kombinierte Vorbedingung: {x>0 ^ x<0} ist immer false.
- Auch die Nachbedingung von P1 ist nicht erfüllbar, falls P2 ausgeführt wird: Egal ob P2 komplett vor
P1 ausgeführt wird({x>0 ^ x<0}x=-2;{x>0}) oder aber P2 verzahnt mit P1 ausgeführt wird ({x>0 ^
x<0}x=-2;{x=16})
=> Die Assertions werden also in den meisten Fällen false sein.
Grundprobleme bei der Beschreibung von concurrent Systemen:
1.Wie beschreibt man, dass die Ausführung concurrent sein kann?
2.Welchen Synchronisationsmechanismus soll man einsetzen?
3.Welchen Interprozessmodus soll man einsetzen?
Synchronisationsmechanismen
Ansatz CoRoutine
CoRoutinen entsprechen Prozessen, welche mithilfe von resume synchronisiert werden.
Schwachpunkt: CoRoutinen laufen in der Regel nicht concurrent ab.
Programmiersprachen mit CoRoutinen: Simula, Bliss, Modula.
Ansatz Fork... Join
Ähnlich wie bei den CoRoutinen verläuft der Fork, ABER: Die aufrufende und aufgerufene Routine
werden concurrent ausgeführt. Die join Anweisung verzögert dann die Ausführung des Aufrufers, bis
die "Partner"-Routine beendet ist.
Mögliche Probleme: Einsatz von fork…join in bedingten Anweisungen
Programmiersprachen mit fork, join: PL/I, Mesa, Java 7.
Ansatz cobegin...coend
- Die cobegin Anweisung (oder parbegin bei Dijkstra) startet die concurrent Ausführung von
Anweisungen:
cobegin S1|| S2 || S3 || … || Sn coend;
- Damit werden die verschiedenen Si concurrent ausgeführt, wobei Si selber wieder cobegin…coend
Blöcke mit lokalen Deklarationen enthalten können. Das cobegin Statement ended erst, wenn alle Si
beendet sind.
Programmiersprachen mit cobegin.. coend: CSP, Edison, Algol 68.
Anwendung: Betriebsysteme.
Vergleich mit fork…join:
-cobegin..coend ist weniger flexibel
-Anzahl Prozesse in cobegin..coend ist fix und bekannt;
-Prozessverschachtelung in cobegin..coend ist hierarchisch.
Ansatz process
Wenn Routinen als Ganzes concurrent ausgeführt werden können, ist die Beschreibung mit
cobegin..coend bzw. fork..join umständlich. Einfacher ist es die Routine zu kennzeichnen. process ist
ein solcher Ansatz.
Beispiel (Betriebsystem):
program OP_SYS;
… process reader; …cobegin…coend;
process executer;
… process printer;…
end.
Programmiersprachen mit process: Distributed Processes, Concurrent Pascal, Modula, Ada.
Shared Variablen
Mit shared Variablen werden zwei Arten der Interprozess- Kommunikation realisiert:
Mutual Exclusion / gegenseitiger Ausschluss (Mutex):
Eine Programmsequenz muss als Ganzes verarbeitet werden, ohne Unterbruch: die Sequenz
ist ein kritischer Bereich (critical section).
Condition Synchronisation:
Ein von mehreren Prozessen benutztes Datenobjekt ist in einem Zustand, in dem bestimmte
Methoden nicht ausgeführt werden können. (Bsp. Buffer, nur lesen wenn nicht leer, nur
schreiben wenn nicht voll)
Semaphoren
Eine Semaphore ist eine nichtnegative Integer-Variable auf der zwei atomare Operationen P und V
definiert sind.
- P(s) verzögert den Prozess solange bis s > 0 und setzt dann (atomar) s= s - 1; RESERVIERT PLATZ
- V(s) setzt s=s+1 (atomar). GIBT PLATZ FREI
Semaphore sollten fair sein, da P(s) nicht ewig verzögern darf. Zuerst angehaltene Prozesse sollten
als erstes aufgeweckt werden
Conditional Critical Regions CCR
Eine CCR Anweisung verzögert die Ausführung eines Prozesses solange, bis B erfüllt ist. Dann wird S
ausgeführt. Die Berechnung von B und S kann durch andere Prozesse, welche r benötigen, nicht
unterbrochen werden. R ist eine Ressource=> Schwach verbreitet, nicht für
Monitor
Monitore kombinieren Ressourcen und Methoden in einem Konstrukt. Ein Monitor besteht aus
Variabeln (Speicherung Monitorzustand), Initialisierungscode (1*ausgeführt) und aus Prozeduren,
welche den Zugriff auf die Monitor-Ressourcen gestatten.
Dazu gehören zwei Methoden: signal und wait.
-
wait: condition.wait blockiert den Prozess; kontrolliert den exklusiven Zugang zum Monitor.
signal: cond.signal beiwirkt entweder nichts (wenn kein Prozess vor dem Monitor wartet),
oder der Prozess wird kurz angehalten, um einen wartenden Prozess reaktivieren zu können.
Message Passing
Nachrichten basierte Verfahren sind eine Alternative zur Synchronisation mit shared Variablen.
Vorteil: der empfangende Prozess erhält Daten und gleichzeitig wird eine Reihenfolge (senderreceiver) festgelegt. Damit lässt sich die Synchronisation vereinfachen.
Grundoperationen:
-
send expression__list to destination~designator.
receive variable__list from source__designator
Arten des Message-Passing:
-
-
Asynchrones Message Passing: Das Send ist Non-Blocking wenn der Puffer zwischen Sender
und Receiver genügend gross ist. Sollte der Puffer voll sein gibt es die Möglichkeit das
Senden zu blockieren oder aber eine Warnung/Meldung zurückzugeben.
Synchrones Message Passing: Es wird nur gesendet, wenn auch empfangen werden kann, es
ist also blockierend. Damit kennt der Empfänger der Zustand des Senders vor dem
Senden.Der Sender kann aber auch grob abschätzen, in welchem Zustand der Empfänger sein
wird.
Bei den meisten Systemen ist die Empfangsseite mit dem Receive blockierend und wartet auf neue
Daten. Allenfalls ist dies ein separater Thread, oder sogar der einzige Thread, wobei dann der ganze
Empfänger blockiert wäre.
Beispiel
Guarded Command
Ermöglichen elegante Implementierung des Puffers in einem Prozess ; Anweisungsblock wird nur
ausgeführt, wenn die entsprechende Bedingung wahr ist, z.B. zugehörigen receive eine Nachricht
vorliegt. 'guard' ist ein Boole'scher Ausdruck. Falls er true ist, wird das Statement ausgeführt.
Actors (Higher Level Message Passing)
Ursprünglich (1973) am MIT als Modell im Bereich Artificial Intelligence entwickelt, heute ein Modell
zur Untersuchung der theoretischen Grundlagen von nebenläufigen Systemen.
Grundsätzliche Funktionsweise: Actor empfängt eine Nachricht; Actor führt lokale Methoden aus;
Actor kann weitere Actors kreieren; Actor legt Response fest.
Beispiel: Chat
11.4 Modelierung verteilter und mobiler Systeme
Formale Modelle
Konzentration auf das wesentliche, möglichst wenig Grundelemente
Sollen ein theoretisches Verständnis abstrakter Probleme liefern und nich unbedingt
konkrete Beispiele lösen.
Grundlage für sichere Programmiersprachen (was ist zwingend nötig, was überflüssig)
Kann für formale oder automatische Analyse verwendet werden -> Model Checker
Labelled Transition System (LTS)
Operationale Semantik Beschreibung oder Verhaltensmodellierung.
Als gerichteter Graph mit beschrifteten Kanten.
Knoten: Zustände
Kanten: Zustandsübergänge / Transitionen (Eingabe: 𝑖𝑛, Ausgabe: ̅̅̅̅̅
𝑜𝑢𝑡)
Aber kein Endlicher Automat:
LTS haben keine Endzustände
Anzahl Zustände können unendlich sein
Von einem Zustand können unendlich viele Transitionen wegführen
Aktionen können synchronisiert sein
Abbildung 1 Bsp. LTS
Calculus of Communicating Systems (CCS)
“Einfache” Prozessalgebra um Kommunizierende System emit möglichst wenig Grundbausteinen
modellieren und verstehen können.
Alle Komponenten (Menschen, Prozessoren, Kommunikationskanäle, usw.) werden als Agenten
dargestellt. Diese sind BlackBoxes mit Interfaces. Agenten können:
Aufgaben erfüllen (auch parallel)
Miteinander kommunizieren
Sprachelemente:
Agenten: 𝐶𝑀 (Coffee Machine)
Aktionen:
o Observable:
Eingabeaktion: 𝑐𝑜𝑖𝑛
̅̅̅̅̅̅̅̅̅
Ausgabeaktion: 𝑐𝑜𝑓𝑓𝑒𝑒
o Unobservable, silent (Tau-Übergänge): 𝜏
Operatoren:
o Restriction
𝑃\𝑎
o Relabeling
𝑃[𝑓]
o Parallel Composition 𝑃|𝑄
o Choice
𝑃+𝑄
Zündholz
𝑀𝑎𝑡𝑐ℎ ≝ 𝑠𝑡𝑟𝑖𝑘𝑒. 0
Zündholz (Agent Match) ist definiert als System das enzündet wird (Aktion strike) und anschliessend
in den Zustand 0 wechselt. Das Zündholz ist heruntergebrannt und es kann nichts mehr damit
geschehen.
Kaffeemaschine
̅̅̅̅̅̅̅̅̅. 𝐶𝑀
𝐶𝑀 ≝ 𝑐𝑜𝑖𝑛. 𝑐𝑜𝑓𝑓𝑒𝑒
Der Agent CM (Coffee Machine) ist definiert als System, das eine Münze
(Eingabeaktion coin) entgegennimmt, Kaffee ausgibt und sich anschliessend
wieder wie ein Agent CM verhält.
Kaffee- und Teemaschine
̅̅̅̅̅̅̅̅̅. 𝐶𝑇𝑀 + ̅̅̅̅̅
𝐶𝑇𝑀 ≝ 𝑐𝑜𝑖𝑛. (𝑐𝑜𝑓𝑓𝑒𝑒
𝑡𝑒𝑎. 𝐶𝑇𝑀)
Ein Agent CTM, der zuerst eine Münze entgegennimmt und anschliessend entscheidet, ob er Kaffee
oder Tee ausgibt (und sich dann wieder wie ein CTM Agent verhält).
̅̅̅̅̅̅̅̅̅. 𝐶𝑇𝑀2 + 𝑐𝑜𝑖𝑛. 𝑡𝑒𝑎
̅̅̅̅̅. 𝐶𝑇𝑀′
𝐶𝑇𝑀′ ≝ 𝑐𝑜𝑖𝑛. 𝑐𝑜𝑓𝑓𝑒𝑒
Ein Agent CTM‘, der zuerst entscheidet ob er Kaffee oder Tee ausgibt und anschliessend eine Münze
entgegennimmt und das entsprechende Getränk ausgibt.
𝐶𝑇𝑀 ≠ 𝐶𝑇𝑀′
1 Kaffeemaschine + 2 Programmierer
𝑆𝑚𝑈𝑛𝑖 ≝ 𝐶𝑀 | 𝐶𝑆 | 𝐶𝑆′
Ein System mit zwei Programmierer (CS) und einem
Kaffeautomaten (die parallel Arbeiten können).
Restriction
𝑆𝑚𝑈𝑛𝑖 ≝ (𝐶𝑀|𝐶𝑆)\𝑐𝑜𝑖𝑛\𝑐𝑜𝑓𝑓𝑒𝑒
Die Aktionen coin und coffee sind von aussen nicht mehr
sichtbar. Die Kaffeemaschine kann also nur noch vom Agenten
CS benutzt werden.
Relabeling (konkretisierung abstrakter Strukturen)
Abstraktes System (universeller Getränkeautomat):
𝐶𝑉 ≝ 𝑐𝑜𝑖𝑛. ̅̅̅̅̅̅
𝑖𝑡𝑒𝑚. 𝐶𝑉
Konkretisierung:
𝐶𝑀 ≝ 𝐶𝑉[𝑐𝑜𝑓𝑓𝑒𝑒/𝑖𝑡𝑒𝑚]
Parametrisierte Kanäle
𝐴𝑑𝑑𝑂𝑛𝑒 ≝ 𝑖𝑛(𝑥). ̅̅̅̅̅̅̅̅̅̅̅̅̅̅
𝑜𝑢𝑡(𝑥 + 1). 𝐴𝑑𝑑𝑂𝑛𝑒
Automat, welcher die Zahl 1 zum Eingabewert addiert.
CCS to LTS
Gemäss CCS verläuft ein Prozess verschiedene zustände. Die Zustandsübergänge kommen durch
Aktionen zustande.
̅̅̅̅̅̅̅̅̅. 𝐶𝑀
𝐶𝑀 ≝ 𝑐𝑜𝑖𝑛. 𝑐𝑜𝑓𝑓𝑒𝑒
Durch die Aktion coin ergibt sich ein neuer Zustand:
̅̅̅̅̅̅̅̅̅. 𝐶𝑀
𝐶𝑀1 ≝ 𝑐𝑜𝑓𝑓𝑒𝑒
Der entsprechende LTS kann also wie folgt gezeichnet werden:
19 Webservices
Wie kann ich meine Kundenapplikationen warten, ohne FTP verwenden zu müssen?
Ideen:
RPC: viel zu kompliziert (C, C++, …)
ORBA: noch komplizierter!
XML-RPC
Language Mapping
Java Type
Integer
Boolean
Double
byte[]
java.util.Map /Hashtable
Object[], java.util.List/Vector
java.util.Date
XML Tag Name
i4, int
boolean
double
base64
struct
array
dateTime.iso8601
XML-RPC ist zu beschränkt bezüglich Datentypen (XML Schema?).
XML-RPC ist zu ungenau spezifiziert.
Web-Services nächste Phase
Der Zusatz "Web" ist dabei eher sekundär:
o Hauptaspekt der Service Orientierten Architektur (SOA) ist der Service, HTTP wird
lediglich als Basisprotokoll verwendet.
Marshalling / Unmarshalling (die interne/externe Datendarstellung) geschieht mithilfe von
XML.
o XML ist reiner Text (braucht also viel Platz, ist aber leicht lesbar).
SOAP, das Zugriffsprotokoll auf entfernte Objekte Verwendet XML, um Request/Reply
Anfragen in XML darzustellen.
Alle XML Teile werden mithilfe von Schematas definiert.
Der grundlegende Aufbau orientiert sich an bestehenden RPC Ansätzen.
WSDL
Interface Beschreibung:
Web Services werden mithilfe einer speziellen Web Service Description Language (WSDL)
beschrieben.
Aus einer WSDL kann Java Code generiert werden.
Aus einer Service Klasse in Java kann eine WSDL Beschreibung generiert werden.
Registry:
Web Services können in speziellen Repositories beschrieben werden und können dort von
interessierten Clients gesucht und zusammen gestellt werden, Universal Description & Discovery
Interface (UDDI): Services können erfasst und genau auf einem Repository Server mutiert werden.
UDDI
UDDI ist ein Verzeichnis von Web Services.
1. WSDL Beschreibung erstellen
2. Registrierung mittels UDDI API
3. Client: Suchen eines Dienstes mittels UDDI API
4. Bestimmen der WSDL des Dienstes
5. Generieren der Client Message
6. Versenden der Message zum Dienst
Referenzen
Web Services werden mithilfe einer URL identifiziert:
Zum Testen eines Web Services kann man sogar einen Web Browser verwenden!
Ein WS wird über seine URL aktiviert.
Diese ist permanent und wird nicht speziell für den Methodenaufruf instanziert / aktiviert (der Web
Service existiert auch noch nach dem Aufruf).
Web Services werden in der Regel transparent angeboten:
Die XML Darstellung ist für den Benutzer und den Programmierer nicht sichtbar (die Middleware
versteckt die Details vor den Nutzern).
SOAP – Simple Object Access Protocol
SOAP gestattet Request/Reply (C/S) und asynchrone Kommunikation.
XML wird sowohl für die Beschreibung der Daten / Parameter als auch zur Beschreibung der
Kommunikation (SOAP) verwendet.
SOAP kann auf der Basis von HTTP und SMTP (oder sogar TCP, UDP,..) verwendet werden:
Typischerweise verwendet man HTTP für einfache Dienste und SMTP im Falle von
komplexeren Anfragen mit Attachments.
Ein SOAP API (in C, C++, Python, Java, …) gestattet den Einsatz von SOAP ohne sich um die
Details (XML,SMTP, HTTP, …) zu kümmern.
SOAP Nachrichten können auch über Zwischenknoten übermittelt werden und Transaktionen
beschreiben.
SOAP-Anfrage (ohne Header):
SOAP-Antwort (ohne Header):
HTTP POST Request:
Bsp: Tel.Nr. abfrage mit SOAP:
REST Design Pattern
REST steht für Representational State Transfer.
REST basiert auf einem zustandlosen / stateless Client-Server und einem cacheable
Kommunikationsprotokoll, in allen bekannten Fällen also dem HTTP Protokoll.
REST ist ein Architekture Style.
Idee: statt komplexen Mechanismen wie CORBA, RPC oder SOAP setzt man HTTP zur
Kommunikation zwischen Devices ein.
Das WWW ist letztendlich der Prototyp eines HTTP basierten REST Systems.
REST ist eine leichtgewichtige Alternative zu SOAP Web Services und RPC.
Bsp: Telefonnummer-Abfrage mit REST:
http://www.acme.com/phonebook/UserDetails/12345
REST verwendet lediglich eine URL / URI.
Diese wird mithilfe des GET Befehls an den Server geschickt.
REST Adressiert die Ressource direkt; es wird keine Methode aufgerufen.
Analogie:
SOAP verwendet einen Umschlag
REST ist eine Postkarte.
CODE BEISPIELE
Bild Bitweise downloaden und speichern (mit Buffer)
package Vss.W01.U2;
import java.io.BufferedReader;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.URL;
public class URLKlasse {
public static void main(String[] args) throws IOException {
InputStream iStream2 = (new
URL("http://www.spacetelescope.org/static/archives/posters/large/hubble.jpg")).openStream();
byte[] buffer = new byte[1024];
FileOutputStream oStream2 = new FileOutputStream("C:\\Testimage.jpg");
int n=0;
while ((n=iStream2.read(buffer)) != -1) {
oStream2.write(buffer, 0, n);
}
iStream2.close();
oStream2.flush();
oStream2.close();
}
}
Webseite mithilfe der Klassen URL, BufferedReader und
InputStreamReader lesen
package Vss.W01.U2;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.URL;
public class URLKlasse {
public static void main(String[] args) throws IOException {
InputStream iStream = (new URL("http://www.hsr.ch")).openStream();
BufferedReader reader = new BufferedReader(new InputStreamReader(iStream));
String line = null;
while ( (line = reader.readLine()) != null ) {
System.out.println(line);
}
iStream.close();
}
}
JAVA-API
