ƒ Synchron / asynchron nimmt Bezug auf den Empfänger

ƒ Kommunikationsbibliotheken machen oft einen Unterschied

Synchron = blockierend ^?

zwischen synchronem und blockierendem Senden

ƒ bzw. analog zwischen asynchron und nicht-blockierend

ƒ Blockierung ist dann ein rein senderseitiger Aspekt

ƒ blockierend: Sender wartet, bis die Nachricht lokal vom Kommuni- kationssystem abgenommen wurde (und der Puffer wieder frei ist)

ƒ nicht-blockierend: Sender informiert Kommunikationssystem

leider etwas verwirrend!

nicht blockierend: Sender informiert Kommunikationssystem lediglich, wo bzw. dass es eine zu versendende Nachricht gibt (Gefahr des Überschreibens des Puffers bevor dieser frei ist!)

ƒ Synchron / asynchron nimmt Bezug auf den Empfänger

ƒ synchron: Nach Ende der Send-Operation wurde die Nachricht dem Empfänger zugestellt (asynchron: dies ist nicht garantiert)

ƒ Nicht-blockierende Operationen liefern oft einen „handle“

Nicht-blockierend

p

handle = send(...)

ƒ dieser kann in Test- bzw. Warteoperationen verwendet werden

ƒ z.B. Test, ob Send-Operation beendet:

if msgdone(handle)…

ƒ oder z.B. wartenauf Beendigung der Send-Operation:

msgwait(handle)

ƒ Nicht-blockierend ist oft effizienter, aber evtl. unsicherer

und umständlicher (evtl. Test; warten) als blockierend

Synchrone Kommunikation lässt sich mit

Dualität der

Kommunikationsmodelle

asynchroner Kommunikation nachbilden:

ƒ Warten auf explizites Acknowledgment im Sender direkt nach dem send

send m;

receive ack;

receive m;

send ack;

Sender Empfänger

. . . . . .

. . . . . .

nach dem send

ƒ Explizites Versenden des Acknowledgments durch den Empfänger direkt nach dem receive

send m

receive m send ack receive ack Sender blockiert

Asynchrone Kommunikation mittels synchroner:

Dualität der

Kommunikationsmodelle (2)

y y

Idee: Zusätzlichen Prozess vorsehen, der für die Zwischenpufferung aller Nachrichten sorgt

Puffer

Dazwischengeschalteter Prozess mit vielen Pufferplätzen

S E

Æ Entkoppelung von Sender und Empfänger

S E

Wie realisiert man einen Puffer- prozess bei syn. Kommunikation?

...

receive warte bis Sender S etwas schickt; dann:

ƒ Dilemma: Was tut der Pufferprozess nach dem Ablegen der Nachricht im lokalen Speicher?

receive -warte,bis Sender S etwas schickt; dann:

Nachricht im lokalen Speicher ablegen send -warte,bis Empfänger E bereit ist

? ...

Puffer

S E

p

ƒ wieder im receive auf den Sender warten, oder

ƒ in einem (blocking) send auf den Empfänger warten?

ƒ Entweder Sender S oder Empfänger E könnte unnötigerweise blockiert sein!

Bemerkung: Puffer der Gösse 1 lassen sich so realisieren ÆKaskadier- ung im Prinzip möglich („Pufferpipeline“)

ƒ E schickt „seinem“ Puffer einen

t“ ( d d di

1. Lösung: Puffer als Server!

„request“ (und muss dazu die Adresse des Puffers kennen)

ƒ Puffer schickt E keine Antwort, wenn er leerist

ƒ Empfänger E wird nur dann verzögert, wenn Puffer leer

ƒ Für Sender S ändert sich nichtsFür Sender S ändert sich nichts

ƒ Was tun bei vollemPuffer?

ÆDann sollte der Puffer keine Nachricht von S (wohl aber von E!) annehmen (Denkübung: wie programmiert man das?)

2. Lösung:

Puffer als Multithread-Objekt

S

Empfangs- thread

Sende- thread

put get receive

Pufferspeicher

S

send

Beachte: Threads greifen auf gemeinsamen Speicherzu

E

ƒ Empfangsthread ist (fast) immer empfangsbereit

Puffer als Multithread-Objekt (2)

p g ( ) p g

ƒ nur kurzzeitig anderweitig beschäftigt (put in lokalen Pufferspeicher)

ƒ evtl. nicht empfangsbereit, wenn lokaler Pufferspeicher voll

ƒ Sendethread ist (fast) immer sendebereit

ƒ Pufferspeicher ist i.Allg. zy- klisch organisiert (Æ g ( FIFO) )

ƒ Pufferspeicher liegt im ge- meinsamen Adressraum

ƒ ֜ Synchronisation der beiden Threads notwendig!

ƒ konkurrentes Programmieren

ƒ klassische Themen der Betriebssystemtheorie

Hauptklassifikation von

Kommunikationsmechanismen

Synchronisationsgrad

“orthogonal”

“asynchroner RPC”

Rendezvous asynchron synchron Mitteilung

Auftrag

y g

Kommunika- tionsmuster

orthogonal

no-wait send

Remote Procedure Call(RPC)

ƒ Häufigste Kombination:

Mitteilung asynchron, Auftrag hingegen synchron

ƒ Asynchron-mitteilungsorientierte Kommunikation

No-Wait Send

y g

ƒ Vorteile

ƒ weitgehende zeitliche Entkopplung von Sender und Empfänger

ƒ einfache, effiziente Implementierung (bei kurzen Nachrichten)

N ht il

send

receive Datagramm

ƒ Nachteile

ƒ keine Erfolgsgarantie für den Sender

ƒ Notwendigkeit der Zwischenpufferung (Kopieraufwand, Speicher- verwaltung,…) im Unterschied etwa zur synchronen Kommunikation

ƒ Gefahr des „Überrennens“ des Empfängers bei zu häufigen Nachrichten ÆFlusssteuerung („flow control“) notwendig

ƒ Synchron-mitteilungsorientierte Kommunikation

Rendezvous-Protokolle

y g

Transport- schicht send

NACK ACK

Wieder- holung Sender

E fä

Senderinstanz

Empfängerinstanz

ƒ Hier beispielhaft „Sender-first-Szenario“:

Sender wartet als Erster

Empfänger

Zeitpunkt, wo Sender und Empfänger „gleichzeitig“

miteinander kommunizieren

ƒ Rendezvous: Der erste wartet auf den anderen

Rendezvous-Protokolle (2)

(„Synchronisationspunkt“)

ƒ Mit NACK / ACK (vgl. Bild) sind weniger Puffer nötig Æ aber aufwändiges Protokoll („busy waiting“)

ƒ Alternative 1: Statt NACK („negative ACK“): Nachricht auf Empfängerseite puffern (Nachteil: Platzbedarf für Puffer)

ƒ Alternative 2: Statt laufendem Wiederholungsversuch: Empfänger- instanz meldet sich bei Senderinstanz sobald Empfänger bereit instanz meldet sich bei Senderinstanz, sobald Empfänger bereit

ƒ Insbesondere bei langen Nachrichten sinnvoll: Vorherige

Anfrage, ob bei der Empfängerinstanz genügend Puffer-

platz vorhanden ist, bzw. ob Empfänger bereits Synchro-

nisationspunkt erreicht hat

ƒ Aufruf einer „entfernten Prozedur“

Remote Procedure Call (RPC)

Keine Parallelität

ƒ Synchron-auftragsorientiertiertes Prinzip

call

l

receive reply Client blockiert

Client

Server

reply request

accept, return reply, receive reply etc. werden

„unsichtbar“

durch Compiler

ƒ Bei verteilten objektorientierten Systemen:

„Remote Method Invocation“ (RMI), z.B. Java RMI

accept return reply Server bearbei- tet Prozedur

bzw. Laufzeit- system erledigt

ƒ Soll dem klassischen Prozeduraufruf möglichst gleichen

RPC: Pragmatik

ƒ klare Semantik für den Anwender (Auftrag als „Unterprogramm“)

ƒ Einfaches Programmieren

ƒ kein Erstellen von Nachrichten, kein Quittieren etc. auf Anwendungsebene

ƒ Syntax analog zu bekanntem lokalen Prozeduraufruf

ƒ Verwendung lokaler / entfernter Prozeduren analog

ƒ Typsicherheit (Datentypprüfung auf Client und Serverseite möglich)

ƒ Typsicherheit (Datentypprüfung auf Client- und Serverseite möglich)

ƒ Implementierungsproblem: „Verteilungstransparenz“

ƒ Verteiltheit so gut wie möglich verbergen

RPC: Implementierung

Client Server

Auspacken

Ergebnisseder Marshalling Auspacken

Argumenteder Marshalling Ergebnis-

rückgabe

Entfernter Prozedur-

aufruf

Lokaler Prozedur-

aufruf

Ergebnis- rückgabe

Stubs

Empfangen der Request- Nachricht

Senden der Reply-

Nachricht Senden

der Request- Nachricht Empfangen

der Reply- Nachricht

Request Reply Transport-

system

ƒ Stub = Stummel, Stumpf

RPC: Stubs

, p

ƒ Parameter a in eine Nachricht packt

ƒ Nachricht an Server S versendet

ƒ Timeout für die Antwort setzt

ƒ Antwort entgegennimmt (oder evtl. exception bei timeout auslöst)

ƒ Ergebnisparameter b mit den Ersetzt durch ein längeres Programm- stück (Client-Stub), welches u.a.:

call S.X(out: a ; in: b);

xxx ; xxx ; Client:

ƒ Ergebnisparameter b mit den Werten der Antwortnachricht setzt

ƒ Wirken als „proxy“

RPC: Stubs (2)

p y

ƒ lokale Stellvertreter des entfernten Gegenübers

ƒ (Client-Stub bzw. Server-Stub)

ƒ Simulieren einen lokalen Aufruf

ƒ Sorgen für Zusammenbau und Entpacken von Nachrichten

ƒ Konvertieren Datenrepräsentationen

ƒ bei heterogenen Umgebungen

ƒ bei heterogenen Umgebungen

ƒ Können oft weitgehend automatisch generiert werden

ƒ z.B. aus dem Client- oder Server-Code sowie evtl. einer Schnittstellenbeschreibung

ƒ Steuern das Übertragungsprotokoll

ƒ z.B. zur Behebung von Übertragungsfehlern

„Kommunikation mit Proxies“ (Bild aus dem Buch: „Java ist auch eine Insel“)

ƒ Problem: Parameter komplexer Datentypen wie

RPC: Kompatibilität von

Datenformaten und -strukturen?

p yp

ƒ Records, Strukturen

ƒ Objekte

ƒ Referenzen, Zeiger

ƒ Zeigergeflechte

ƒ Problem: RPCs werden oft in heterogenen Umgebungen eingesetzt mit unterschiedlicher Repräsentation z B von

ƒ sollen Adressen über Rechner- / Adressraumgrenzen erlaubt sein?

ƒ sollen Referenzen symbolisch, relativ,...

interpretiert werden?

ƒ wie wird Typkompatibilität sichergestellt?

eingesetzt mit unterschiedlicher Repräsentation, z.B. von

ƒ Strings (Längenfeld ↔‘\0’ als Endekennung)

ƒ Character (ASCII ↔Unicode)

ƒ Arrays (zeilen-↔spaltenweise)

ƒ Zahlen (niedrigstes Bit vorne oder hinten)

Marshalling: Zusammenstellen der Nachricht

RPC: Marshalling

a s a g usa e ste e de ac c t aus den aktuellen Prozedurparametern

ƒ evtl. dabei geeignete „standardisierte“ Codierung (komplexer) Datenstrukturen

ƒ Glätten („flattening“) komplexer (evtl. verzeigerter) Datenstrukturen zu einer Sequenz von Basistypen (evtl. mit Strukturinformation)

ƒ umgekehrte Transformation wird oft als

„unmarshalling“ bezeichnet

1) Umwandlung in eine gemeinsame

RPC: Datenkonversion

1) Umwandlung in eine gemeinsame Standardrepräsentation

ƒ z.B. XML bei „XML-RPCs“ (in Web-Applikationen)

lokale Repräsen-

tationÆXML XML Æ lokale

Repräsentation

System 1 System 2

XML

ƒ Beachte: Jeweils zwei Konvertierungen erforderlich;

für jeden Datentyp jeweils Kodierungs- und Dekodierungsroutinen vorsehen

tation ÆXML Repräsentation

2) Oder sendeseitig lokale Datenrepräsentation ver-

RPC: Datenkonversion (2)

) g p

wenden und dies in der Nachricht vermerken

ƒ „receiver makes it right“

ƒ Vorteil: bei gleichen Systemumgebungen/Computer- typen ist keine (doppelte) Umwandlung nötig

ƒ Empfänger muss aber mit der Senderrepräsentation mgehen können

umgehen können

Generell: Datenkonversion ist überflüssig, wenn sich alle Kommunikationspartner an einen gemeinsamen Standard halten

ƒ RPCs sollten so weit wie möglich lokalen Prozedur-

RPC: Transparenzproblematik

aufrufen (als bekanntes Programmierparadigma) g gleichen, es gibt aber einige subtile Unterschiede

ƒ z.B. bei Nichterreichbarkeit oder Absturz des Servers;

RPCs dauern auch länger als lokale Prozeduraufrufe

ƒ Beachte auch: Client-/Serverprozesse haben evtl.

unterschiedliche Lebenszyklen unterschiedliche Lebenszyklen

ƒ Server könnte z.B. noch nicht oder nicht mehr oder in einer

„falschen“ (z.B. veralteten) Version existieren

ƒ Anwender oder Programmierer eines Clients hat typischerweise keine Kontrolle über den Server

ƒ RPC i.Allg. wesentlich langsamer als lokaler Prozeduraufruf

RPC: Leistungstransparenz?

g g

ƒ Kommunikationsbandbreite ist bei umfangreichen Datenmengen relevant

ƒ Oft ungewisse, variable Verzögerungen

Effizienzzanalyse eines RPC-Protokolls

Null-RPC(Nutznachricht der Länge 0,

keine Auftragsbearbeitung) 1440 Byte-Nutznachricht

(ebenfalls keine Auftragsbearbeitung) (zitiert nach A. Tanenbaum)

g g) ( g g)

1. Call stub

2. Get message buffer 3. Marshal parameters

6. Trap to kernel

7. Queue packet for transmission 8. Move packet to controller

10. Get packet from controller 11. Interrupt service routine 12. Compute UDP checksum

ƒ Eigentliche Übertragung(9) kostet relativ wenig

ƒ Rechenoverhead(Prüfsummen, Header etc.) ist nicht vernachlässigbar

ƒ Bei kurzen Nachrichten ist Kontextwechselzwischen Anwendung und Betriebssystem relevant

ƒ Mehrfaches Kopierenkostet viel

4. Fill in headers p 5. Compute UDP checksum

over the bus p

9. Network transmission time

13. Context switch to user space p 14. Server stub code

ƒ Evtl. muss Server („Zielort“) bei Adressierung explizit

RPC: Ortstransparenz?

( ) g p

genannt werden

ƒ Getrennte Adressräume von Client und Server

ƒ keine Kommunikation über globale Variablen möglich

ƒ typischerweise keine Pointer/ Referenzparameterals Parameter möglich

ƒ Es gibt mehr Fehlerfälle

RPC: Fehlertransparenz?

g

ƒ beim klassischen Prozeduraufruf gilt:

Client = Server Æ„alles oder nichts“

ƒ hier: partielle („einseitige“) Systemausfälle typisch (Server-Absturz, Client-Absturz)

ƒ Nachrichtenverlust

ƒ ununterscheidbar von zu langsamer Nachricht!

֜Fehlerproblematik ist also „kompliziert“!

ƒ Client/Server haben zumindest zwischenzeitlich eine un- terschiedliche Sicht des Zustands einer „RPC-Transaktion“

ƒ crash kann im „ungünstigsten Moment“ des RPC-Protokolls erfolgen

Wir besprechen nachfolgend 4 typische Fehlerursachen:

Typische RPC-Fehlerursachen

p g yp

1. Verlorene Request-Nachricht 2. Verlorene Reply-Nachricht 3. Server-Crash

4. Client-Crash Grundprobleme:

ƒ Client / Server haben temporäreine inkonsistente Sicht

ƒ Timeoutbeim Client kann verschiedene Ursachen haben (verlorener Request, verlorenes Reply, langsamer Request bzw. Reply, langsa- mer Server, abgestürzter Server,...) →Fehlermaskierung schwierig

ƒ Gegenmassnahme:

Verlorene Request-Nachricht

Timeout-

Nach Timeout (kein Reply) die g

Request-Nachricht erneut senden

ƒ Probleme:

ƒ Wie viele Wiederholungsversuche maximal?

ƒ Wie gross soll der Timeout sein?

ƒ Was wenn die Request-Nachricht gar nicht verloren war

request request...?

Timeout Intervall

?

Client

ƒ Was, wenn die Request-Nachricht gar nicht verloren war, sondern Nachricht oder Server untypisch langsam?

ƒ Probleme, wenn Nachricht tatsächlich gar nicht verloren:

Verlorene Request-Nachricht (2)

ƒ Doppelte Request-Nachricht!

(Gefährlich bei nicht-idempotenten serverseitigen Operationen!)

ƒ Server sollte solche Duplikate erkennen (Denkübung: Benötigt er dafür einen Zustand? Genügt es, wenn der Client Duplikate als solche kennzeichnet? Genügen Sequenznummern? Zeitmarken?)

ƒ Würde das Quittieren der Request-Nachricht etwas bringen?

Bei automatischer Wie

1 2

?

Bei automatischer Wie- derholung von Request- Nachrichten ist eine Viel- zahl möglicher Fälle zu unterscheiden

ƒ Gegenmassnahme 1:

Verlorene Reply-Nachricht

analog zu verlorener Request-Nachricht g

ƒ also: Anfrage bei Timeout wiederholen

reply timeout

Client

Server !

ƒ Probleme:

ƒ vielleicht ging aber tatsächlich der Request verloren?

ƒ oder der Serverwar nur langsamund arbeitet noch?

ƒ ist aus Sicht des Clients nicht unterscheidbar!

ƒ Gegenmassnahme 2:

Verlorene Reply-Nachricht (2)

g

Server hält eine „Historie“ versendeter Replies

ƒ falls Server Request-Duplikate erkennt und den Auftrag bereits ausgeführt hat: letztes Reply erneut senden, ohne die Prozedur nochmal auszuführen

ƒ pro Client muss nur das neueste Reply gespeichert werden

ƒ Bei vielen Clients u.U. dennoch Speicherplatzprobleme: p p p Æ Historie nach „einiger“ Zeit löschen bzw. kürzen

ƒ und wenn man ein gelöschtes Reply später dennoch braucht?

ƒ ist in diesem Zusammenhang ein ack eines Reply sinnvoll?

Server-Crash

Client

timeout Client

Server

crash!

keinreply Ausführung

der Prozedur

timeout request

(Ausführungder Prozedur, aber kei- ne Rückmeldung)

Client Server

crash!

keinreply

(keineoder nur teilweise Ausführung der Prozedur)

timeout request

ƒ Probleme: Wie soll der Client obige Fälle unterscheiden?

Server-Crash (2)

ƒ ebenso: Unterschied zu verlorenem request bzw. reply?

ƒ Sinn und Erfolg konkreter Gegenmassnahmen hängt u.U.

davon ab!

ƒ Client meint evtl. zu Unrecht, dass ein Auftrag nicht ausgeführt wurde (Æfalsche Sicht des Zustandes!)

ƒ Evtl. Probleme nach einem Server-Restart

ƒ z.B. „Locks“, die noch bestehen (Gegenmassnahmen?) bzw.

allgemein: „verschmutzter“ Zustand durch frühere Inkarnation

ƒ typischerweise ungenügend Information, um in alte Transaktionszustände problemlos wieder einzusteigen

ƒ Oder auch:

Client-Crash

Client mittlerweile nicht mehr am reply interessiert

l d S d h b

Client Server

crash!

request ?

ƒ Reply des Servers wird nicht abgenommen

ƒ Server wartet z.B. vergeblich auf eine Bestätigung (wie unterscheidet der Server dies von langsamen Clients oder langsamen Nachrichten?)

ƒ blockiert i.Allg. Ressourcen beim Server!

ƒ Problem: „Orphans“ (Waisenkinder) beim Server

Client-Crash (2)

ƒ Prozesse, deren Auftraggeber nicht mehr existiert

ƒ Nach Restart könnte ein Client versuchen, Orphans zu terminieren (z.B. durch Benachrichtigung der Server)

ƒ Orphans könnten aber bereits andere RPCs abgesetzt haben, weitere Prozesse gegründet haben,...

ƒ Pessimistischer Ansatz: Server fragt bei laufenden Auf- g trägen von Zeit zu Zeit und vor wichtigen Operationen beim Client zurück (ob dieser noch existiert)

ƒ „Sehr“ alte Prozesse, die für einen Auftrag gegründet

wurden, werden als Orphans angesehen und terminiert

Resümee (3a)

ƒ Synchrone Kommunikation mit asynchroner simulieren

f l k l d

ƒ Warten auf ein explizites Acknowledgement

ƒ Asynchrone Kommunikation mit synchroner simulieren

ƒ Pufferprozess zur Entkoppelung dazwischenschalten

Resümee (3b)

ƒ Implementierung von Pufferprozessen

ƒ z.B. durch Multithreading

ƒ Rendezvous-Protokoll (syn., mitteilungsorientiert)

ƒ RPC-Implementierung

ƒ Stubs

ƒ Parameter-Marshalling

ƒ Transparenzproblematik

ƒ Transparenzproblematik

ƒ RPC-Effizienz

ƒ RPC-Fehlerproblematik

ƒ Fehlerursachen (verlorene Nachrichten, Crash von Server / Client)

ƒ Gegenmassnahmen