Verteilte Systeme

2. Kommunikation

Sommersemester 2011

Institut für Betriebssysteme und Rechnerverbund

TU Braunschweig

Dr. Christian Werner– Bundesamt für Strahlenschutz –

2-2 Überblick

� Schichtenmodelle� Motivation

� Dienste und Protokolle

� ISO-Modell

� Internet-Modell

� Darauf aufsetzende Konzepte� Remote Procedure Calls

� Verteilte Objektsysteme

� „Future Internet“� Notwendigkeit

� Anwendungsbeispiele

� Experimentalplattformen – das Labor das Future-Internet-Forschers

2-3 Warum Schichtenmodelle?

� Für die Kommunikation über ein Netz müssen eine Vielzahl von Problemen gelöst werden.

� Die Idee ist, diese komplexe Aufgabe in viele kleine, weniger komplexe Aufgaben aufzuteilen.

� Zur Lösung der Aufgaben in einer höheren Schicht werden die Lösungen der darunter liegenden Schichten verwendet.

2-4 Kommunikation in Schichten

Dolmetscher B

Spanisch

Englisch

Dolmetscher B

Spanisch

Englisch

Techniker BTechniker BTechniker Aerkennt einzelne Buch-

staben und „morst“ diese

Techniker Aerkennt einzelne Buch-

staben und „morst“ diese

Netz

Chinesischer

Philosoph

Spanischer

Philosoph

Dolmetscher A

Chinesisch

Englisch

Uninterpretierte Sätze

ohne Kenntnis des

Existentialismus

Uninterpretierte Zeichen

in korrekter Reihenfolge

Diskussion über den

Existentialismus

2-5 Dienste und Protokolle

� Die von einem Netz bereitgestellten Funktionen werden abstrakt als Dienst bezeichnet.

� Die einzelnen elementaren Funktionen werden als Dienstprimitive bezeichnet. Typische ISO/OSI Dienste sind:� Request: Anforderung eines Dienstes

� Indication: Anzeige, dass ein Dienst angefordert wurde

� Response: Reaktion des Dienstes auf eine Dienstanzeige

� Confirmation: Bestätigung, dass ein angeforderter Dienst erbracht wurde

2-6 Dienste und Protokolle

� Die Schnittstellen, über die die Dienstprimitive in Anspruch genommen werden können, werden als Dienstzugangspunkte (service access point, SAP) bezeichnet.

� Die Dienste werden von sogenannten Instanzen (entities) erbracht.

� Die Regeln, nach denen sich Instanzen verhalten und mit anderen Instanzen interagieren, werden als Protokoll bezeichnet.

2-7 Darstellung und Schichtung von Diensten

� Die Bildung von Schichten ist ein grundlegendes Prinzip zur Strukturierung von Kommunikationssystemen.

� Dienste einer Schicht dürfen immer nur Dienstprimitive von Diensten in direkt benachbarten Schichten in Anspruch nehmen.

N-Instanz 1 N-Instanz 2

Dienstnutzer Dienstnutzer

Dienstzugangpunkt NDienstschnittstelle N

Schicht N

(N-1)-Instanz 1 (N-1)-Instanz 2 Schicht N-1

Dienstschnittstelle N-1 Dienstzugangpunkt N-1

2-8

user dataFTND

Datenfluss durch die Schichten

1011010

user data

user dataF

user dataFT

user dataFTN

user dataFTND

1011010

user data

user dataF

user dataFT

user dataFTN

TL protocol

File transfer protocol

user file

PHY

DL

NL

TL

FTP

ftp

client

PHY

DL

NL

TL

FTP

ftp

server

NL protocol

DL protocol

2-9 Weg-Zeit-Diagramme

� Weg-Zeit-Diagramme verdeutlichen den zeitlichen und räumlichen Zusammenhang zwischen Dienstprimitiven.

� Die vertikale Achse ist die Zeitachse, die horizontale Achse gibt den räumlichen Abstand an zwischen Dienstnutzer und Diensterbringer an.

� Werden Dienstaufrufe (requests) grundsätzlich (positiv oder negativ) bestätigt, so handelt es sich um einem bestätigten Dienst (confirmedservice).

� Werden Dienstaufrufe (requests) nicht bestätigt, so handelt es sich um einen unbestätigten Dienst (unconfirmed service).

request

confirmation

indication

response

request

indication

Bestätigter Dienst Unbestätigter Dienst

Dienstnutzer Diensterbringer Dienstnutzer Diensterbringer

2-10 Darstellung und Spezifikation von Protokollen

� Darstellung von Protokollen mit endlichen Automaten:

� Spezifikationsmöglichkeiten für Protokolle:� natürliche Sprache� Formale Modelle (erweiterte endliche Automaten, attributierte

Grammatiken, Petrinetze, Prozessalgebra, temporale Logik)� Spezifikationssprachen (LOTOS, Estelle, SDL)

XReq

RuheWarten

XReq; YReq

YConf; XConf

XConf XRes XInd

YReq YConf YRes YInd

Warten

YInd; XInd

XRes; YRes

2-11 Das ISO/OSI-Referenzmodell

Medium

Vermittlung

Transport

Bitübertragung

Sicherung

Steuerung

Darstellung

Anwendung

Network

Transport

Physical

Data Link

Session

Presentation

Application

Anwendungsprozess

Network

Physical

Data Link

Application Process

Media

Transitsystem

Endsystem Endsystem

2-12 ISO/OSI-Transportsystem

� Bitübertragungsschicht (physical layer):� Übertragung einer Folge von Bits über ein Medium� Festlegung von Eigenschaften des benutzten Mediums� Darstellung der Werte 0 und 1 (z.B. Spannungswerte)� Synchronisation zwischen Sender und Empfänger � Festlegungen von Steckernormen

� Sicherungsschicht (data link layer):� Übertragung einer Bitfolge in Rahmen (frames)� Datenübertragung zwischen Systemen, die ein gemeinsames

Medium besitzen� Erkennung und Behebung von Übertragungsfehlern� Flusssteuerung zur Behandlung von Überlastsituationen� Realisierung meist in Hardware auf Adapterkarten

2-13 ISO/OSI-Transportsystem

� Vermittlungsschicht (network layer):� Bestimmung eines Weges durch das Netz� Multiplexen von Endsystemverbindungen über eine

Zwischenverbindung� Fehlererkennung und -behebung zwischen Endsystemen� Flusssteuerung zwischen Endsystemen� Aufteilung eines Pakets in Rahmen

� Transportschicht (transport layer):� Ende-zu-Ende Kommunikationskanäle zwischen Applikationen� Virtuelle Verbindungen über verbindungslose Datagrammdienste� Fehlererkennung und -behebung zwischen Applikationen� Flusssteuerung zwischen Applikationen� Verschiedene Dienstgüten möglich

2-14 ISO/OSI-Anwendersystem

� Sitzungsschicht (session layer):� Synchronisation und Koordination von kommunizierenden

Prozessen� Dialogsteuerung (Sicherungspunkte)

� Darstellungsschicht (presentation layer):� Transformation und Anpassung von Datendarstellungen� Serialisierung von Datenstrukturen zum Zweck der Übertragung� Datenkompression

� Anwendungsschicht (application layer):� Bereitstellung von grundlegenden Diensten, die direkt von

beliebigen Anwendungen benutzt werden können:� Dateitransfer, virtuelle Terminals, Namensraumverwaltung,

Datenbankzugriff, Netzwerkmanagement, elektronische Nachrichtensysteme, Prozess- und Maschinensteuerung, ...

2-15 ISO/OSI-Standardisierung

� Die International Organization for Standardization (ISO) ist eine freiwillige, nicht per Staatsvertrag geregelte Organisation zur internationalen Normung.

� Die Mitglieder der ISO setzen sich aus den Normungsinstituten der einzelnen Mitgliedsländer zusammen (ANSI für die USA und DIN für Deutschland).

� Die Standards der ISO werden in ca. 200 technischen Komitees (TCs) durch deren Unterkomitees (SCs) und Arbeitsgruppen (WGs) erstellt.

� ISO-Standardisierungsmodell:� Entwurfsvorschlag (draft proposal, DP)� Entwurf (draft international standard, DIS)� Standard (internation standard, IS).

� Die jeweiligen Übergänge bedürfen Mehrheiten (Abstimmungen) und können sich mehrmals zyklisch wiederholen.

� Die Open Sytems Interconnection (OSI) beschreibt den Teil der Standards, der sich mit der Kommunikation in offenen (Kommunikations-) Systemen befasst.

2-16 Das Internet-Schichtenmodell

Medium

Internet (IP)

Transport

ApplicationApplication

Internet (IP)

Transport

Anwendungsprozeß

Internet (IP)

Application Process

Media

Router

Endsystem Endsystem

ApplikationApplikation

SubnetzwerkSubnetzwerk SubnetworkSubnetwork SubnetworkSubnetwork

2-17 Internet-Standardisierung

� Die Standardisierung der Internet-Protokolle wird durch die Internet Engineering Task Force (IETF) durchgeführt. Kontrolliert wird die IETF durch die Internet Engineerung Steering Group (IESG).

� Die IETF ist eine offene Organisation, bei der prinzipiell jedermitarbeiten kann. (Es gibt keine Mitgliedschaftspflicht bzw. -gebühren oder dergleichen.)

� Internet-Standards werden in Arbeitsgruppen (working groups, WGs) ausgearbeitet, die wiederum in verschiedenen Bereichen (areas) organisiert sind.

� IETF-Standardisierungsmodell:� Vorgeschlagener Standard (proposed standard)� Vorläufiger Standard (draft standard)� Internet Standard (full standard)

� Die jeweiligen Übergänge erfordern "rough consensus" und Implementationen. Zyklische Wiederholungen sind begrenzt möglich.

� Die IETF befasst sich ausschließlich mit Standards rund um das Internet.

2-18 Eigenschaften der Modelle

� Das Internet-Protokoll (IP) stellt sehr geringe Anforderungen an ein Subnetzprotokoll (Übertragung eines Pakets an eine Zieladresse).

� Fast alle Netzwerktechnologien (nicht nur der Schicht 2) können als Subnetzwerk benutzt werden.

� Das Internet-Protokoll (IP) schafft eine gemeinsame Basis, die leicht an neue Netzwerktechnologien angepasst werden kann.

� Andererseits ist der Adressraum der derzeitigen IP Version 4 (IPv4) zu klein, um dem Bedarf nach Adressen zu befriedigen, weshalb eine Umstellung zur Version 6 (IPv6) erfolgen muss.

2-19 Eigenschaften der Modelle

� Die Internet-Architektur stammt aus der Computerwelt und hat entsprechend geeignete Programmierschnittstellen.

� Die ISO/OSI-Architektur stammt aus der Telekommunikationswelt und ist mehr auf die Bedürfnisse der klassischen Telekommunikation zugeschnitten.

� Implementationen von Internet-Protokollen sind meist frei zugänglich, was deren Verbreitung und Verbesserung in kurzen Zeitintervallen ermöglicht.

� ISO/OSI-Protokolle werden von formalen Standardisierungsgremien entworfen, was sehr zeitaufwändig ist und oftmals zu komplexen Resultaten führt.

2-20 Remote Procedure Call – Motivation

� Jahrelang nur nachrichtenbasierte Kommunikation in VS

� Realisierung über send und receive Funktionsaufrufe

� Fehlende Transparenz!

� Lösung: übertrage die Idee des Aufrufs von Prozeduren zur Erledigung von Aufgaben auf VS (Birrell und Nelson, 1984)

� Prozess ruft Prozedur in anderem Prozess auf und wartet auf das Ergebnis, bevor er weiterarbeitet

� Probleme?

2-21 Probleme bei RPC

� Prozesse laufen in unterschiedlichen Rechnern und damit in unterschiedlichen Adressräumen (call-by-reference, call-by-value?)

� Übertragung von Parametern zwischen unterschiedlichen Rechnern

� Crash von einer der beteiligten Maschinen �Semantik des Aufrufs

� Die Probleme sind weitgehend lösbar, RPC ist ein wichtiger Kommunikationsmechanismus.

2-22 Ablauf des Aufrufs

(aus Tanenbaum, van Steen: Distributed Systems)

2-23 Wichtige Grundlage: Stubs

� Stubs („Stummel“) bilden die Prozedur-Schnittstellen für die Applikationsprogramme

� Eine Applikation ruft eine entfernte Prozedur auf, indem sie lokal eine Stub-Prozedur aufruft

� Diese übersetzt den Aufruf in eine netzwerkübertragbare Nachricht (Client-Stub).

� Dieser Prozess wird als Marshalling bezeichnet.

� Auf der Server-Seite wird die Nachricht empfangen, ins das Host-Format umgewandelt und an die Implementierung der Prozedur gegeben (Server-Stub).

� Diese wird ausgeführt; das Ergebnis geht denselben Weg zurück.

2-24 Marshalling

2-25 RPC und verteilte Objektsysteme

� RPC = Übertragung der prozeduralen/imperativenProgrammierung auf verteilte Systeme

� Heute wichtige Form des Programmierens: Objektorientierung

� Auch dazu gibt es eine Übertragung auf verteilte Systeme, nämlich die verteilten Objektsysteme

2-26 Verteilte Objektsysteme

Rechner ProzessObjekt

Verteiltes ObjektsystemLokales Objektsystem

2-27 Das Objekt-Modell

� System = Sammlung miteinander interagierender Objekte, von denen jedes aus einer Menge von Daten und einer Menge von Methoden besteht

� Wichtige Begriffe:� Objektreferenz: die „Adresse“ eines Objekt� Schnittstellen: Definition der Zugangspunkte eines Objekts;

definiert durch die Signatur der Methoden� Aktionen: initiiert durch ein Objekt, das eine Methode eines

anderen Objekts aufruft; resultiert in der Zustandsänderung von Objekten

� Exceptions: eine Möglichkeit, Fehler in einem Programm auf saubere Art und Weise zu behandeln

� Garbage Collection: Freigabe nicht mehr benutzten Speichers

2-28 Das verteilte Objektmodell

� Interagierende Objekte sind auf mehr als einen Prozess verteilt

� Begriffe:� Entfernte Objektreferenz: die Adresse eines Objekts im ganzen

verteilten System; muss eindeutig sein

� Entfernte Schnittstellen: die Schnittstelle eines entfernten Objekts, oft beschrieben in einer formalen IDL (interface definition language)

� Aktionen: Methodenaufrufe anderer Objekte können Prozessgrenzen überschreiten

� Exceptions: verteilte Ausführung des Systems erweitert das Spektrum möglicher Fehler

2-29 Entfernte und lokale Methodenaufrufe

invocation invocationremote

invocationremote

locallocal

local

invocation

invocationA B

C

D

E

F

Rechner ProzessObjekt

(aus Coulouris et al: Distributed Systems)

2-30 Schnittstellen entfernter Objekte

� Die entfernte Schnittstelle gibt an, wie auf entfernte Objekte zugegriffen wird.

� Ihre Beschreibung enthält� Den Namen der Schnittstelle

� Möglicherweise Datentypdefinitionen

� Die Signatur aller entfernt verfügbaren Methoden, bestehend aus- Dem Methodennamen

- Ihrer Ein- und Ausgabeparameter

- Ihrem Rückgabewert

� Jede Middleware besitzt eine eigene Sprache, um solche Schnittstellen zu beschreiben, die IDL.

2-31 Entferntes Objekt und Schnittstelle

interfaceremote

m1m2m3

m4m5m6

Data

implementation

remoteobject

{ of methods

(aus Coulouris et al: Distributed Systems)

2-32 Future Internet - Motivation

� Das Internet hat eine sehr einfache Design-Idee:� Einfaches Netz („Best Effort“)

� Alle Intelligenz in den Endsystemen

� Modell: IP hourglass� Zustandlose Kommunikation

� Alles über IP

� Aber: Heutige Anforderungen und Anwendungen sehr viel vielfältiger

� Stichworte� QoS

� Per-Flow-Behandlung von Multimedia

� Sicherheit

� Zuverlässigkeit

� Wirtschaftlichkeit

� VoIP

� Internet of Things/Real-World Internet

� Mobilität

� Versuch, dies durch „Anbaulösungen“ zu erreichen

� Folge: sehr komplexes System, s. Grafik kommende Seite

IP

2-33 Aktuelle Internet-Architektur

2-34 Future Internet – Förderung und Players

� Weltweite Arbeiten an einem zukünftigen Internet – „Future Internet“

� Im Wesentlichen zwei Denkrichtungen� Inkrementelle bzw. schichtenweise Verbesserung

� Clean-slate

� Massive Förderung in Europa fördert sowohl national als auch auf EU-Ebene� Challenge 1 im aktuellen 7. Rahmenprogramm – allein im Arbeitsprogramm

2009/2010 557 Mio €

� Z.B. G-Lab in Deutschland

2-35Vorschläge für radikale Verbesserungen im Netz

� Fundamental neue Architektur:� Content-Centric Network (Van Jacobsen)

� Adressierung nicht von Hosts, sondern von Daten

� Replizierung als Standardlösung für nicht-permanente Konnektivität

� „objektorientiertes Routing“

� Persistente Identifier

� Intelligentes Netz� Heute ist die Intelligenz in den Endsystemen, das Internet an sich

ist „dumm“, es kann nur Pakete weiterleiten

� Netzbasierte Services zur Unterstützung von Sicherheit, Mobilität, Dienstgütegarantien

2-36 Scene 1 – car pooling

2-37 Scene 2 – public transport hub

2-38 Scene 3 – carbon credits

2-39 Future Internet of Energy

Weather Prediction: Sunny, Windy, 23ºC

Weather Prediction: Sunny, Windy, 23ºC

Wind leads to more electricity generation

Wind leads to more electricity generation

Lower electricity production

Lower electricity production

Green Electricity available

Green Electricity available

Energy production covers (estimated) needs

Energy production covers (estimated) needs

Heat generators are not needed

Heat generators are not needed

Sun leads to increased electricity generation

Sun leads to increased electricity generation

Electricity Car can get cheaper recharge

Electricity Car can get cheaper recharge

M. SANCHEZ, 2006, European Technology Platform SmartGrids

2-40 Warum Experimentalforschung im Future Internet?

� Wichtige Trends in der Informationstechnologie� immer und immer mehr Rechnersysteme, die miteinander interagieren �

komplexe Situationen, die sich nur noch schwierig simulieren lassen

� Computer aller Art wachsen immer stärker in die reale Welt hinein und müssen sich im harten Alltagsleben unter unterschiedlichsten Bedingungen bewähren � Modellierung und Simulation zunehmend schwierig

� Folge: Simulationsergebnisse geben nur noch sehr bedingt Aufschluss über die Einsetzbarkeit eines Algorithmus oder eines Protokolls im Feld � Inzwischen in der Literatur für Mobile/Ubiquitous Computing belegt:

- Katz et al: Simulationsannahmen sind viel zu einfach

- Kurkowskly et al: weniger als 15% der Simulationsergebnisse der Papers aufder MobiHoc 200-2005 sind reproduzierbar!

� Abhilfe: Experimente unter möglichst realistischen Bedingungen.

2-41 Laboreinrichtungen?

Quelle: Uni Münster

2-42 Anforderungen an Experimentaleinrichtungen

� Sie müssen prinzipiell darauf ausgerichtet sind, alle Arten von verteilten Anwendungen, Algorithmen und Protokollen auszuführen, und zwar auf allen Schichten. � auch Clean-Slate-Ansätze

� sowie Cross-Layer-Ansätze

� Die Ergebnisse müssen leicht zugänglich sein und einer Auswertung zugeführt werden können.

� Experimente müssen wiederholbar sein: ein unter denselben Bedingungen mehrfach durchgeführtes Experiment muss stets dieselben Ergebnisse erbringen.

� Experimente können (bzw. dürfen) die Funktionsfähigkeit der Experimentalplattform beeinträchtigen.

2-43 Plattformen am Beispiel – SmartSantander

� EU-Proposal im 7. Rahmenprogramm, Call 5

� Ziel: Aufbau einer umfassenden Experimentaleinrichtung für das Internet of Things

� > 20.000 Sensoren/Aktoren

� Deployment in der spanischen Stadt Santander

� Umsetzung diverser Szenarien wie oben beschrieben

� Nutzung durch Firmen und Forschungs-einrichtungen unterEinbeziehung derin Santander lebendenMenschen

2-44 Zusammenfassung

� Schichtenmodelle sind gut geeignet, um die Komplexität verteilter Systeme beim Design und der Implementierung zu verringern.

� ISO/OSI hat primär konzeptionellen Nutzen

� Das Internet-Modell hat sich in der Praxis durchgesetzt

� Für zusätzliche Transparenz sorgen Ansätze wie RPC und Verteilte Objektsysteme

� Künftige Herausforderungen sind Gegenstand der Forschungsarbeiten zum Thema „Future Internet“� Althergebrachte Architekturansätze werden zum Teil in Frage gestellt

� Extrem hohe Systemkomplexität� einfache Modelle reichen nicht mehr aus!

� Experimentalforschung gewinnt an Bedeutung

2-45 Diskussion