Kommunikationsmodelle 2

Description

Flashcards on Kommunikationsmodelle 2, created by Julian Rottenberg on 01/07/2018.
Julian Rottenberg
Flashcards by Julian Rottenberg, updated more than 1 year ago
Julian Rottenberg
Created by Julian Rottenberg over 6 years ago
7
0

Resource summary

Question Answer
Auftragsorientierte Modelle (Das Client/Server-Modell) (Terminierungssemantiken)
Auftragsorientierte Modelle (Das Client/Server-Modell) (Fehlersemantiken) (Fehler: Was ist der Grund, wenn ich keine Antwort erhalte?)
Auftragsorientierte Modelle (Das Client/Server-Modell) (Implementierung) - aufbauend auf elementaren send/receive-Operationen - Auftragserteilung -> send/receive-Botschaftenpaar - request/awaitresult-Semantik - Auftragsannahme -> receive/send-Botschaftenpaar -> accept/reply-Semantik
Auftragsorientierte Modelle (Das Client/Server-Modell) (Implementierung) (Bild)
Auftragsorientierte Modelle (Das Client/Server-Modell) (IT-Sicherheitsaspekte des Client/Server-Modells)
Auftragsorientierte Modelle (Das Client/Server-Modell) (IT-Sicherheitsaspekte des Client/Server-Modells) (Nichtverteilte Systeme)
Auftragsorientierte Modelle (Das Client/Server-Modell) (IT-Sicherheitsaspekte des Client/Server-Modells) (Verteilte Systeme)
Auftragsorientierte Modelle (Das Client/Server-Modell) (IT-Sicherheitsaspekte des Client/Server-Modells) (Zugriffsschutz) - Server muss wissen: Wer ist der Client? => Client-Authentisierung
Auftragsorientierte Modelle (Das Client/Server-Modell) (IT-Sicherheitsaspekte des Client/Server-Modells) (Vertraulichkeit, Integrität, Verfügbarkeit der Informationen) - Client muss wissen: Wer ist der Server? => Server-Authentisierung - Kommunikation -> Mithören durch Dritter - Verändern, Verhindern der Kommunikation => Kryptografische Mechanismen
Auftragsorientierte Modelle (Das Client/Server-Modell) (IT-Sicherheitsaspekte des Client/Server-Modells) (Message) - Message: Client/Server-Modelle brauchen viel Hilfe von außen
Auftragsorientierte Modelle (Zusammenfassung (Auftragsorientierte (Client/Server-)Modelle)
Funktionsaufruforientierte Modelle
Funktionsaufruforientierte Modelle (Idee funktionsaufruforientierter Modelle) Adaption des - anwendungsnahen, unkomplizierten und vor Allem - vertrauten Kommunikationsparadigmas an die Eigenschaften verteilter Systeme
Funktionsaufruforientierte Modelle (Technik) Verallgemeinerung der Kommunikationsmuster des - Prozeduraufrufs: Prozedurfernaufrufe (Remote Procedure Call, RPC) - Methodenaufrufs: Methodenfernaufrufe (Remote Method Invocation, RMI)
Funktionsaufruforientierte Modelle (Modellmerkmale) - Rollenmodell: 2 Rollen -> Aufrufer einer Prozedur/Methode -> Ausführer derselben - Datenmodell: Prozedur/Methodenparameter, spezifiziert durch Signaturen
Funktionsaufruforientierte Modelle (Typische Anwendungen)
Funktionsaufruforientierte Modelle (Beispiel 1) (Betriebssystem mit μKern-Architektur) (Grundidee dieser Architekturform) (lediglich elementarste Betriebssystem-Funktionen) - Privilegienmanagement - Isolation (Adressräume) - IPC (RPC)
Funktionsaufruforientierte Modelle (Beispiel 1) (Betriebssystem mit μKern-Architektur) (Grundidee dieser Architekturform) (übrige Funktionen) - Prozessmanagement - Dateisysteme - Kommunikationsmanagement voneinander Isoliert in gering privilegierten Komponenten
Funktionsaufruforientierte Modelle (Beispiel 1) (Betriebssystem mit μKern-Architektur) (Grundidee dieser Architekturform) => Robustheit => Sicherheit => funktionale Skalierbarkeit
Funktionsaufruforientierte Modelle (Kommunikationsoperationen) (Prozeduraufruf)
Funktionsaufruforientierte Modelle (Kommunikationsoperationen) (Prozedurfernaufruf)
Funktionsaufruforientierte Modelle (Beispiel 2) (Kommunikation zwischen Betriebssystemen) (Szenario)
Funktionsaufruforientierte Modelle (Beispiel 2) (Kommunikation zwischen Betriebssystemen) (Das Szenario logisch)
Funktionsaufruforientierte Modelle (Beispiel 2) (Kommunikation zwischen Betriebssystemen) (Softwarekomponenten des Szenarios)
Funktionsaufruforientierte Modelle (Beispiel 3) (Kommunikation in verteilten Anwendungen)
Funktionsaufruforientierte Modelle (Der Fernaufruf) (Verallgemeinerung des (alt)bekannten Prozeduraufrufs)
Funktionsaufruforientierte Modelle (Kommunikationsmuster des Fernaufrufs) (-> Genau wie altbekannt)
Funktionsaufruforientierte Modelle (Implementierung des Fernaufrufs) (-> Anders als altbekannt)
Funktionsaufruforientierte Modelle (Idealvorstellung des Fernaufrufs insbesondere (gegenüber dem Request/Reply-Modell) (Aufruftransparenz) - Typprüfung der Signatur beim Aufruf (Parameter, Funktionswert; statisch und dynamisch) - Kein explizites Parameterübergabemanagement (z.B. Verpacken in Botschaften) - Keine explizite Programmablaufsteuerung (z.B. warten mittels synchroner receive-Operation)
Funktionsaufruforientierte Modelle (Idealvorstellung des Fernaufrufs insbesondere (gegenüber dem Request/Reply-Modell) (Ortstransparenz) - Keine explizite Adressierung der ausführenden Instanz (Server-Id, DNS)
Funktionsaufruforientierte Modelle (Idealvorstellung des Fernaufrufs insbesondere (gegenüber dem Request/Reply-Modell) (Fehlertransparenz) - Keine explizite Fehlerbehandlung
Funktionsaufruforientierte Modelle (Die 7 Plagen verteilter Systeme bei der Herstellung des Ideals)
Funktionsaufruforientierte Modelle (\begin{Ausflug}) (Compiler-Techniken) - zur Implementierung prozeduraler Programmiersprachen: Organisation geschachtelter Prozeduraufrufe
Funktionsaufruforientierte Modelle (\begin{Ausflug}) (Compiler-Techniken) (Ein Problem prozeduraler Programmiersprachen) Aufruf einer Prozedur erzeugt neuen Kontext - an den IN-Parameter von der Aufrufstelle übergeben werden können - aus dem OUT-Parameter an die Aufrufstelle übergeben werden können - aus dem (in der Regel) an die Aufrufstelle zurückgekehrt wird - der prozedurale Variablen besitzt -> dynamisch -> geschachtelt -> rekursiv
Funktionsaufruforientierte Modelle (Aufgabe der Compiler) - Management dynamischer Kontexte
Funktionsaufruforientierte Modelle (Technik) - Einstreuung von Code um einen Prozeduraufruf herum, der dynamisch einen Datenbereich erzeugt mit -> die lokalen Variablen der Prozedur -> die aktuellen IN-Parameter -> Raum für die zu berechnenden OUT-Parameter und den Rueckgabewert - die Rueckkehradresse => Prozeduraktivierungskobjekte (Procedure Activation Records, PARs)
Funktionsaufruforientierte Modelle (Technik) (Alternativen)
Funktionsaufruforientierte Modelle (inside PARs)
Funktionsaufruforientierte Modelle (Quintessenz - \end{Ausflug}) -
Funktionsaufruforientierte Modelle (Quintessenz - \end{Ausflug}) (Der Austausch erfolgt:) - über gemeinsamen Speicherbereich, dem PAR -> möglich, da Aufrufer und Ausführer Adressraum teilen - in einheitlichem Format: sprachspezifisch, eventuell sogar compilerspezifisch -> möglich durch Sprach-/Compilernormierung
Funktionsaufruforientierte Modelle (Quintessenz - \end{Ausflug}) (Anmerkung) - PARs werden oft auch in Prozessorregistern (statt Stack) übergeben -> schneller -> ebenfalls vom Aufrufer und Ausführer gemeinsam genutzt
Funktionsaufruforientierte Modelle (Die 7 Plagen verteilter Systeme) (Plage 1) - Unterschiedliche Programmiersprachen => kein einheitlcihes PAR-Format, d.h. -> unterschiedliche Formate der PAR -> unterschiedliche Datenrepräsentation innerhalb des PAR
Funktionsaufruforientierte Modelle (Die 7 Plagen verteilter Systeme) (Plage 2) - Separate Adressräume => Kein gemeinsamer Speicher, d.h. -> direkter Zugriff auf PAR durch Prozedur i. Allg. nicht möglich (Ausnahme: DSM)
Funktionsaufruforientierte Modelle (Die 7 Plagen verteilter Systeme) (Plage 3) - Separate Prozesse => keine gemeinsame Ablaufsteuerung ("Programmzähler"), d.h. -> Zu Beginn der Prozedurausführung --> Aufrufer muss explizit angehalten werden --> Ausführer muss explizit gestartet werden -> Nach Abschluss der Prozedurausführung --> Ausführer muss explizit angehalten werden --> Aufrufer explizit fortgesetzt werden
Funktionsaufruforientierte Modelle (Die 7 Plagen verteilter Systeme) (Plage 4) - Separate Hardware => Ausfälle (unabhängig voneinander!) werden sichtbar -> des Kommunikationsmediums -> des Aufrufers -> des Ausführers
Funktionsaufruforientierte Modelle (Die 7 Plagen verteilter Systeme) (Plage 5) - Unterschiedliche Hardware => unterschiedliche Speicherabbildung der Datentypen im PAR -> ganze und rationale Zahlen -> Zeichencodierung
Funktionsaufruforientierte Modelle (Die 7 Plagen verteilter Systeme) (Plage 6) - Offene Kommunikationswege => IT-Sicherheit -> Beobachtbarkeit der Kommunikation -> Veränderbarkeit der Kommunikation -> Verhinderbarkeit der Kommunikation -> Identifikation und Authentisierung von Aufrufer und Ausführer
Funktionsaufruforientierte Modelle (Die 7 Plagen verteilter Systeme) (Plage 7) - Lange und schmale Kommunikationswege => Performanz -> Latenzzeiten -> ein Bild als Referenzparamter --> lokal: 4 Byte (32-Bit-Adresse) --> als Parameter eines Fernaufrufs: mehrere Megabyte
Funktionsaufruforientierte Modelle (Gesucht) (Kommunikationsmodell) (mit prozeduraler Aufrufsemantik) - mit prozeduraler Aufrufsemantik -> Aufrufer/Ausführer Rollenmodell -> signaturprüfendes Datenmodell (Typsystem, formale Parameter) -> synchron -> Ausfälle treten nicht auf - und dies implementiert in verteiltem System unter Anwesenheit der 7 Plagen => wird wohl teuer...
Funktionsaufruforientierte Modelle (Ein erster Schritt) (Auf genau die ersten 3 Plagen treffen wir auch beim Aufruf von Betriebssystemdiensten) - werden in prozeduraler Form aufgerufen von Anwendungsprozessen außerhalb des Betriebssystems - sind implementiert und werden ausgeführt innerhalb des Betriebssystems
Funktionsaufruforientierte Modelle (Ein erster Schritt) (Auf genau die ersten 3 Plagen treffen wir auch beim Aufruf von Betriebssystemdiensten) (Prozeduraufrufmodell mit...) - unterschiedlichen Programmiersprachen (Plage 1) - (evtl.) separaten Adressräumen (Plage 2) - (evtl.) separaten Prozessen (Plage 3)
Funktionsaufruforientierte Modelle (Aufruf von Betriebssystemdiensten)
Funktionsaufruforientierte Modelle (Umgang mit den 3 Plagen) (Plage 1)
Funktionsaufruforientierte Modelle (Umgang mit den 3 Plagen) (Plage 2)
Funktionsaufruforientierte Modelle (Umgang mit den 3 Plagen) (Plage 2.2)
Funktionsaufruforientierte Modelle (Umgang mit den 3 Plagen) (Plage 3)
Funktionsaufruforientierte Modelle (Für eine RPC-Implementierung können wir das darauf lernen) (Umgang mit...) - unterschiedlichen Sprachen - unterschiedliche Namensrämen
Funktionsaufruforientierte Modelle (Für eine RPC-Implementierung können wir das darauf lernen) (allerdings noch nicht mit...) - unterschiedlichen Adressräumen (wir haben i. Allg. keinen gemeinsamen Speicher) - unterschiedlichen Prozessen (Ablaufsteuerung)
Funktionsaufruforientierte Modelle (Stubs) (Stubs ("Stummel")) - Stellvertreter einer (woanders implementierten) Prozedur - implementieren Algorithmen zum Umgang mit den meisten der 7 Plagen - rudimentär bereits in libc angetroffen
Funktionsaufruforientierte Modelle (Stubs) (Ziel) (Fernaufrufe wie lokale Prozeduraufrufe aussehen zu lassen) (Aufruftransparenz) - kein explizites Parameterübergabemanagement => PAR-Transport - keine explizite Programmablaufsteuerung => Synchronisation
Funktionsaufruforientierte Modelle (Stubs) (Ziel) (Fernaufrufe wie lokale Prozeduraufrufe aussehen zu lassen) (Ortstransparenz) - keine explizite Adressierung der ausführenden Instanz
Funktionsaufruforientierte Modelle (Stubs) (Ziel) (Fernaufrufe wie lokale Prozeduraufrufe aussehen zu lassen) (Fehlertransparenz) - keine explizite Behandlung von Kommunikationsfehlern
Funktionsaufruforientierte Modelle (Stubs) (Ziel) (Fernaufrufe wie lokale Prozeduraufrufe aussehen zu lassen) (Stubs beinhalten) - Stellvertreter der aufgerufenen Prozedur beim Aufrufer - Stellvertreter des Aufrufers auf der Ausführerseite
Funktionsaufruforientierte Modelle (Stubs) (Ziel) (Fernaufrufe wie lokale Prozeduraufrufe aussehen zu lassen) (Stubs werden)
Funktionsaufruforientierte Modelle (Stub-Aufgaben) (Aufrufer-Stub)
Funktionsaufruforientierte Modelle (Stub-Aufgaben) (Server-Stub)
Funktionsaufruforientierte Modelle (Dynamischer Ablauf eines RPCs)
Funktionsaufruforientierte Modelle (Wo kommen Stubs nun her?) (Aufruf von BS-Diensten: BS-API statisch) - Systemaufruf-"Stubs" (z.B. libc, z.B. Java-Klasse) statisch
Funktionsaufruforientierte Modelle (Wo kommen Stubs nun her?) (Aufruf von RPCs-in beliebigen verteilten Anwendungen) - dynamische, anwendungsspezifische Generierung - Stubs werden von dazu ausgerüsteten Compilern erzeugt
Funktionsaufruforientierte Modelle (Wo kommen Stubs nun her?) (Aufruf von RPCs-in beliebigen verteilten Anwendungen) (Input der Stubgenerierung für eine Prozedur)
Funktionsaufruforientierte Modelle (Beispiel einer (COBRA) IDL Schnittstellendefinition) (Ein einfacher Email-Server mit 2 Prozeduren)
Funktionsaufruforientierte Modelle (Beispiel einer (COBRA) IDL Schnittstellendefinition) (Schematischer Aufbau eines daraus generierten Stubs (C)
Funktionsaufruforientierte Modelle (Beispiel einer (COBRA) IDL Schnittstellendefinition) (Schematischer Aufbau eines Aufrufs (Hinweg))
Funktionsaufruforientierte Modelle (Beispiel einer (COBRA) IDL Schnittstellendefinition) (Schematischer Aufbau eines Aufrufs (Hinweg)) (1)
Funktionsaufruforientierte Modelle (4. Plage: Hardware-Heterogenität) (Problem) (Zeichen, Gleitkommazahlen)
Funktionsaufruforientierte Modelle (4. Plage: Hardware-Heterogenität) (Problem) (ganze Zahlen)
Funktionsaufruforientierte Modelle (4. Plage: Hardware-Heterogenität) (Lösungsalternativen) (Normierung...) - Normierung einer einheitlichen Repräsentation der Datentypen innerhalb einer Botschaft; Normen: -> COBRA Common Data Representation (CDR) -> Sun External Data Representation (XDR) -> XML => nicht immer effizient, da u.U. überflüssige Doppelkonvertierungen
Funktionsaufruforientierte Modelle (4. Plage: Hardware-Heterogenität) (Lösungsalternativen) (Formatbeschreibung in Botschaft) - größere Botschaften - aufwändigeres De-Marshalling
Funktionsaufruforientierte Modelle (4. Plage: Hardware-Heterogenität) (Implementierung) - in den Stubs als Teil der Paramter-Marshallings
Funktionsaufruforientierte Modelle (Stubs und die 7 Plagen: Zwischenstand)
Funktionsaufruforientierte Modelle (Partielle Ausfälle) (Ziel) - Aufrechterhaltung der Illusion "RPC = LPC" auch unter Anwesenheit von -> Kommunikationsausfällen -> Rechnerausfällen
Funktionsaufruforientierte Modelle (Partielle Ausfälle) (Problem) - verteiltes System, mehrere Komponenten, separate Hardware => partielle und unabhängige Ausfälle von Komponenten - zukünftige Computing-Paradigmen: -> hohe Dynamik, Heterogenität, hochgradig Verteiltheit, unkalkulierbare Verfügbarkeit => Ausfälle sind alltäglich
Funktionsaufruforientierte Modelle (Partielle Ausfälle) (i.F. 2 Annahmen)
Funktionsorientierte Modelle (Partielle Ausfälle) (Fehlermodelle) (Fail-stop-Fehler (auch fail-silent)) - Knoten: ausgefallene Knoten stoppen und schweigen für immer - Kommunikation: Botschaften gehen vollständig verloren
Funktionsorientierte Modelle (Partielle Ausfälle) (Fehlermodelle) (Fail-stop-return-Fehler) - ausgefallene Knoten schweigen, können aber ihre Arbeit wieder aufnehmen - Botschaften werden unverändert zugestellt, können aber verzögert werden
Funktionsorientierte Modelle (Partielle Ausfälle) (Fehlermodelle) (byzantinische Fehler) - ausgefallene Knoten verhalten sich chaotisch bis bösartig - Botschaften können verändert, verspätet, gar nicht eintreffen
Funktionsorientierte Modelle (Partielle Ausfälle) (Obere Grenze der Anzahl von Ausfällen) - Ausfalltransparenz ist ein Konsensproblem: -> Aufrufer und Ausführer müssen sich trotz möglicher Ausfälle einig werden --> Prozedur ausgeführt --> Prozedur nicht ausgeführt - Konsensprobleme in verteilten Systemen grundsätzlich nur bei begrenzter Anzahl von Ausfällen lösbar
Funktionsorientierte Modelle (Partielle Ausfälle)
Funktionsorientierte Modelle (Ausfälle: Was kann alles passieren?) (Beispiel: Fernaufruf eines Clients an einen RPC-Server)
Funktionsorientierte Modelle (1. Verlust von RPC-Requests)
Funktionsorientierte Modelle (2. Verlust von RPC-Replies)
Funktionsorientierte Modelle (2. Verlust von RPC-Replies) (Symptom) - Symptom: Antwort des Servers bleibt aus (also dasselbe) => Differenzierung zu Fall (1.) durch Client unmöglich
Funktionsorientierte Modelle (2. Verlust von RPC-Replies) (Auswirkung) - Auswirkung: Server hat Operation ausgeführt (also eine andere) => Erkennen des Fehlers durch Server jedoch sehr teuer, i. Allg. sogar unmöglich
Funktionsorientierte Modelle (2. Verlust von RPC-Replies) (Lösungen) (1. Idempotente Serveroperationen) 1. Idempotente Serveroperationen (=mehrfache Ausführung hat dieselbe Wirkung wie einfache) => einfache Fehlerbehandlung: Client kann RPC beliebig oft wiederholen
Funktionsorientierte Modelle (2. Verlust von RPC-Replies) (Lösungen) (1. Idempotente Serveroperationen) (Beispiele) - Lesen eines Bankkontostandes - Erteilen punktueller Weckaufträge - Löschen von Dateien
Funktionsorientierte Modelle (2. Verlust von RPC-Replies) (Lösungen) (1. Idempotente Serveroperationen) (i. Allg. allerdings nicht erreichbar) - Abbuchung eines Geldbetrags - Erteilen periodischer Weckaufträge - Anhängen von Daten an Dateien
Funktionsorientierte Modelle (2. Verlust von RPC-Replies) (Lösungen) (2. Erkennung von Wiederholungen) (=> Brute-force-Verfahren (teuer, aber unkompliziert)) (Clients nummerieren Aufrufe) - Clients nummerieren Aufrufe -> Wiederholungen erhalten gleiche Sequenznummer
Funktionsorientierte Modelle (2. Verlust von RPC-Replies) (Lösungen) (2. Erkennung von Wiederholungen) (=> Brute-force-Verfahren (teuer, aber unkompliziert)) (Server prüfen Sequenznummern eintreffender Aufrufe) - filtern Wiederholungen heraus - senden dann dem Client Ergebnisse erneut
Funktionsorientierte Modelle (2. Verlust von RPC-Replies) (Lösungen) (2. Erkennung von Wiederholungen) (=> Brute-force-Verfahren (teuer, aber unkompliziert)) (Dazu notwendig) (Server speichern Sequenznummern und Ergebnisse) - zustandsbehaftete Server - teuer - ärgerlich, da fast immer überflüssig - es gibt intelligentere Verfahren
Funktionsorientierte Modelle (3. Server-Ausfall) (1)
Funktionsorientierte Modelle (3. Server-Ausfall) (2)
Funktionsorientierte Modelle (3. Server-Ausfall) (3) (Lösung: Problem bei Fail-stop-return-Fehlermodell) - Lösung -> Server merkt sich Fortschrittlich sämtlicher laufender Operationen (persistentes Log) -> bei Wiederanlauf Recovery --> Rücksetzen sämtlicher nicht abgeschlossener RPC-Operationen - Neubeginn => transaktionale Server
Funktionsorientierte Modelle (4. Client-Ausfall)
Funktionsorientierte Modelle (4. Client-Ausfall) (Lösungsalternativen)
Funktionsorientierte Modelle (4. Client-Ausfall) (2)
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Fehlersemantik) - Spezifikation der Garantien, die einem Aufrufer über die Ausführung der Prozedur auch unter möglichen partiellen Ausfällen gegeben werden => Daraus dann abgeleitet: das Verhalten beider Seiten
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Fehlersemantik) (4 verbreitete Fehlersemantiken) - "maybe" -> Garantien : keine; "nichts genaues weiß man nicht" -> Vorteil: einfache und performante Implementierung - "exactly-once" - "at-least-once" - "at-most-once"
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Fehlersemantik) (exactly-once) (Garantien) - bei Erfolgsrückmeldung: Ausführung exakt 1x - bei Fehlermeldung: gar nicht ausgeführt => bequen (RPC = LPC) => teuer (alles-oder-nichts-Eigenschaft transaktionaler Systeme => nicht grundsätzlich machbar (Konsensproblem, s.o.)
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Fehlersemantik) (exactly-once) (Voraussetzungen) - bekannte obere Grenze der Ausfallanzahl - aufwändiges Transaktionsmanagement (Konsens/Commit-Algorithmen)
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Fehlersemantik) (at-least-once) (Garantien) - bei Erfolgsmeldung: Ausführung mindestens 1x - bei Fehlermeldung: keine, d.h. Ausführung möglicherweise -> gar nicht, partiell, genau 1x, mehrfach/partiell => einfache Fehlerreaktion der Aufrufer: Neusenden
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Fehlersemantik) (at-least-once) (Voraussetzung) - Idempotenz der Serveroperationen
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Fehlersemantik) (at-least-once) (Implementierung) - keine Duplikatfilterung notwendig -> kein Aufwand für Buchführung (Duplikatfilterung, Ergebnisse) -> zustandslose Server, einfacher Umgang mit Serverausfällen => preiswert
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Fehlersemantik) (at-most-once) (Garantien) - bei Erfolgsmeldung: Ausführung genau 1x - bei Fehlermeldung: nicht mehrfach, d.h. Ausführung -> gar nicht, partiell, oder genau 1x => komplexere Fehlerreaktion der Aufrufer: Neusenden mit identischer Kennung
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Fehlersemantik) (at-most-once) (Implementierung) (Aufrufer) - Aufrufer: Management von RPC-Kennungen
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Fehlersemantik) (at-most-once) (Implementierung) (Server) - Server -> Duplikatfilterung => keine erneute Operationsausführung bei Wiederholung des Aufrufs -> Speicherung der Ergebnisse => keine erneute Berechnung, lediglich Neusenden => :) - Idempotenz nicht vorausgesetzt :( - zustandsbehaftete Server => hohe Kosten für Vorsorge zur Ausfallbehandlung: Sequenznummern und Ergebnisse auf persistentem Speicher sichern
Funktionsorientierte Modelle (Fehlersemantiken funktionsaufruforierntierter Modelle) (Beispiel: Stub-Prozeduren mit Fehlersemantik)
Funktionsorientierte Modelle (Zwischenstand: Stubs und die 7 Plagen)
Funktionsorientierte Modelle (Lange Kommunikationswege) (Interessenkonflikt) (Bequemlichkeit; das "Rundum-sorglos-Paket") (Ortstransparenz) - Aufruf einer Prozedur/Methode ohne Kenntnis des physischen Ortes, insbesondere keine explizite Prozedur-/Objektlokalisierung und -adressierung
Funktionsorientierte Modelle (Lange Kommunikationswege) (Interessenkonflikt) (Bequemlichkeit; das "Rundum-sorglos-Paket") (Zugriffstransparenz) - Zugriff auf entfernte Objekte identisch mit dem Zugriff auf lokale Objekte
Funktionsorientierte Modelle (Lange Kommunikationswege) (Interessenkonflikt) (Bequemlichkeit; das "Rundum-sorglos-Paket") (Sprachtransparenz) - anwenderfreundliche Fehlersemantiken
Funktionsorientierte Modelle (Lange Kommunikationswege) (Interessenkonflikt) (Performanz & Echtzeitfähigkeit) - Performanz: Kommunikationsbandbreite und -latenz - Echtzeitfähigkeit: schwer quantifizierbare Latenzschwankungen
Funktionsorientierte Modelle (Lange Kommunikationswege) (Interessenkonflikt) (Performanz) - Einfluss der Kommunikationskosten beim Systementwurf
Funktionsorientierte Modelle (Lange Kommunikationswege) (Interessenkonflikt) (Performanz) (Beschränkung der Bandbreite) - Objektdesign, Schnitstellendesign -> Operationsgranularität (Stub-Durchläufe: viele kleine Aufrufe sind teurer als ein großer) -> Parametervolumen - Platzierung von Objekten mit intensiver Kommunikation "nah" beieinander -> statische Platzierung -> dynamische: Gravitationsmodell, mobile Objekte
Funktionsorientierte Modelle (Lange Kommunikationswege) (Interessenkonflikt) (Performanz) (Latenz) - Objektdesign, Schnittstellendesign -> Objekt- und Operationsgranularität: Zahl der Objektinteraktionen - Platzierung von Objekten mit intensiver Kommunikation "nah" beieinander
Funktionsorientierte Modelle (Lange Kommunikationswege) (Interessenkonflikt) (Performanz) (Einfluss der Kommunikationskosten bei der Implementierung) (Nutzung von Lokalität) - Differenzierung in Stubs zwischen -> lokaler Kommunikation (effizient über gemeinsamen Speicher -> nicht-lokale Kommunikation (teurer, über Botschaften)
Funktionsorientierte Modelle (Lange Kommunikationswege) (Interessenkonflikt) (Performanz) (Einfluss der Kommunikationskosten bei der Implementierung) - Nutzung von Lokalität - problemspezifische Kommunikationsmodelle - professionelle Implementierungen - Berücksichtigung von Eigenschaften der technischen Infrastruktur (Latenz, Bandbreite, Verlässlichkeit, MTU)
Funktionsorientierte Modelle (Lange Kommunikationswege) (Interessenkonflikt) (Performanz) (Fazit) - Bequemlichkeit kostet - Professionalität der Kenntnisse dieser Zusammenhänge entscheidend für Leistungsparameter der entwickelten Systeme
Funktionsorientierte Modelle (Offene Kommunikationswege) (IT-Sicherheit) - sämtliche Aspekte des Client/Server-Modells sind relevant -> gegenseitige Authentisierung von Aufrufer und Ausführer - Autorisierung von Aufrufen - Beobachtbarkeit, Veränderbarkeit, Verhinderbarkeit der Kommunikation
Funktionsorientierte Modelle (Zahltag) (Fernaufrufe gibt es nicht umsonst)
Funktionsorientierte Modelle (Zoo der RPC-Realisierungen) (1)
Funktionsorientierte Modelle (Zoo der RPC-Realisierungen) (2)
Funktionsorientierte Modelle (Zusammenfassung) (Funktionsaufruforientierte Kommunikationsmodelle) -
Funktionsorientierte Modelle (LPC = RPC? => Stubs) (Orts- und Zugriffstransparenz) :) - Adressierung und Lokalisierung - Aufrufsyntax: Parametermarshalling
Funktionsorientierte Modelle (LPC = RPC? => Stubs) (Heterogenität) :) - Sprache, Hardware: standardisierte Datentypenpräsentation - Betriebssystem: Syntax und Semantik der Kommunikationsschnittstelle
Funktionsorientierte Modelle (LPC = RPC? => Stubs) (Kontrollflusssteuerung) :) - synchrone Botschaften
Funktionsorientierte Modelle (LPC = RPC? => Stubs) (IT-Sicherheit) :( - in Stubs i.d.R. nicht vorhanden (anwendungsspezifisch)
Funktionsorientierte Modelle (LPC = RPC? => Stubs) (Fehlertransparenz) :( - in Stubs i.d.R nicht vorhanden (anwendungsspezifisch)
Funktionsorientierte Modelle (LPC = RPC? => Stubs) (Performanz) :( - in Stubs i.d.R. nicht vorhanden (evtl. Optimierung lokaler Aufrufe) (anwendungsspezifisch)
Strombasierte Modelle (Ziel) - Kommunikation großvolumiger Datenströme unter Echtzeitbedingungen
Strombasierte Modelle (Typische Anwendungsszenarien)
Strombasierte Modelle (Rollenmodell) (Quellen) - Produzenten von Datenströmen (bildgebende Geräte, Datenbanken, Sensoren, Software)
Strombasierte Modelle (Rollenmodell) (Filter) - codieren, mischen, vervielfältigen Datenströmen
Strombasierte Modelle (Rollenmodell) (Senken) - Konsumenten von Datenströmen (Anzeigegeräte, Datenbanken, Softwarekomponenten)
Strombasierte Modelle (Rollenmodell) (Bindings) (1)
Strombasierte Modelle (Rollenmodell) (Bild) (1)
Strombasierte Modelle (Rollenmodell) (Bindings) (2)
Strombasierte Modelle (Rollenmodell) (Bild) (2)
Strombasierte Modelle (Datenmodell)
Strombasierte Modelle (Datenmodell) (Fehler- und Terminierungssemantiken) (Fehlersemantiken) - hohes Datenvolumen => Effizienz! => Keine universell gültige Standardreaktion auf Fehler - effiziente Verfahren nutzen Anwendungswissen -> zeitliche Bedingungen -> Eigenschaften des Datenmodells
Strombasierte Modelle (Datenmodell) (Fehler- und Terminierungssemantiken) (Beispiel: Reaktion auf Datenverlust/Verfälschung) (gegeben Garantien? Verlust tolerierbar?) - medizinische Anwendungen: nein - digitales Fernsehen: ja
Strombasierte Modelle (Datenmodell) (Fehler- und Terminierungssemantiken) (Beispiel: Reaktion auf Datenverlust/Verfälschung) (reparierbar?) - Echtzeitbedingungen: ausreichend Zeit? - Nutzbare Redundanz? - Puffert Sender? - Wichtigkeit der Verluste (z.B. I-Frame vs. B-Frame)
Strombasierte Modelle (Datenmodell) (Highlights) (Performanz, Effizienz, Adaptivität) - datenmodellspezisiche Bindings - applikationsspezifische Fehlersemantiken
Strombasierte Modelle (Datenmodell) (Highlights) (Interoperabilität und Heterogenität) - ortsspezifische Komponenten der bindings: Anpassung an -> Programmiersprache -> Betriebssystem -> Hardware (vgl. Stubs, s.u.)
Strombasierte Modelle (Datenmodell) (Highlights) (IT-Sicherheit) - vollständige Kommunikationskontrolle durch Binding - Isolation der Bindings gegenüber Anwendung
Wissensbasierte Modelle (Das EAZ-Szenario) ("Ich möchte morgen meine Emails lesen...")
Wissensbasierte Modelle (Ziel) - Kommunikation von Wissen dorthin, wo es benötigt wird, aber...
Wissensbasierte Modelle (Idee) - Repräsentation von Wissen durch Algorithmen
Wissensbasierte Modelle (Modellvarianten) - Prozessmigration -> Lastausgleich - mobile Agenten -> Data Mining - Applets -> Web - Mobile Objekte -> Ad-hock-Kooperation
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure)
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Die Idee) (Jeder Dienst) - besitzt eine Dienstbeschreibung: Java-Klasse - besitzt eine Bedienungsanleitung: Java-Klasse - ist bei einem Dienstbroker registriert
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Die Idee) (Dienstnutzung) - Browsen der Dienstbeschreibungen im Broker - Abholen der Bedienungsanleitung -> Erzeugen einer individuellen Klasseninstanz -> Einlagern als Dienstproxy in lokale JVM (Java Virtual Machine) - Nutzung der Proxy-Methode
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Die Idee) (Integration neuer Dienste) - Anfertigen von Dienstbeschreibungs- und Bedienungsanleitungsklassen - Information an Broker
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Integration neuer Dienste) (Beispiel
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Registrierung von Diensten) (1. (Neuer) Dienst) - sucht Broker (= "Lookup Service") -> Technik: Multicast
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Registrierung von Diensten) (2. Lookup Service)
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Registrierung von Diensten) (3. Dienst)
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Registrierung von Diensten) (Bild)
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Finden von Diensten) (1. Client) - sucht Lookup Service -> Technik: Multicast
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Finden von Diensten) (2. Lookup Service) - sendet Lookup Service Proxy -> Technik: sendet serialisiertes Java-Objekt (register, lookup, notify)
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Finden von Diensten) (3. Client) - nutzt lookup-Methode zur Übergabe einer formalisierten Beschreibung des gewünschten Dienstes -> Technik: sendet Service-Template-Objekt
Wissensbasierte Modelle (Finden von Diensten) (4. Lookup Service) - sendet an client passende Service-Item-Objekte -> Technik: Dienstproxies mit Methoden zum Nutzen des Dienstes -> Kommuniziertes Wissen --> Methoden, wie Dienste nu nutzen sind
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Finden von Diensten) (Anmerkung) - Im Unterschied zum Client/Server-Modell ist das Kommunikationsmodell zwischen Dienst und Client komplett in der Hand des Proxies
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Finden von Diensten) (Bild)
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Zusammenfassung Jini) (Durch mobile Objekte kommuniziertes Wissen) - Lookup Service Proxy: Methoden zur Nutzung des Lookup Service - Service-Item-Objekte: Beschreibungen und Methoden zur Nutzung von Diensten - Service-Template-Objekte: Beschreibungen von Diensten
Wissensbasierte Modelle (Anwendungsbeispiel: Die Jini-Infrastruktur (Java Intelligent Network Infrastructure) (Zusammenfassung Jini) (Folge: Client muss nicht a priori wissen)
Wissensbasierte Modelle (Rollenmodell) - analog Send/Receive-Modell: Sender, Empfänger
Wissensbasierte Modelle (Datenmodell) - serialisierte Objekte -> mobile Algorithmen -> mobile Objekte -> mobile Agenten -> Applets
Wissensbasierte Modelle (Fehler- und Terminierungssemantiken) - Varianten analog Send/Receive-Modell
Wissensbasierte Modelle (Pros und Kons) (Datenmodell) - hohe Anforderungen an Gemeinsamkeiten der Kommunikationspartner: identische Ablaufumgebung, z.B. JVM
Wissensbasierte Modelle (Pros und Kons) (Datenmodell) (IT-Sicherheit) - Voraussetzungen für Vertrauen in Gastgeber -> Objekt führt Werte mit sich (Informationen, kryptografische Schlüssel - Voraussetzung für Vertrauen in mobiles Objekt -> ist ein fremdes Programm
Wissensbasierte Modelle (Transaktionaler Speicher) (Kontext) - Interprozesskommunikation in Betriebssystemen: gemeinsamer Speicher (Shared Memory) Granularität: Speicherseiten (Variablen, Datenstrukturen, Code)
Wissensbasierte Modelle (Transaktionaler Speicher) (Beispielszenario: Livestreaming)
Wissensbasierte Modelle (Transaktionaler Speicher) (Ausflug: Kommunikation und Synchronisation) (1)
Wissensbasierte Modelle (Transaktionaler Speicher) (Ausflug: Kommunikation und Synchronisation) (2)
Wissensbasierte Modelle (Transaktionaler Speicher) (Die Probleme im Detail) (Problemfelder) (1)
Wissensbasierte Modelle (Transaktionaler Speicher) (Die Probleme im Detail) (Problemfelder) (2)
Wissensbasierte Modelle (Transaktionaler Speicher) (Kritische Abschnitte und wechselseitiger Ausschluss) (Definition)
Wissensbasierte Modelle (Transaktionaler Speicher) (Kritische Abschnitte und wechselseitiger Ausschluss) (Annahmen)
Wissensbasierte Modelle (Transaktionaler Speicher) (Kritische Abschnitte und wechselseitiger Ausschluss) (Lösung: Synchronisationsmechanismen) - Semaphore - Hoare'sche Monitore
Wissensbasierte Modelle (Transaktionaler Speicher) (Kritische Abschnitte und wechselseitiger Ausschluss) ((Binaere) Semaphore: abstrakter Datentyp mit)
Wissensbasierte Modelle (Transaktionaler Speicher) (Kritische Abschnitte und wechselseitiger Ausschluss) (Abstrakte Semantik)
Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren)
Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (1. Problem: Konsistenz des gelesenen Bildes)
Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (2. Problem: Geschwindigkeitsdifferenz (bei einelementigem Puffer))
Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (2. Problem: Geschwindigkeitsdifferenz (bei mehrelementigem Puffer)
Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (Ausflugsende - Zwischenfazit) (Semaphore) - lösen 2 elementare Synchronisationsprobleme paralleler Aktivitäten -> wechselseitiger Ausschluss - unterschiedliche Geschwindigkeiten - erreichen dies durch aktives Warten oder Suspendierung - sind implementiert in den Tiefen des Ressourcenmanagements
Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (Ausflugsende - Zwischenfazit) (Problem) - Semaphore lösen das Problem wechselseitigen Ausschlusses durch Sperren (Sperrsynchronisation) -> Verhinderung paralleler Ablaeufe Damit haben wir heute vermehr ein Problem: Performanz
Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (Ausflugsende - Zwischenfazit) (Motivation)
Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (Ausflugsende - Zwischenfazit) (Ära ist beendet) - praktische Aspekte der Energieverteilung/Wärmeableitung auf Chip(s) -> Limitierung der Steigerung der Taktfrequenz - logische Aspekte der Instruktuionsausführung -> Limitierung spekulativer Ausführung der Instruktionsparallelität
Wissensbasierte Modelle (Transaktionaler Speicher) (Benutzung von Semaphoren) (Ausflugsende - Zwischenfazit) (Leistungssteigerung durch Paradigmenwechsel der Prozessorarchitektur: Multicores) - Paradigmenwechsel der Software notwendig: parallele/verteilte Algorithmen - hochparallele, nicht sperrende Synchronisationsmodelle - Transaktionaler Speicher
Show full summary Hide full summary

Similar

ein kleines Informatik Quiz
AntonS
Kommunikationsmodelle 3 & Programmierparadigmen
Julian Rottenberg
Informatik
Tom Kühling
PHP Grundlagen
chrisi.0605
Wirtschaftsinformatik Teil 2
Sabrina Heckler
Informatik 1 - Einführung
Svenja
Codierung
Tom Kühling
Wirtschaftsinformatik Teil 1
Sabrina Heckler
Einführung in das Studium Informatik
Daniel Doe
Lernplan
Sandra K