14299781
Description
Flashcards by Julian Rottenberg, updated more than 1 year ago
|
Created by Julian Rottenberg
almost 6 years ago
|
|
| 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 |
Want to create your own Flashcards for free with GoConqr? Learn more.