Verteilte Systeme - Grundlagen

Grundlagen Verteilter Systeme

Ziele der Lektion

1. Erkennen, was über die ”bloße“ Verkabelung von Rechnern hinausgeht
2. Erfahren, welchen Schwerpunkt Middleware dabei besitzt
3. Verteilte Systeme aus Sicht der Systementwicklung beleuchten
4. Ermöglichen, ein verteiltes System zu entwickeln
5. Tieferes Verständnis für verteilte Systeme entwickeln
6. Schwierigkeiten bei der Replikation von Systemen erkennen

Einführung, Konzepte und Technologien

Nach Coulouris et. Al., sozusagen nach der Bibel der Verteilten Systeme kann ein solches definiert werden als:

„Ein Verteiltes System ist ein System in dem (Hardware oder Software) Komponenten in einem Computernetzwerk Ihre Aktionen kommunizieren und koordinieren, einfach durch den Austausch von Nachrichten.“

- Coulouris, Dollimore, Kindberg

oder etwas weniger formell und eher pessimistisch ausgedrückt:

Eine verteiltes System ist eines in dem ich keinerlei Arbeit zustande bringe, weil irgendein mir unbekannter Rechner von dem ich nie gehört habe abgestürzt ist.“

- Leslie Lamport

Verteilte Systeme ergeben sich aus der Notwendigkeit Rechner an unterschiedlichen Standorten miteinender zu verbinden; sie können eingeführt werden, um die Leistung (Performance) eines Server Systems zu erhöhen (siehe Cluster Computing) und sie erfüllen oftmals den Zweck, meist auch auf Server Systemen, Die Fehlertoleranz mit Hilfe von unterschiedlichen Backup Systemen zu gewährleisten.

Verteilte Systeme charakterisieren sich durch parallele Aktivitäten, indem autonome Komponenten gleichzeitig unterschiedliche Aufgaben abarbeiten. Die Kommunikation der einzelnen Komponenten findet statt, indem sie Nachrichten miteinander austauschen. Verteilte Systeme unterscheiden sich somit von Shared Memory Architekturen weil sie auf keinen gemeinsam benutzten Speicher zugreifen (können). Ein Einsatzgebiet von Verteilten Systemen ist auch die gemeinsame Nutzung von Ressourcen oder Geräten wie Drucker, Scanner, Telefonanlagen oder andere.

Dabei besitzt kein einziger Prozess in so einem System das Wissen über den globalen Status des Gesamtsystems. Es gibt auch keine gemeinsamen Zeitgeber, somit nur begrenzte Möglichkeiten die Taktgeber der einzelnen Prozesse zu synchronisieren.

Man unterscheidet bei verteilten Architekturen zwischen Multiprozessor und Multicomputer Systemen. Multiprozessor Systeme besitzen einen gemeinsamen Speicher, wie z.B. die z.Zt. aktuellen dual oder Quad Core Prozessor Architekturen. Multicomputer Systeme besitzen keinen gemeinsamen Adressraum (Speicher) und sind homogen in Hard- und Software aufeinander abgestimmt. Dies können „Massively Parallel Prozessoren (MPP)“ Systeme oder Workstation-Cluster sein. Solche Systeme führen dem allseits bekannten Szenario für Betriebssysteme die in verteilter Umgebung Einsatz finden.

Die größte Bedeutung ist allerdings den heterogenen Multicomputer Systemen zuzuordnen. Diese sollen auch im Rahmen dieses Studienheftes betrachtet werden. Dabei müssen in Bezug auf die Computerpraxis oft folgende Fragen beantwortet werden:

1. Was wenn komplett unterschiedliche Hardware verwendet wird, z.B. Intel CISC vs. PowerPC RISC Chips von IBM?

7. Wie kommunizieren Programme auf unterschiedlichen Betriebssystemen miteinander?

8. Was geschieht, wenn die Daten verschiedener Systeme unterschiedlich repräsentiert werden, z.B. EBCDIC vs. ASCII vs. UTF8 oder LATIN Zeichensätze?

9. Was geschieht oder muss geschehen, wenn Sie Ihr Büro in die Südsee verlegen?

10. Wie behalten sie die Übersicht über die vielen Aufgaben die auf einer Anzahl von Rechnern laufen?

11. Was, wenn zwei Ihrer Kunden gleichzeitig das selbe Produkt bestellen wollen (Concurrency oder Gleichzeitigkeit)?

12. Was, wenn die Datenbank mit den Informationen zu Ihrem Lagerbestand abstürzt?

13. Was, wenn jemand den Stecker zieht während sie im Internet eine Bestellung aufgeben?

14. Was tun, wen jemand in Ihre Server eindringen will?

15. Was, wenn der Kunde behauptet, er hätte gar keine Bestellung aufgegeben?

16. Was, wenn Ihr Laden so berühmt wird, dass Millionen von Kunden zur gleichen Zeit auf Ihre Webseite zugreifen?

All dies lässt sich zu den Herausforderungen der Heterogenität, transparenten Verteilung, Fehlertoleranz, Skalierbarkeit, Gleichläufigkeit, Offenheit und Sicherheit zusammenfassen. Diese müssen von verteilten Systemen im täglichen Gebrauch gemeistert werden.

Kommunikation in Verteilten Systemen

Gegeben sei das Beispiel eines Onlineshops entsprechend dem UML Usecase Diagramm in Abb. 1. Der Benutzer sich (1) das Inventar (alle Waren ansehen), (2) nach bestimmten Waren suchen und (3) Waren bestellen.

Abb. 1. Beispiel eines Use Cases: Kundenzugriff auf Server

Dabei gilt, dass der Online-Store Computer das „Shop-Programm“ und der Kunde das „Shopping-Programm“ einsetzt. Beide Computer sind über ein Netzwerk miteinander verbunden. Die unterschiedlichen Prozesse der Computer tauschen dabei folgende Nachrichten aus:

1. „Sende mir die Warenliste aller Waren“

17. „Hier ist die Liste der Waren: ...“

18. „Ich möchte diese bestimmte Ware bestellen“

19. „Die Bestellung der Ware wurde angenommen“

Abb. 2. Interconnected NETworks

Dabei müssen Sender und Empfänger der Nachrichten sich über bestimmte Dinge einig werden. Dies sind z.B.: Die Art und Weise wie die Nachrichten transportiert werden, Welcher Spannungswert für 1 oder 0 verwendet werden soll, welches das letzte Bit sein soll und was im Fall von Fehlern geschehen muss. Darüber hinaus muss klar sein, welche Bedeutung die Bits haben, also handelt es sich um Text oder Binärdaten, welcher Zeichensatz soll gelten oder gibt es andere speziell zugeschneiderte Formate. Viele andere Vereinbarungen müssen auch noch auf anderer Ebene getroffen werden. Die Summe dieser Vereinbarungen bezeichnet man als Protokoll.

Ein Protokoll ist eine bestimmte definierte Menge von Konventionen die es Computern erlauben Information auszutauschen. Dabei müssen sowohl Syntax und Semantik vereinbart werden. Gemeinsame Regeln müssen eingeführt werden, um die Interaktion zwischen den Computern zu Steuern und Administrieren und es müssen die Formate der auszutauschenden Daten bestimmt werden.

Dabei kann nicht davon ausgegangen werden, dass alle beteiligten Rechner am gleichen Netz angeschlossen sind, viel mehr kommunizieren diese über INTERconnected NETworks, also Computer sind an Netze angeschlossen die wiederum über ein übergeordnetes Netz miteinander verbunden werden. Dadurch entstehen komplexe Interaktionen zwischen und mit verschiedenen Kommunikationsprotokollen (siehe Abb. 2)

Zur Bewältigung dieser Komplexität gibt es mehrere Strategien. Eine Einteilung des Systems in Sub-Systeme (nach dem Motto „Devide et conquere“) kann vorgenommen werden. Dabei werden die zu entwickelnden Komponenten kleiner und können anderweitig wiederverwertet werden. Das System wird leichter wartbar und kann besser portiert werden.

Layered Architektur

Die Einteilung des Systems kann auch in Layern/Leveln und Partitionen vorgenommen werden. Dabei baut ein Layer auf den anderen auf und unterschiedliche Partitionierung eines Layers dient zur Behandlung unterschiedlicher Funktionalitäten.

Wie zu sehen in Abb. 3 werden Layer übereinander gestapelt und mit wohl definierten Schnittstellen (Interfaces) miteinander verbunden. Dabei bietet ein Layer n Services für den darüberliegenden Layer n+1 an indem er seinerseits Services des darunterliegenden Layers n-1 annimmt.

Die Schnittstellen (Interfaces) definieren dabei die Syntax des Service und beinhalten die Namen der zur Verfügung stehenden Funktionen die Namen und Typen von Parametern. Die Typen der Ergebniswerte und eine Definition der möglichen Ausnahmen, ähnlich dem Aufruf einer Funktion oder Methode in einem Programm. Ein wichtiger Aspekt, von dem häufig Gebrauch gemacht wird, ist dabei die Möglichkeit, dass ein bestimmtes Interface mehrmals und auf verschiedne Weise implementiert werden kann. So können logisch identische Funktionalitäten in verschieden ausgeprägtem Umfeld gleichermaßen bestimmt werden. So kann z.B. ein Layer 2 der Daten paketiert mit beliebigen Layer 1 Komponenten zusammenarbeiten, gleich ob diese die Pakete dann über Luft oder Kupfer übertragen.

Die wohl berühmteste Layer Architektur auf dem Gebiet der Computer-Kommunikation ist das sog. ISO/OSI Referenzenmodell. ISO = „International Standard Organization“ und OSI = „Open Systems Interconnect“ haben eine geschichtete Architektur für Netzwerk Protokolle verabschiedet, den sog. „Protokoll-Stack“ (Protokollstapel?). Beim Senden wird dabei der Stapel der einzelnen Layer (Schichten) von oben nach unten durchgegeben, wobei der obere Layer die Daten verändert und/oder erweitert und and den darunter liegenden Layer weitergibt.

ISO/OSI Layer

ATM hier in den 2. Layer zu geben ist eher spekulativ, ursprünglich ware es eher ein Paketnetzwerk auf Layer 1, da es sich wuasio als Draht dargestellt hat, aber wer kümmert sich heute noch um ATM?

Die unterste Schicht versendet dann die Nachricht als physische (elektromagnetische) Signale. Beim Empfang wird der Stapel in umgekehrter Reihenfolge durchlaufen. Die Signale werden vom untersten Layer aufgegriffen und dann Layer für Layer nach oben weitergegeben. Dabei kommunizieren zwei identische Layer auf unterschiedlichen Computern mit demselben Protokoll. Über alle Layer hinweg entsteht somit eine Verschachtelung von Layer- spezifischen Protokollen. Alle sieben Layer sind in Abb. 4 zu sehen.

Die Layer/Schichten im einzelnen:

1. Physical Layer: Zur physikalischen Übertragung der Bits und Bytes, elektronische Signale
2. Data Link Layer: Zum Transport zwischen zwei Punkten im Netzwerk, Media Access Control Prüfsummen Flow-Control etc.
3. Network Layer: End-to-End Datenübertragung zwischen Computern über alle verbundenen Netzwerke, Packet-Forwarding und Routing

4. Transport Layer: End-to-End Datenübertragung zwischen einzelnen Prozessen auf verschiedenen Computern, Ports, Flow-Control

5. Session Layer: Stellt eine virtuelle Verbindung zwischen Prozessen her, Z.B. Auf- und Abbau von Verbindungen

6. Presentation Layer: Definiert, wie die gesendeten oder empfangenen Daten interpretiert werden sollen, d.h. was die 1-en und 0-en bedeuten und in welcher Reihenfolge sie zu lesen sind

7. Application Layer: Die Verbindung zwischen zwei Applikationen, z.B. File Transfer nach OSI etc.

Im Internet hat sich allerdings ein vereinfachtes Modell durchgesetzt, eine vier-schichten Architektur die as ISO/OSI Model vereinfacht, siehe

Die Layer sind:

1. Hosts-to-Network oder PHY Layer: Physikalische Datenübertragung zwischen zwei Stationen
2. Internet oder IP Layer: End-to-End Datenübertragung zwischen Computern über alle Netzwerke hinweg
3. Transport Layer: End-to-End Übertragung zwischen einzelnen Prozessen auf den Computern, z.B. Vom Browser am Client zu Port 80 auf dem Server
4. Application Layer: Appliklationsspeziefische Protokolle wie HTTP oder FTP, SSH etc.

Das ISO/OSI Modell ist definiert und verabschiedet von einem anerkannten Standardgremium. In dem Standard hat das Modell an sich immer Vorrang vor den Protokollen, welche sich in der Regel auf einen bestimmten Layer beziehen und nicht Layer-überschreitend angewendet werden. Ein Layer kann mehrere Protokolle beheimaten. Das Modell ist universell einsetzbar und ist daher sehr Komplex in der Implementierung. Außerdem wurde es vielleicht zum falschen Zeitpunkt, also zu früh, verabschiedet.

Die dargestellten Layer, wie sie im Internet Verwendung finden, sind aus der Erfahrung und der aktuellen Nutzung der Protokolle heraus gewachsen. Vice versa zum ISO/OSI Modell stehen hier die Protokolle im Mittelpunkt und nicht die Kommunikationsschichten (Layer). Das Internet Layer-Modell ist einfach gehalten und daher robust; es existieren viele gut funktionierende Applikationen.

Auch wenn die meisten Applikationen basierend auf dem Internet Modell implementiert werden, so wird doch immer wieder das ISO(OSI Modell herangezogen, um Kommunikationsverfahren zu beschreiben. Man spricht und plant Kommunikation indem man die ISO/OSI Layer referenziert, wenn es dann zur Implementierung kommt werden dann diese Modelle auf das Internet-Kommunikationsmodell reduziert.

Dabei werden Layer 1 und 2 des ISO/OSI Modells, also Physical und Datalink Layer auf den Layer 1 des Internet Modells also auf den Host-to-Network Layer abgebildet. Der Layer 3 des ISO(OSI Modells, also der Network Layer, wird auf Layer 2 im Internet Modell abgebildet, den Internet Layer. Die beiden Transport Layer werden 1:1 zugeordnet, also Layer 4 im ISO/OSI Modell auf Layer 3 im Internet. Die restlichen Layer im ISO/OSI Modell werden im Internet zu dem Application Layer zusammengefasst.

Wie werden nun aber die Daten, auf dem Netzwerk Layer (Layer 3 im OSI Modell) übertragen? Hierbei gibt es zwei grundverschiedene Ansätze, das sog. „Circuit Switching“ (Leitungsvermittlung), also die Leitungsvermittlung und das „Packet Switching“ also die Paketvermittlung.

Die Leitungsvermittlung fand Ihre Anwendungsgebiete bisher immer in der Sprachkommunikation und wird vor allem in der Telekommunikation angewandt. Auch heute in den Zeiten von SIP und IMS wird z.B. die Sprache in einem modernen Mobilfunknetz bis zur Basisstation immer noch leitungsvermittelt (im RAN). Bei der Leitungsvermittlung gibt es eine fest zugeordnete Leitung (entweder einen physikalischen Draht, oder einen fest reservierten Zeitschlitz im Backbone Netzwerk) für eine Kommunikationsverbindung. Ein dedizierter Aufbau und Abbau der Verbindung ist notwendig. Die Leitungsvermittlung eignet sich besonders gut für Echtzeit-Datenverkehr wie Sprach oder Video Übertragung. Die Übertragung ist zuverlässig und von hoher Qualität, kann aber Ressourcen verschwenden, da z.B. Leitungen in beide Richtungen fix reserviert wurden, unabhängig davon, ob nun gerade gesprochen wird oder ob sich das Bild eines Videos nun verändert oder nicht.

Circuit Switching

Die Paketvermittlung ist eine Erfindung aus der Welt de Internets und geht auf das Amerikanische Verteidigungsministerium und dessen DARPA Net zurück. Ein sehr interessanter geschichtlicher Hintergrund, auf den hier aber nicht weiter eingegangen werden kann. Im Zentrum dieses Vermittlungsverfahrens steht die Datenübertragung bei der die Datenströme in diskrete Teilstücke eingeteilt und dann auf den Weg zum Empfänger geschickt werden. Dies sind die sog. Datenpakete nach denen dieses Verfahren Ihren Namen bekommen hat. Die Pakete werden dabei unabhängig voneinander, nach dem „store-and-forward“ Prinzip über mehrere Konten hinweg durch das Netzwerk transportiert (sie werden „geroutet“). Der ursprüngliche Datenstrom mit seiner Information in richtiger Reihenfolge wird dann beim Empfänger aufgrund von Zusatzdaten, die den einzelnen Paketen angefügt wurden, wieder rekonstruiert. Anders als in der Leitungsvermittlung kann hier die Nachricht Ihr Ziel über mehrere Wege erreichen. Und im Falle eine Übertragungspause werden auch keine Ressourcen benötigt.

Vorteile der Leitungsvermittlung sind eine fixe Bandbreite und somit garantierter Kapazität und niedrige Signalverzögerungen und Verzögerungsvariation. Als Nachteile können extra Overhead durch Verbindungsauf- und Abbau und die Verschwendung von Ressourcen bei geringer Nutzung genannt werden.

Vorteile der Paketvermittlung sind die effiziente Ausnützung von Ressourcen, die hohe Flexibilität bei Übertragungsweg und Übertragungsart und die Tatsache, dass auf Netzwerk-Layer Ebene kein Setup und Teardown der Verbindung notwendig ist. Ein wesentlicher Nachteil ist die fehlende Garantie über geringe Signalverzögerungen und effektiver Bandbreite, also die wichtigsten Quality of Service Parameter.

Verbindungsorientierte Übertragung

Auf dem Transport Layer unterscheidet man zwischen „Connection-oriented“ (Verbindungsorientiert), also verbindungsorientierter und „connectionless“, also verbindungsloser Kommunikation. Verbindungsorientierte Kommunikation gewährleistet eine (nahezu) fehlerfreie Kommunikation und garantiert die korrekte Reihenfolge der Daten für den der das jeweilige Transport Protokolle verwendet. Weiters wird Flusskontrolle durchgeführt und Datenverlust oder Duplizierung sind ausgeschlossen. Das TCP (Transmission Control Protocol) Ist dafür das wohl bekannteste Beispiel.

Verbindungslose Protokolle verschicken nach bestem Vermögen sogenannte Datagramme, das sind Datenpakete die für sich abgeschlossen und ohne Zusammenhang mit anderen Paketen losgeschickt werden. Dabei gilt die Prämisse von „Abgeschickt ist gleich Angekommen“. Pakete die verlorengegangen sind werden nicht erneut gesendet. Diese Datagramme kann man am besten mit Postkarten vergleichen. Das Berühmteste Beispiel dafür ist das UDP (User Datagram Protocol) Protokoll. Es wird immer dann eingesetzt wenn Daten schnell und mit geringer Verzögerung übertragen werden müssen, wobei die darüberliegenden Applikationen auf das ein oder andere verlorengegangene Datenpaket verzichten können. UDP stellt z.B. die Basis von RTP (Realtime Transmission Protocol) dar welches zur Übertragung in Echtzeit (z.B. VOIP oder Video Streaming) verwendet wird. Diese Übertragungprotokolle haben nichts mit den angewandten Kodierungsverfahren wie MPEG2 oder H.264 zu tun.

Verbindungslose Übertragung

Auf der Application-Layer Ebene ist das wohl bekannteste Protokoll HTTP, also Hypertext Transfer Protokoll, welches für World Wide Web implementiert wurde. Es wurde definiert unter IETF RFC 1945 und RFC 2616 (siehe www.ietf.org). Es ist ein „stateless“ Protokoll, also zwischen zwei gesendeten Nachrichten besteht kein Zusammenhang und basiert auf dem Request/Response, also dem Frage/Antwort Schema.

HTTP steht auf allen Plattformen zur Verfügung, wird oft auch schon von kleinen Geräten wie 4-Port Routern oder ähnliches zur Konfigurationsanbindung verwendet. Das Protokoll ist sehr einfach gehalten und die Nachrichten sind textbasiert. Entsprechende Nachrichten können also auch von Menschen gelesen und manuell eingetippt werden, meist zum Testen. Es kennt darüber hinaus einfache aber effektive Sicherheitsmechanismen und wird von Firewalls eher freundlich behandelt. Ein Grund dafür, warum SOAP meist über HTTP übertragen wird, was aber wiederum bedeutet, dass Firewalls eigentlich doch nicht so freundlich sein sollten was HTTP Verkehr anbelangt.

Eine HTTP Nachricht besteht aus einer Request oder Status Zeile (1. Zeile der Nachricht) gefolgt von mehreren Zeilen mit Name-Value-Pair (name=wert) einträgen die als Header bezeichnet werden. Darauf folgt eine Leerzeile mit der Zeichenkombination (<CR><LF>), also die art und weise, wie in Windows in der Regel Leerzeichen gespeichert werden. Darauf folgt der Sogenannte Body, welcher dann die Nutzdaten enthält.

Die erste Zeile einer HTTP Request Nachricht enthält die HTTP Methode (GET, HEAD, POST oder PUT, abhängig von der HTTP Version) und die angeforderte Ressource, also die URL der zu liefernden Daten (z.B. eine HTML Datei). Die Möglichen Header Werte kann man dem Standard entnehmen. Bei einer HTTP Response Nachricht enthält die erste Zeile den Status-Kode und eine kurze Beschreibung (z.B. „200 OK“, oder „404 Not Found“. Im Body der Nachricht sind dann die gewünschten Daten enthalten.

Nachrichtenkodierung

Daten, die über das Netzwerk übertragen werden sind einfach nur Bits und Bytes, Nullen und Einsen. Sie können verschiedenste Information und Formate repräsentieren. Z.B: Text wie ASCII, UTF8, UTF16, etc., oder einfache Datentypen wie byte, int , long, float etc. Sie können aber auch bedeuten, dass Objekte, Klassen, Bilder oder Dokumente über die Leitung geschickt werden.

Weiters, besteht ein Netzwerk aus einer Vielzahl verschiedenartiger, heterogener Systeme und Computer. Manche Computer interpretieren die Bytes in Bitreihenfolge von rechts nach links (Intel), andere von links nach rechts (PPC auf G5 Macs oder die CPU der XBOX360). Die Art der Zeichencodierung (UTF vs. LATIN) oder die Breite der Register, 8, 16, 32 oder 64 Bit, der verwendeten CPUs können sich unterscheiden. Einen Transformation der Daten oder ein „allgemein“ verständlicher Kode ist erforderlich, um nicht nur Bits sondern auch Information übertragen zu können. Dies ist theoretisch recht einfach, hat aber einen starken Einfluss auf die Performance und somit die Übertragungsrate.

Wenn man nun für jeden Code auf jeden beliebigen anderen Code ein Mapping definieren will, dann würde man bei n Codes n² Transformationen implementieren müssen; das berühmte n-Quadrat Problem. Viel besser wäre es also, vor der Übertragung, die vorliegenden Daten in ein kanonisches Format umzuschreiben, die Daten dann über das Netz zu schicken und auf der Empfangsseite dieses allgemein verständliche Format auf die Präsentation der Daten im lokalen System wieder zurück zu codieren. Dadurch wird eine Reduzierung der Komplexität auf 2*n statt n² erreicht.

Bei der Textcodierung werden dabei Character und Charactersets definiert wie früher ASCII oder EBSDIC Kodierung und in heutzutage im Sinne der globalen Familie des Internets Zeichenmengen und Kategorisierungen wie UTF oder LATIN.

Es braucht aber auch eine kanonisierte Form, um die Bits die in die Leitung fließen und am anderen Ende wieder ausgelesen werden zu interpretieren. Diese Form wird definiert in der Abstract Syntax Notation, ASN.1 der ISO (International Standard Organization). Der Standard besteht aus vier Hauptelementen:

1. Die Abstract Syntax beschreibt die Struktur von Daten unabhängig von anderen Programmiersprachen
2. Die Concrete Syntax beschreibt die Struktur der Daten bezogen auf eine bestimmte Programmiersprache.
3. Die Transfer Syntax beschreibt die Struktur der Daten auf dem Übertragungsweg
4. Die Encoding Rules (z.B. die Basic Encoding Rules BER) beschreiben die Transformation von der Concrete Syntax in die Transfer Syntax

ASN.1

Im Folgenden werden nun einige Beispiele für die Notierung in ASN.1 und die Kodierung in BER gegeben.

ASN.1 Deklaration eines Datentypen (hier “BookType”):

BookType ::= INTEGER {

paperback(0)

hardcover(1)

}

Beispiel Wertedefinition:

hardcover BookType ::= hardcover(1)

Die Standard Kodierungsregeln von ASN.1 besagen, dass:

• Datentypen-Information wird via TAGs übertragen
• Es werden keine Typennamen übertragen
• TAGs werden annotiert, um Typen zu beschreiben.

Dabei gibt es vier verschiedene TAG Klassen:

UNIVERSAL, APPLICATION, CONTEXT-SPECIFIC, PRIVATE

Die Daten werden dann via TLV Kodierung (Tag, Length, Value) übertragen

BER TLV Prinzip

Beispiel Definition:

BookType ::= [APPLICATION 4] INTEGER {

paperback(0)

hardcover(1)

}

hardcover BookType ::= hardcover(1)

Die Daten hardcover werden nun in codiert wie in Abb. 11.

BER Beispiel

Die Kombination aus ASN.1 und BER ist sehr effektiv. Beliebige Datenstrukturen können kanonisiert übertragen werden. Der Preis für die Perfektion ist jedoch hoch. Die Kodierung ist aufwendig und ineffizient, z.B. beim Zugriff auf bestimmte Bits. Viele Applikationen kennen die Typen ihrer zu übertragenden Daten ohnehin, was diese Information überflüssig macht. ASN.1 ist ein Kind der Telekommunikationsstandardgremien und wird auch heute noch in diesem Bereich eingesetzt, z.B. bei UMTS oder Intelligent Networks. Mittlerweile hat sich allerdings XML als Standard bei der Übertragung von typisierten Daten etabliert.

XML, die Extended Markup Language ist eine textbasierte Meta Sprache mit einer selbstbeschreibenden Datenpräsentation: Daten und Typinformation zu den Daten erscheinen zusammen. XML ist plattformunabhängig und jede Menge Tools und APIs zum Generieren und Lesen von XML stehen zur Verfügung (SAX, DOM, etc.). Man könnte XMLD als die Sprache der Maschinen in Internet bezeichnen. Es gibt zur Zeit kaum datenorientierte Applikationen, die diesen Standard nicht unterstützen würden. XML ist adaptier- und erweiterbar, via sogenannter Extensible Stylesheets (XSLT). XML wurde standardisiert von der W3C.

Auf XML, XLINK, XPATH, XPOINTER und XSLT wird unter Kapitel 4.2.4 näher eingegangen.

XML ist eine Metasprache mit dem Zweck, konkrete Sprachen zu definieren, also im Falle der Datenübertragung das Vokabular zur Typenbeschreibung. Dabei werden die aktuellen Daten mit Tags versehen, die die Bedeutung der Daten bestimmen. Die Möglichkeiten, welche Daten wie getagged werden können, werden durch die XML Stylesheets bestimmt.

Ein durch XML beschriebenes Set an Daten in einer Datei wird als Dokument bezeichnet. Diese Dokumente sind hierarchisch geordnet, indem mit Anfangs- und Endtaggs versehene Datensegmente ineinander verschachtelt werden.

XML ist sehr erfolgreich aber man sollte sich nicht von dem Mythos blenden lassen, dass XML einfach zu handhaben und von Menschen lesbar sei (Beweis: Speichern Sie ein MS-Word Dokument als XML ab und öffnen sie diese mit einem einfachen Texteditor).

Es gibt noch andere Methoden zur Serialisierung von Daten, vor allem objektorientierte Laufzeitumgebungen wie .Net oder Java definieren eigene über die jeweilige Sprache hinaus nicht standardisierte Formate um , z.B. Objekte zu speichern oder zu übertragen.

Remote Procedure Calls, Middleware und verteilte Objekte

Bevor wir auf RPC eingehen sollten wir einen kurzen Ausflug in die Welt der Clients und Server machen. Gegeben sei dabei der schon unter 1.2 vorgestellte Usecase eines Online-Store.

Der Online Store stellt den Dienst, Waren über das Internet anzubieten und zu vertreiben bereit. Die notwendigen Prozesse die dabei ablaufen werden dabei unter dem Begriff „Server“ zusammengefasst. Oft wird damit auch der ganze Computer bezeichnet, auf dem diese Prozesse oder Aufgaben abgearbeitet werden.

Der Prozess der diesen Service benutzt, wird als Client bezeichnet. Dabei kann ein Server der Client eines anderen Servers sein, z.B. in einer Multi-Tier Architektur moderner Business-Anwendungen.

Den gesamten Service jetzt aber nur auf Basis von Requests und Responds die via TCP über das Netz geschickt werden, wäre sehr zeitaufwendig, fehleranfällig und kaum wieder verwertbar für viele verschiedene Online-Stores.

Client Server Schema

Client Server Schema

Es gibt dazu einen eleganteren Ansatz. Dabei tut man auf der Seite des Clients einfach so, als würde man eine Prozedur oder Funktion aufrufen, ohne dass dem Aufrufenden dabei klar ist, ob die Funktion nun auf dem eigenen lokalen Rechner oder auf einem anderen irgendwo im Internet abgearbeitet wird. In unserem Beispiel könnte man dann einfach zwei C-Funktionsprototypen definieren wie etwa:

public Receipt order(Books] books);

public Book[] suche(String keyword);

Totale Transparenz und absolute Ununterscheidbarkeit von lokalen und entfernten Aufrufen von Funktionen auf einem beliebigen Computer wird allerdings immer ein Ideal bleiben. Faktoren wie Laufzeitverzögerung, parallele Abarbeitung, Speicherzugriff oder teilweise Ausfälle von Geräten wird von Programmierern immer gesondert behandelt werden müssen. Man kann Ihnen das Leben dabei allerdings wesendlich vereinfachen, indem man notwendiges Expertenwissen über Sockets, Session-Management, Datenrepräsentation oder das Auffinden von Services (Funktionen) vereinfacht oder abstrahiert.

Der erste Versuch dies zu erreichen ist die Einführung von sogenannten Remote Procedure Calls. Diese Technologie setzt auf dem Transport Layer auf und entbindet damit den Applikationsprogrammierer von der Verantwortung Netzwerkprotokolle oder Sockets selbst ansteuern zu müssen.

Naming Services

„It’s all in a name.“

Diese im Englischen oft verwendete Redewendung deutet auf die Wichtigkeit der Namensvergabe für das was wir tun und geschaffen haben hin. Dies gilt um so mehr für verteilte Systeme, denn was man nicht benennen kann existiert letztlich nur für sich selbst und ist somit nutzlos in der Welt der anderen. Und verteilte Systeme sind vom Benutzer aus betrachtet nun mal nichts anderes als: „Die Welt der Anderen“. Damit Computer mit Namen gut umgehen können müssen diese systematisiert werden. Dadurch entstehen Namenssysteme und in verteilten Systemen Namensdienste zur Auffindung von Ressourcen im Netz.

Jede logische Einheit eines Naming-Service, jeder Eintrag den man dort ablegen kann, besteht aus drei Elementen:

• NAME:
  

Dieser beschreibt das Objekt um das es geht (welches eingetragen oder gesucht wird)

• ADRESSE:
  

Der Ort an dem sich das Objekt befindet

• PFAD
  

Beschreibt, wie man am Ort des Objektes zu dem Objekt selbst findet.

Die oben genanten Elemente lassen sich z.B. auch in dem HTML Address-Tag wieder finden: <a ref=http://ffh.online-campus.at/Dokumente/AIT2/Studienheft.pdf> Skriptum zu GridComputing </a> mit NAME=“Skriptum zu GridComputing“, ADRESSE=ffh.online-campus.at und PFAD=Dokumente/AIT2/Studienheft.pdf.

Man braucht Naming Services, um Objekte (oder anders gesagt Ressourcen) im Netz zu identifizieren. Objekte können sein: Dateien, Benutzer, Datenbanken, Variablen, Kommunikationsverbindungen o.ä. Man nutzt Namenssysteme auch, um Daten und Information mit anderen zu teilen und um eine Indirektion zwischen Objekt und Zugriffsmethode zu schaffen. Die Bindung von Namen an Objekte ist dadurch dynamisch und kann jederzeit geändert werden Ein einziger Name kann eine gesamte Menge an Objekten bezeichnen und man kann einem Objekt gleich mehrere Namen geben. Außerdem ist die Namensvergabe eine Voraussetzung für die Transparenz eines Systems. So können WWW Server irgendwo auf der Welt aufgestellt werden, die Server können beliebig umgezogen werden und es kann mehrere replizierte Server geben, die auf der ganzen Welt verteilt laufen und den gleichen Namen haben, z.B.: um von einer Adresse www.millisoft.com, Antworten von europäischen oder amerikanischen Servern zu bekommen, je nach Konfiguration.

Naming Services stehen folgenden Problemen gegenüber: Dem Management von Kontextinformation, die ständige Verfügbarkeit der Namensauflösung - vom Namen zum wirklichen Objekt, dem riesigen Umfang an Namen und Objekten in einem (weltweiten) System und der Heterogenität unterschiedlicher Namensysteme welche miteinander verschränkt werden müssen.

Dabei ist Kontextmanagement der zentrale Aspekt, da die Bedeutung von Namen in der Regel abhängig vom Kontext ist in dem Sie gebraucht werden. SO kann z.B. das englische Wort „state“ einen Staat in den USA wie Kansas oder Kalifornien bezeichen und in einem anderen Kontext den momentanen Zustand eines laufenden Computerprogramms beschreiben.

Es gibt verschiedene Möglichkeiten, diese Probleme zu lösen:

• Zentralisiertes Kontextmanagement hat den Vorteil, dass es einfach zu implementieren ist aber die Nachteile, dass es einen „Single Point of Failure“ und einen weiteren Performance Engpass darstellt
• Verteiltes Kontextmanagement hat den Vorteil, dass es keinen „Single Point of Failure“ gibt und Loadsharing zwischen den Servern betrieben werden kann. Nachteile sind, dass es sehr komplex zu implementieren ist und der Ausfall eines Servers bedeutet, dass der Namensbereich für den dieser zuständig ist nicht mehr bedient werden kann.
• Verteiltes Kontextmanagement mit Replikation bietet hohe Verfügbarkeit, effizienten Zugriff und Loadsharing zwischen den Servern. Nachteile sind, dass nun auch Replikationsmanagement betrieben werden muss und dass laufzeitbedingt Inkonsistenzen in der Namensverwaltung auftauchen können.

Die Namen selbst können flach oder strukturiert sein. Beispiele für flache Namen oder Identifier sind die Reisepassnummer oder die ISBN eines Buches. Beispiele von strukturierten Namen sind Pfadangaben in einem hierarchischen Dateisystem, die Namespaces in C# oder die Paketnamen in Java, sowie die Domain Namen für Internet Adressen.

Die Funktionen eines Naming Services, ganz gleich ob dieser nur einen einzigen Application Server oder das ganze Internet abdeckt, lassen sich, abgesehen von den administrativen Aufgaben, in zwei Gruppen zusammenfassen: Die Manipulation von Kontext- und Namensinformation, sowie das Beantworten von Nachfragen.

Die Schreibfunktionen des Services sind: ADD – zum Erstellen eines Bezugs zwischen Name und Objekt, DELETE – zum Löschen des selben und MODIFY zum Verändern einer zuvor erstellten Referenz. Die Lesefunktionen sind: READ – das Auflösen eines Namens auf das konkrete damit verknüpfte Objekt, SEARCH – das Finden von Namen oder Objekten bezogen auf bestimmte Attribute und LIST – das Auflisten aller Namen in einem bestimmten Namensraum.

Geschichte der P2P Netze

Beispiele für Naming Services sind, im Bereich der Programmierung von verteilten Systemen das JNDI „Java Naming Directory Interface“ zum Auffinden von lokalen oder entfernten Objekten und im Bereich großer Netzwerke das X.500 Directory oder der DNS „Domain Name Service“ des WWW.

Die Hauptaufgabe des DNS ist das Umwandeln (LOOKUP) von symbolischen Computernamen auf Internet Adressen (und vice versa REVERSE-LOOKUP). Der Namensraum des DNS ist hierarchisch gegliedert und ortsunabhängig organisiert. Die Aufteilung erfolgt in Domains die in einer Baumstruktur miteinander verbunden sind. Im Gegensatz zum wenig verwendeten X.500 Directory baut der Domain Name Service auf einem einfachen Datenmodell auf, arbeitet mit einfachen Filter-Abfragen und ist Weltweit anerkannt (ICANN).

Peer-to-Peer Netzwerke

Peer-to-Peer Netzwerke sind ein fester Bestandteil des Web2.0 in den Bereichen Messaging (ICQ, Jabber), Groupware (Groove, Wave?), Internettelefonie (Skype), Media-Streaming (Hulu, Zatoo), Hosting/Filesharing (Bittorrent, Avalanche) oder auch bei Suchmaschinen (YaCy) (vergleiche auch [I4]).

In den 90-er Jahren des letzten Jahrhunderts hat ein Paradigmenwechsel eingesetzt der Peer-to-Peer Systeme den traditionellen Client/Server Lösungen bevorzugte. P2P Systeme sind autonom, skalierbar, dynamisch, anonym, dezentral und selbst-organisierend. Peer-to-Peer Datenverkehr macht mittlerweile mehr als die Hälfte des Internet Verkehrsvolumens aus. Man unterscheidet heute mindestens drei Generationen von Peer-to-Peer Netzwerken: 1. Generation – zentralisierte P2P Netze, 2. Generation reine P2P und hybrid P2P Netzwerke und 3. Generation – 3. Generation DHT (Distributed Hash Tables) P2P Netzwerke a la Bittorrent.

Bei der ersten Generation von Peer-to-Peer Netzwerken, den zentralisierten P2Ps speichert ein Server den Index zum Auffinden der Daten im Netz. Der Datenaustausch findet dann Peer-to-Peer also direkt von Rechner zu Rechner statt. Wie bei allen zentralisierten Systemen ist auch hier der Schwachpunkt der zentrale Server dessen Ausfall zu einem Totalausfall des Dienstes führen würde. Außerdem skaliert ein System schlecht dessen Hauptlast auf einem einzigen Rechner liegt.

Bei reinen P2P Systemen der 2. Generation sind alle Peers (Rechner) gleich. Queries und Pings werden weitergeleitet und es existiert keinerlei „globales Wissen“. Solche Systeme sind sehr robust. Dadurch ergeben sich allerdings Performance Probleme verursacht durch Message-flooding (hohe Anzahl von Nachrichten) und Daten-Kollisionen. Es gibt z.B. bei Gnutella auch keine Garantie alle Daten aufzufinden. Bei der hybriden P2P Variante wie Fasttrack unterscheidet man zwischen „normalen“ Peers und „Super“ Peers. Dadurch entsteht eine gewisse Hierarchie im Netz. Super-peers nutzen Ihre lokale Information bei einer Query und leiten diese nur weiter, wenn auf dem Peer Rechner selbst nichts gefunden wird.

In der 3. Generation der Peer-to-Peer Netzwerke wird das Konzept der verteilten Hashtabellen angewendet (DHT). Auch hier sind alle Peers gleich und es gibt keinerlei hierarchische Struktur. Die Last wird gleich verteilt auf alle Peers und Knoten und Objekte im Netz werden alle auf im gleichen Schlüsselraum (Anzahl möglicher Schlüssel) abgebildet.

Eine detaillierte Diskussion des Themas Peer-to-Peer Netzwerke würde eine ganze Vorlesung ausfüllen. Auch die Behandlung anderer wichtiger Aspekte zum Thema verteilte Systeme wie Zeitsynchronisation von Netzwerken, die Integration von globalen Daten und Datenreplikation sowie Parallelität und Transaktionsmanagement, würden den Rahmen dieses Studienheftes sprengen und können daher hier nicht weiter ausgeführt werden. Dem interessierten Leser bleibt es überlassen, diese Themen in der im Anhang angegeben Literatur selbst nachzulesen.