3 - J (suc2)

unterschiedliche Hardwarearchitekturen

unterschiedliche Betriebssysteme (Plattformen)

unterschiedliche Programmiersprachen

Damit die Komponenten des verteilten Systems miteinander kommunizieren können, müssen sie alle ein gemeinsames Format für Daten benutzen

Unter marshalling versteht man die Transformation einer beliebigen Nachricht in eine übertragbare Nachricht, wobei

die Datenstruktur in eine zusammenhängende Nachricht "planiert" wird und

die zu sendenden Daten aus dem lokalen in das gemeinsame Format übersetzt werden

Daraus resultiert ein Strom von bytes, welcher übertragen werden kann: eine übertragbare Nachricht

Auf der Seite des Empfängers müssen die empfangenen Daten aus dem gemeinsamen Format in das lokale Format des Empfängers übersetzt werden

Dieser Prozess wird unmarshalling genannt

Unmarshalling wird immer auf der Seite des Empfängers ausgeführt

Vorteile:

direkte Kontrolle aller Transportparameter grössere Flexibilität bei der Entwicklung neuer Protokolle bessere Performance

Nachteile

die Datenrepräsentation wenig komfortable Entwicklung von Anwendungen

Middleware ist eine zusätzliche Schicht, die sich zwischen Transportschicht (TCP/UDP) und Anwendung befindet

Vorteile

Bequeme Entwicklung von Anwendungen Lösung des Datenrepräsentationsproblems Evtl. weitere Dienste „von Haus aus“ verfügbar

Nachteile

Ein (unter Umständen grosser) Overhead muss in Kauf genommen werden Schlechtere Performance im Vergleich zu Socket-Programmierung

Aufruf einer Prozedur, welche sich im gleichen Speicherraum (Prozess) befindet

Keine Interprozesskommunikation mit LPC möglich

Vorteile:

Bessere Performance, da alle Prozeduren im gleichen Prozess bzw. Speicherraum

Zuverlässige Kommunikation

Einfachere Parameterübergabe, da lokaler Stack für alle Prozeduren gemeinsam und verfügbar

Einfacher Zugriff auf gemeinsame Daten, da alle Prozessdaten gemeinsam

Nachteile:

Keine Interprozesskommunikation möglich Folie

RPC steht für den "entfernten Aufruf von Prozeduren„

Mit "entfernt" ist eine Prozedur gemeint, welche

in einem anderen Prozess ausgeführt wird bzw.

sich in einem anderen Speicherraum befindet

Stellt eine Art der Interprozesskommunikation

Die kommunikationswillige Prozesse können

auf dem gleichen System oder

auf unterschiedlichen Systemen ausgeführt werden 

LPC ist einfacher zu implementieren, da sich die ganze Kommunikation (Nachrichtenaustausch) in einem gleichen Speicherraum (gleicher Prozess) abspielt

RPC ist weniger performant Kommunikation erfolgt in Form von Nachrichten, welche von einem zu anderem Prozess übertragen werden Parameter, welche übergeben werden müssen, müssen in die Nachricht passend verpackt werden

RPC ist komplexer in der Implementierung, da zusätzliche Protokolle für das Senden von Nachrichten benötigt

Wie wird eine entfernte Prozedur aufgerufen (mit allem, was dazu gehört: Parameterliste, Rückgabewert)?

Wie werden Fehlersituationen (Exceptions) behandelt?

Die Struktur der Anfrage- bzw. Anwort-Nachricht muss "abgesprochen" werden und darf danach nicht ohne Rücksprache mit der "Gegenseite" geändert werden

Damit soll sichergestellt werden, dass die Kommunikation zwischen beteiligten Komponenten exakt und ohne Missverständnisse realisiert werden kann.

Die Rede ist von Request- und Reply-Protokoll

definiert, wie die Anfrage-Nachricht aufgebaut werden muss

enthält alle für den Aufruf der entferenten Operation relevanten Informationen (den Namen der Methode und die Parmeterliste) in einer passenden Form

hängt im Aufbau (Struktur) von der Operation ab, die aufgerufen werden soll

definiert, wie die Antwort-Nachricht aufgebaut werden soll

enthält alle für die Antwort relevanten Informationen in einer passenden Form:

den Rückgabewert, der von der aufgerufenen Operation retourniert wird

die Informationen über die Ausnahme, die evtl. geworfen werden könnte

ist im Aufbau vom Rückgabewert und Ausnahme, die geworfen werden könnte, abhängig

Pro Operation, die als entfernte Operation aufgerufen werden soll, muss je ein Request- und Reply-Protokoll definiert werden

Erst nach dem die Request- und Reply-Protokoll definiert sind, kann mit der Implementierung der Kommunikation gestartet werden

eine Art der Interprozesskommunikation gemeint, mit der Aufruf von Operationen (Prozeduren) realisiert wird, die sich in einem anderen Prozess befinden

da die aufgerufene Prozeduren nicht im eigenen Prozess (Speicherraum) ausgeführt werden, reden wir von einem entfernten Prozeduraufruf

Verbindung herstellen (connect)

Daten lesen (read) und Daten schreiben (write)

Verbindung abbauen (diesconnect)

Man ist gezwungen, mit Streams zu arbeiten (I/O), was nicht unserer Vorstellung entspricht: für uns ist logischer, die benötigten Methoden direkt aufzurufen.

Stellen wir dem Client eine Komponente zur Verfügung, die im gleichen Prozess ausgeführt wird und als Server aussieht

Diese Komponente muss die gleiche Schnittstelle wie der Server implementieren

Die Rede ist von einem Stub (auch ClientStub, Proxy bzw. Stellvertreter genannt)

Stellen wir dem Server eine Komponente zur Verfügung, die im gleichen Prozess ausgeführt wird und als Client aussieht

Diese Komponente wird die Prozeduren des Servers als lokale Prozeduren aufrufen

Die Rede ist von einem ServerStub (auch Skeleton genannt)

bild

Der ClientStub implementiert die Server-Schnittstelle: so kann der Client alle Methoden des Servers auf dem ClientStub aufrufen

Der ClientStub

nimmt den Aufruf der Server-Methode entgegen, verpackt sie passend (Marshalling) und sendet sie zum Server bzw. zum ServerStub (RPC)

nimmt die Antwort des Servers entgegen, entpackt sie (Unmarshalling) und liefert den Rückgabewert an den Client zurück

Der Server muss alle Prozeduren implementieren, die in der entsprechenden Schnittstelle definiert wurden

Der ServerStub

nimmt die Anfrage, die der ClientStub gesendet hat, entgegen und entpackt sie (Unmarshalling)

ruft die gewünschte Methode auf dem Server auf (LPC) und nimmt die Antwort des Servers entgegen

verpackt die Antwort passend (Marshalling) und sendet sie an den ClientStub zurück

Der ServerStub muss eine Referenz auf den Server haben, um seine Prozeduren aufrufen zu können

Übergabe von Werten (pass by value)

Der Wert wird in die Nachricht entsprechend kopiert

Auf der anderen Seite wird der Wert "rekonstruiert"

Übergabe von Referenzen (pass by reference)

Grundsätzlich nicht möglich

Ausnahme: falls gemeinsamer Speicher vorhanden (shared memory)

Bei einem entfernten Aufruf kann ein Fehler an mehreren Orten passieren:

Bei der Zustellung der Anfrage

Während der Ausführung auf dem Server

Während der Zustellung der Antwort

Idempotente Prozesse dürfen beliebig oft ausgeführt werden Beispiel: das Lesen aus einer Datei

Nicht idempotente Prozesse dürfen nur einmal ausgeführt werden Beispiel: die Überweisung eines bestimmten Geldbetrags von einem auf das andere Konto)

Performance:

RPC ist langsamer als LPC Antwortzeiten hängen auch von der Belastung des Netzwerks stark, die sich ständig ändert

Sicherheit

Daten (Nachrichten) werden im Netz übertragen uns sind somit angreifbar Probleme mit Authentifizierung von Kommunikationspartner

bild

Streamsockets (auch TCP-Sockets genannt)

Datagramsockets (auch UDP-Sockets genannt)

TCP-Sockets sind verbindungsorientiert (TCP)

Phasen der Datenübertragung:

Aufbau der Verbindung Übertragung von Daten Abbau der Verbindung

Daten, welche übertragen werden, werden

in einen Datenstrom geschrieben, und am Zielort

aus dem Datenstrom (in gleicher Reihenfolge) gelesen

Die Server-Anwendung arbeitet mit der Klasse ServerSocket, welche alle für einen Server notwendigen Funktionalitäten enthält

Die Client-Anwendung arbeitet mit der Klasse Socket

UDP-Sockets sind nicht verbindungsorientiert

Daten werden in Pakete geschrieben

Datenpakete könne maximal 8 KB gross sein (Header- und Nutzdaten zusammen)

Grössere Nachrichten müssen in der Anwendung segmentiert bzw. reassembliert werden

Die Ankunft von Datenpaketen wird nicht bestätigt

Es kann passieren, dass manche Datenpakete nicht ans Ziel kommen Folie

Multicast-Sockets

Vorteile

sehr gute Performance

Protokolle können frei nach Bedarf implementiert werden, wodurch Anpassungen bzw. Optimierungen möglich sind

Nachteile

Sockets eignen sich für reine Datenübertragung

Sockets sind nur die Schnittstelle zur Transportschicht

Bieten keine Unterstützung für Kommunikationssteuerung und Datendarstellung

Protokolle müssen auf der Anwendungsebene implementiert werden um Kommunikationspartner zu finden und Austausch von Nachrichten zu steuern

Eigenschaften der Transportschicht sind zu berücksichtigen (TCP/ UDP)

Programmierung relativ aufwendig und fehleranfällig

aufwendig und fehleranfällig

es müssen einige technische Aspekte berücksichtigt werden, die mit eigentlichem Anwendungsproblem nichts oder nur wenig zu tun haben  

Dies kann zu einem erheblichen Aufwand bei der Entwicklung einer Anwendung führen

Unter Middleware ist die Software zu verstehen, die zwischen der verteilten Anwendung und der darunterliegenden Schicht steht umd "vermittelt"

die Interaktion zwischen Anwendungskomponenten zu erleichtern, und  

die Komplexität der vernetzten Systemumgebung zu maskieren

wird für den Anwendungsentwickler die Umsetzung der Kommunikation einfacher, wobei

alle Aspekte der Netzwerkprogrammierung so weit wie möglich (und sinnvoll) von der verteilten Anwendung verborgen werden  

Der Anwendungsentwickler kann sich auf die Lösung des eigentlichen Anwendungsproblems konzentrieren