Upload
others
View
26
Download
0
Embed Size (px)
Citation preview
Vert. Sys., F. Ma. 121
Ausführung: 1Ergebnis: 1
Ausführung: 0/1Ergebnis: 0
Ausführung: 0/1Ergebnis: 0
Maybe
Ausführung: 1Ergebnis: 1
Ausführung: ≥1Ergebnis: ≥1
Ausführung: ≥0Ergebnis: ≥0 (*)At-least-once
Ausführung: 1Ergebnis: 1
Ausführung: 0/1Ergebnis: 0/1 (+)
Ausführung: 0/1Ergebnis: 0
At-most-once
Ausführung: 1Ergebnis: 1
Ausführung: 1Ergebnis: 1
Ausführung: 1Ergebnis: 1
Exactly-once
FehlerfreierAblauf
Nachrichten-verluste
Ausfall desServers
Wirkung der RPC-Fehlersemantik
May-be → At-least-once → At-most-once → ...ist zunehmend aufwendiger zu realisieren!
- man begnügt sich daher, falls es der Anwendungsfall gestattet, oft mit einer billigeren aber weniger perfekten Fehlersemantik
- Motto: so billig wie möglich, so „perfekt“ wie nötig(Aber dieses Motto gilt natürlich nicht in allen sonstigenLebenssituationen! Ein Sicherheitsabstand durch “besser alsnotwendig” ist oft angebracht!)
(*) Nach einem evtl. Server-Restart können Retries Ergebnisse verursachen(+) Bei Verlust der Antwortnachricht wird diese erneut gesendet
wird in den
Übungen aktualisiert
Vert. Sys., F. Ma. 122
RPC-Protokolle
- Sinnvoll bei langen Aktionen / überlasteten Servern:
- RR-Protokoll (“Request-Reply”):
reply
- RRA-Protokoll (“Request-Reply-Acknowledge”):- “pessimistischer” als das RR-Protokollrequest
reply - Vorteil: Server kann evtl. gespeicherte Replies frühzeitig löschen (und natürlich
ack
request request
wait! reply
timeout-Intervall
“wait” = Bestätigungeines erkanntenDuplikats
- Parameter-Übertragung „on demand“
request Zusatzdaten
more! reply
- spart Pufferkapazität- bessere Flusssteuerung- Zusatzdaten abhängig vom konkreten Ablauf
- Weitere RPC-Protokollaspekte:- effiziente Implementierung einer geeigneten (=?) Fehlersemantik- geeignete Nutzung des zugrundeliegenden Protokolls (ggf. aus Effizienzgründen eigene Paketisierung der Daten, Flusssteuerung, selektive Wiederholung einzelner Nachrichtenpakete bei Fehlern,
- Reply ist implizite Quittung für Request- lohnt sich ggf. eine unmittelbare Bestätigung des Request?
requestAck?
Replies bei Ausbleiben des ack wiederholen)
eigene Fehlererkennung / Prüfsummen, kryptogr. Verschlüsselung...)
Vert. Sys., F. Ma. 123
RPC: EffizienzAnalyse eines RPC-Protokolls
a) Null-RPC (Nutznachricht der Länge 0, kein Auftragsbearbeitung):
15%
5%
10%
20%
1 2 3 4 5 6 7 8 9 10 11 12 13 14
client stub client(BS-Kern)
server(BS-Kern)
Eth
erne
t
serv
er s
tub
1. Call stub2. Get message buffer3. Marshal parameters4. Fill in headers5. Compute UDP checksum6. Trap to kernel7. Queue packet for transmission
8. Move packet to controller over the bus9. Ethernet transmission time10. Get packet from controller11. Interrupt service routine12. Compute UDP checksum13. Context switch to user space14. Server stub code
b) 1440 Byte Nutznachricht (ebenfalls kein Auftragsbearbeitung):
15%
5%
10%
20%
1 2 3 4 5 6 7 8 9 10 11 12 13 14
client stub client(BS-
server(BS-Kern)
serv
er s
tub
- Eigentliche Übertragung kostet relativ wenig- Rechenoverhead (Prüfsummen, Header etc.) keineswegs vernachlässigbar- Bei kurzen Nachrichten: Kontextwechsel zw. Anwendung und BS wichtig
(zitiert nach A. Tanenbaum)
- Mehrfaches Kopieren kostet viel
Kern)
Vert. Sys., F. Ma. 124
RPC: Binding- Problem: Wie werden Client und Server “gematcht”?
- Verschiedene Rechner und i.a. verschiedene Lebenszyklen → kein
Binder
Server 1
Server 2 Client B
Client A
- Server (-stub) gibt den Namen etc. seines Services (RPC-Routine) dem Binder bekannt
- “register”; “exportieren” der RPC-Schnittstelle (Typen der Parameter...)
- Client erfragt beim Binder
- “look up”; “importieren” der RPC-Schnittstelle
- Vorteile: im Prinzip kann Binder- mehrere Server für den gleichen Service registrieren (→ Fehlertoleranz; Lastausgleich)- Autorisierung etc. überprüfen- durch Polling der Server die Existenz eines Services testen
- zentraler Binder ist ein potentieller Engpass(Binding-Service geeignet verteilen? Konsistenz!)
- dynamisches Binden kostet Ausführungszeit
- Probleme:
register
look up
DynamischesBinden mittelseines “Binders”
gemeinsames Übersetzen / statisches Binden (fehlende gem. Umgebung)
- ggf. auch wieder abmelden
- verschiedene Versionen eines Dienstes verwalten
dann eher “Trader”oder “Broker”
die Adresse eines geeigneten Servers
oft auch “registry” oder“look-up service” genannt
Vert. Sys., F. Ma. 125
Asynchroner RPC
- auftragsorientiert → Antwortverpflichtung
call X(...), reply to Y; remote procedure X(...,... )begin
end
return(...,...)await Y(...)
Client Server
. . .
. . .
call
accept return reply
await
Client blockiert
Server bearbei-tet Auftrag
Client
Server
. . .
. . .
- Parallelverarbeitung von Client und Server möglich, solange Client noch nicht auf Resultat angewiesen
receive
ggf. optional
. . .oder:
accept(...)
return(...)
...
...
...
- andere Bezeichnung: “Remote Service Invocation”
Vert. Sys., F. Ma. 126
Future-Variablen
- Spracheinbettung evtl. auch durch “Future-Variablen”- Future-Variable = handle, der wie ein Funktionsergebnis in Ausdrücke eingesetzt werden kann
- Auswertung der Future-Variable erst, wenn unbedingt nötig
- Blockade nur dann, falls Inhalt bei Auswertung noch nicht feststeht
FUTURE future: integer;some_value: integer;…future = call(…);…some_value = 4711;print(some_value + future);
- Zuordnung Auftrag / Ergebnisempfang bei der
- unterschiedliche Ausprägung auf Sprachebene möglich
- “await” könnte z.B. einen bei “call” zurückgelieferten “handle” als Parameter erhalten (also z.B. Y = call X(...); ... await (Y); )
- ggf. könnte die Antwort auch asynchron in einem eigens dafür vorgesehenen Anweisungsblock empfangen werden (vgl. Interrupt-oder Exception-Routine)
- Beispiel:
asynchron-auftragsorientierten Kommunikation?
Vert. Sys., F. Ma. 127
Die Socket-Programmierschnittstelle
- Zu TCP (bzw. UDP) gibt es keine festgelegten “APIs”
- Bei UNIX sind dafür “sockets” als Zugangspunkte zum Transportsystem entstanden
- Semantik eines sockets: analog zu Datei-Ein/Ausgabe
-diese definieren in einer Sprache (z.B. Java) dann eine Art “API”
- ein socket kann aber auch mit mehreren Prozessen verbunden sein
- Programmiersprachliche Einbindung (C, Java etc.)- sockets werden wie Variablen behandelt (können Namen bekommen)- Beispiel in C (Erzeugen eines sockets):
int s;s = socket(int PF_INET, int SOCK_STREAM, 0);
“Type”: Angabe, ob TCP verwendet(“stream”); oder UDP (“datagram”)
“Family”: Internet odernur lokale Domäne
- Bibliotheksfunktion “socket” erzeugt einen Deskriptor- wird innerhalb der Filedeskriptor-Tabelle des Prozesses angelegt- Datenstruktur wird allerdings erst mit einem nachfolgenden “bind”- Aufruf mit Werten gefüllt (binden der Adressinformation aus Host- Adresse und einer “bekannten” lokalen Portnummer an den socket)
Datenstruk-turen vonDateien
Family
Type
Local IP
Remote IP
...
Socket-deskriptor
Vert. Sys., F. Ma. 128
Client-Server mit Sockets (Prinzip)Server
socket();bind();listen();accept();
read();write();...close();
Client
socket();
connect();
write();read();...close(); Zeit
- Voraussetzung: Client kennt die IP-Adresse des Servers sowie die Portnummer (des Dienstes)
- muss beim connect angegeben werden
- Mit “listen” richtet der Server eine Warteschlange für Client-connect-Anforderungen ein
- Auszug aus der Beschreibung: “If a connection request arriveswith the queue full, tcp will retry the connection. If the backlog is not cleared by the time the tcp times out, the connect will fail”
- Accept / connect implementieren ein “Rendezvous”- mittels des 3-fach-Handshake von TCP- bei “connect” muss der Server bereits listen / accept ausgeführt haben
Serverwirdblockiert
- Rückgabewerte von write bzw. read: Anzahl der tatsächlich gesendeten / empfangenen Bytes
Abbruchbei closedes Ser-vers oderClients
- Varianten: Es gibt ein select, ein nicht-blockierendes accept etc., vgl. dazu die (Online-)Literatur
Vert. Sys., F. Ma. 129
Ein Socket-Beispiel in C
- Header-Dateien mit C-Daten-Strukturen, Konstanten etc.- Verwendung von sockets in C erfordert u.a.
- Programmcode zum Anlegen, Füllen etc. von Strukturen- Fehlerabfrage und Behandlung
- Socket-Programmierung ist ziemlich “low level”- etwas umständlich, fehleranfällig bei der Programmierung- aber “dicht am Netz” und dadurch ggf. manchmal von Vorteil
#include <sys/types.h>#include <sys/socket.h>#include <netinet/in.h>#include <netdb.h>#include <stdio.h>
#define PORT 4711#define BUF_SIZE 1024
main(argc,argv)int argc;char *argv[];{ int sock, run; char buf[BUF_SIZE]; struct sockaddr_in server; struct hostent *hp; if(argc != 2) { fprintf(stderr,”usage: client <hostname>\n”); exit(2); }
- Zunächst der Quellcode für den Client:
Vert. Sys., F. Ma. 130
/* create socket */ sock = socket(AF_INET,SOCK_STREAM,0); if(sock < 0) { perror(“open stream socket”); exit(1); } server.sin_family = AF_INET;
/* get internet address of host specified by command line */ hp = gethostbyname(argv[1]); if(hp == NULL) { fprintf(stderr,”%s unknown host.\n”,argv[1]); exit(2); } /* copies the internet address to server address */ bcopy(hp->h_addr, &server.sin_addr, hp->h_length); /* set port */ server.sin_port = PORT; /* open connection */ if(connect(sock,&server,sizeof(struct sockaddr_in)) < 0) { perror(“connecting stream socket”); exit(1); } /* read input from stdin */ while(run=read(0,buf,BUF_SIZE)) { if(run<0) { perror(“error reading from stdin”); exit(1); } /* write buffer to stream socket */ if(write(sock,buf,run) < 0) { perror(“writing on stream socket”); exit(1); } }
close(sock);}
Socket-Beispiel: Client
Vert. Sys., F. Ma. 131
#include <sys/types.h>#include <sys/socket.h>#include <netinet/in.h>#include <netdb.h>#include <stdio.h>
#define PORT 4711 /* random port number */#define MAX_QUEUE 1#define BUF_SIZE 1024
main(){ int sock_1,sock_2; /* file descriptors for sockets */ int rec_value, length; char buf[BUF_SIZE]; struct sockaddr_in server;
/* create stream socket in internet domain*/ sock_1 = socket(AF_INET,SOCK_STREAM,0); if (sock_1 < 0) { perror(“open stream socket”); exit(1); } /* build address in internet domain */ server.sin_family = AF_INET; /* everyone is allowed to connet to server */ server.sin_addr.s_addr = INADDR_ANY; server.sin_port = PORT; /* bind socket */ if(bind(sock_1,&server,sizeof(struct sockaddr_in))) { perror(“bind socket to server_addr”); exit(1); }
Socket-Beispiel: Server
Vert. Sys., F. Ma. 132
listen(sock_1,MAX_QUEUE); /* start accepting connection */ sock_2 = accept(sock_1,0,0); if(sock_2 < 0) { perror(“accept”); exit(1); } /* read from sock_2 */ while (rec_value=read(sock_2,buf,BUF_SIZE)) { if(rec_value<0) { perror(“reading stream message“); exit(1); } else write(1,buf,rec_value); } printf(“Ending connection.\n“);
close(sock_1); close(sock_2);}
1) Beispiel genau studieren; Semantik der socket-Operationen etc.
- Sinnvolle praktische Übungen (evtl. auch in Java):
nachlesen: Bücher oder Online-Dokumentation (z.B. von UNIX)2) Varianten und andere Beispiele implementieren, z.B.:
- Server, der zwei Zahlen addiert und Ergebnis zurücksendet- Produzent / Konsument mit dazwischenliegendem Pufferprozess (unter Vermeidung von Blockaden bei vollem Puffer)
- Messung des Durchsatzes im LAN; Nachrichtenlängen in mehreren Experimenten jeweils verdoppeln
- Server, der mehrere Clients gleichzeitig bedienen kann- Trader, der geeignete Clients und Server zusammenbringt
Socket-Beispiel: Server (2)
Vert. Sys., F. Ma. 133
Übungsbeispiel: Sockets unter Java
- Paket java.net.* enthält u.a. die Klasse “Socket”
- Auch unter Java lassen sich Sockets verwenden
- Streamsockets (verbindungsorientiert) bzw. Datagrammsockets
DataInputStream in;PrintStream out;Socket server;...server = new Socket(getCodeBase().getHost(),7); // Klasse Socket besitzt Methoden // getInputStream bzw. getOutputStream, hier // Konversion zu DataInputStream / PrintStream:in = new DataInputStream(server.getInputStream());out = new PrintStream(server.getOutputStream());... // Etwas an den Echo-Server senden:out.println(...)... // Vom Echo-Server empfangen; vielleicht // am besten in einem anderen Thread:String line;while((line = in.readLine()) != null) // line ausgeben...server.close;
Hostname Echo-Port
Herstellen einer Verbindung
Port Nummer 7 sendet alles zurück
- Zusätzlich: Fehlerbedingungen mit Exceptions behandeln (“try”; “catch”)
- z.B. “UnknownHostException” beim Gründen eines Socket
- Beispiel:
- sogar bequemer als unter C
(auf den nächsten 5 Seiten)
Vert. Sys., F. Ma. 134
Client-Server mit Sockets in Java
- Beispiel aus dem BuchJava Distributed Computingvon Jim Farley (O’Reilly)
import java.lang.*;import java.net.*;import java.io.*;
public class SimpleClient{ // Our socket connection to the server protected Socket serverConn;
public SimpleClient(String host, int port) throws IllegalArgumentException { try { System.out.println(“Trying to connect to “ + host + “ “ + port); serverConn = new Socket(host, port); } catch (UnknownHostException e) { throw new IllegalArgumentException (“Bad host name given.“); } catch (IOException e) { System.out.println(“SimpleClient: “ + e); System.exit(1); }
System.out.println(“Made server connection.“); }
- Hier der Client:
Konstruktor
Vert. Sys., F. Ma. 135
public static void main(String argv[]) { if (argv.length < 2) { System.out.println (“Usage: java \ SimpleClient <host> <port>“); System.exit(1); }
int port = 3000; String host = argv[0]; try { port = Integer.parseInt(argv[1]); } catch (NumberFormatException e) {}
SimpleClient client = new SimpleClient(host, port); client.sendCommands(); }
public void sendCommands() { try { DataOutputStream dout = new DataOutputStream(serverConn.getOutputStream()); DataInputStream din = new DataInputStream(serverConn.getInputStream());
// Send a GET command...dout.writeChars(“GET goodies “);
// ...and receive the results String result = din.readLine(); System.out.println(“Server says: \““ + result + “\““); } catch (IOException e) { System.out.println(“Communication SimpleClient: “ + e); System.exit(1); } }
public synchronized void finalize() { System.out.println(“Closing down SimpleClient...“); try { serverConn.close(); } catch (IOException e) { System.out.println(“Close SimpleClient: “ + e); System.exit(1); } }}
Host- und Port-nummer von derKommandozeile
Wird vom Garbage-Collector aufgerufen, wennkeine Referenzen auf den Client mehr existieren(‘close’ ggf. am Ende von ‘sendCommands’)
Vert. Sys., F. Ma. 136
import java.net.*;import java.io.*;import java.lang.*;
public class SimpleServer { protected int portNo = 3000; protected ServerSocket clientConnect;
public SimpleServer(int port) throws IllegalArgumentException { if (port <= 0) throw new IllegalArgumentException(
“Bad port number given to SimpleServer constructor.“);
// Try making a ServerSocket to the given port System.out.println(“Connecting server socket to port“); try { clientConnect = new ServerSocket(port); } catch (IOException e) {
System.out.println(“Failed to connect to port “ + port); System.exit(1); }
// Made the connection, so set the local port numberthis.portNo = port;
}
public static void main(String argv[]) { int port = 3000; if (argv.length > 0) { int tmp = port; try { tmp = Integer.parseInt(argv[0]); } catch (NumberFormatException e) {} port = tmp; }
SimpleServer server = new SimpleServer(port); System.out.println(“SimpleServer running on port “ + port + “...“);
server.listen(); }
Der Server
Default-Port, an dem der Serverauf eine Client-Verbindung wartet
Konstruktor
Portnummer vonKommandozeile
Aufruf der Methode“listen” (siehe unten)
Socket, der Verbindungs-wünsche entgegennimmt
Vert. Sys., F. Ma. 137
public void listen() { try { System.out.println(“Waiting for clients...“);
while (true) {Socket clientReq = clientConnect.accept();
System.out.println(“Got a client...“); serviceClient(clientReq); } } catch (IOException e) { System.out.println(“IO exception while listening.“); System.exit(1); } }
public void serviceClient(Socket clientConn) { SimpleCmdInputStream inStream = null; DataOutputStream outStream = null; try { inStream = new SimpleCmdInputStream (clientConn.getInputStream()); outStream = new DataOutputStream (clientConn.getOutputStream()); } catch (IOException e) { System.out.println(“SimpleServer: I/O error.“); } SimpleCmd cmd = null; System.out.println(“Attempting to read commands...“);
while (cmd == null || !(cmd instanceOf DoneCmd)) { try { cmd = inStream.readCommand(); } catch (IOException e) { System.out.println(“SimpleServer (read): “ + e); System.exit(1); }
if (cmd != null) { String result = cmd.Do(); try { outStream.writeBytes(result); } catch (IOException e) { System.out.println(“SimpleServer (write): “ + e); System.exit(1); } } } }}
Von DataInput-Stream abge-leitete Klasse
finalize-Methodehier nicht gezeigt
Warten auf connect eines Client,dann Gründen eines Sockets
Klasse SimpleCmd hier nicht gezeigt
Schleife zur Entgegennahme undAusführung von Kommandos
Vert. Sys., F. Ma. 138
Java als “Internet-Programmiersprache”- Java hat eine Reihe von Konzepten, die die Realisierung verteilter Anwendungen erleichtern, z.B.:
- Socket-Bibliothek zusammen mit Input- / Output-Streams- Remote Method Invocation (RMI): Entfernter Methodenaufruf mit Transport (und dabei Serialisierung) auch komplexer Objekte- CORBA-APIs- eingebautes Thread-Konzept- java.security-Paket- plattformunabhängiger Bytecode mit Klassenlader (Java-Klassen
können über das Netz transportiert und geladen werden; Bsp.: Applets)
try { DatagramSocket s = new DatagramSocket(); byte[] data = {’H’,’e’,’l’,’l’,’o’}; InetAddress addr = InetAddress.getByName(“my.host.com“); DatagramPacket p = new DatagramPacket(data, data.length, addr, 5000); s.send(p);}catch (Exception e) { System.out.println(“Exception using datagrams:“); e.printStackTrace();}
- Das UDP-Protokoll kann mit “Datagram-Sockets” verwendet werden, z.B. so:
- InetAddress-Klasse repräsentiert IP-Adressen
Port-Nummer
- diese hat u.a. Methoden “getByName” (klassenbezogene Methode) und “getAddress” (instanzbezogene Methode)
- entsprechend zu “send” gibt es ein “receive”
- UDP ist verbindungslos und nicht zuverlässig (aber effizient)
Damit z.B. Realisierung eines “Meta-Protokolls”: Über einenSocket vom Server eine Klasse laden (und Objekt-Instanz gründen),was dann (auf Client-Seite) ein spezifisches Protokoll realisiert.(Stichworte: “mobiler Code” bzw. Jini)
Vert. Sys., F. Ma. 139
URL-Verbindungen in Java
- falls auf diese mittels einer URL verwiesen wird
- Java bietet einfache Möglichkeiten, auf “Ressourcen” (i.w. Dateien) im Internet mit dem HTTP-Protokoll
- auf höherem Niveau als die Socket-Programmierung
- Klasse “URL” in java.net.*
- Sockets (mit TCP) werden vor dem Anwender verborgen benutzt
- Beispiel: zeilenweises Lesen einer Textdatei
// Objekt vom Typ URL anlegen:URL myURL;myURL = new URL(“http“, ... , “/Demo.txt“);...DataInputStream instream;instream = new DataInputStream(myURL.openStream());String line = ““;while((line = instream.readLine()) != null) // line verarbeiten...
Name der Datei
hier Hostname angeben
- Es ist auch möglich, Daten an eine URL zu senden
lesend und schreibend zuzugreifen
- hier nicht gezeigt: Abfangen diverser Fehlerbedingungen!
- Ferner: Information über das Objekt ermitteln- z.B. Grösse, letztes Änderungsdatum, HTTP-Header etc.
- POST-Methode, z.B. an Skript auf dem Server
Vert. Sys., F. Ma. 140
import java.io.*; import java.net.*;import java.util.Date; import java.text.DateFormat;
public class CheckBookmark {
public static void main (String args[]) throws java.io.IOException, java.text.ParseException {
if (args.length != 2) System.exit(1);
// Create a bookmark for checking...CheckBookmark bm = new CheckBookmark(args[0], args[1]);
bm.checkit(); // ...and check
switch (bm.state) { case CheckBookmark.OK: System.out.println(“Local copy of “ + bm.url_string + “ is up to date”); break; case CheckBookmark.AGED: System.out.println(“Local copy of “ + bm.url_string + “ is aged”); break; case CheckBookmark.NOT_SUPPORTED: System.out.println(“Webserver does not support \ modification dates”); break; default: break; } }
String url_string, chk_date; int state;
public final static int OK = 0; public final static int AGED = 1; public final static int NOT_SUPPORTED = 2;
CheckBookmark(String bm, String dtm) // Constructor { url_string = new String(bm); chk_date = new String(dtm); state = CheckBookmark.OK; }
Übungsbeispiel: Ein Bookmark-Checker(auf den nächsten 2 Seiten)
Vert. Sys., F. Ma. 141
public void checkit() throws java.io.IOException, java.text.ParseException {
URL checkURL = null;URLConnection checkURLC = null;
try { checkURL = new URL(this.url_string); } catch (MalformedURLException e) { System.err.println(e.getMessage() + “: Cannot \ create URL from “ + this.url_string); return; }
try { checkURLC = checkURL.openConnection(); checkURLC.setIfModifiedSince(60); checkURLC.connect(); }
catch (java.io.IOException e) { System.err.println(e.getMessage() + “: Cannot \
open connection to “ + checkURL.toString()); return; }
// Check whether modification date is supported if (checkURLC.getLastModified() == 0) { this.state = CheckBookmark.NOT_SUPPORTED; return; }
// Cast last modification date to a “Date“ Date rem = new Date(checkURLC.getLastModified());
// Cast stored date of bookmark to Date DateFormat df = DateFormat.getDateInstance(); Date cur = df.parse(this.chk_date);
// Compare and set flag for outdated bookmark if (cur.before(rem)) this.state = CheckBookmark.AGED; }}
Vert. Sys., F. Ma. 142
Adressierung
- Sender muss in geeigneter Weise spezifizieren, wohin die Nachricht gesendet werden soll
- Empfänger ist evtl. nicht bereit, jede beliebige Nachricht von jedem Sender zu akzeptieren
- ggf. mehrere Adressaten zur freien Auswahl (Lastverteilung, Fehlertoleranz)
- ggf. mehrere Adressaten gleichzeitig (Broadcast, Multicast)
- selektiver Empfang (Spezialisierung)- Sicherheitsaspekte, Überlastabwehr
- Probleme- Ortstransparenz: Sender weiss wer, aber nicht wo (sollte er i.a. auch nicht!)
- Anonymität: Sender und Empfänger kennen einander zunächst nicht (sollen sie oft auch nicht)
Vert. Sys., F. Ma. 143
Kenntnis von Adressen?
- Adressen sind u.a. Rechneradressen (z.B. IP-Adresse
1) Fest in den Programmcode integriert → unflexibel
oder Netzadresse in einem LAN), Portnamen, Socketnummern, Referenzen auf Mailboxes...
- Woher kennt ein Sender die Adresse des Empfängers?
3) Adressanfrage per Broadcast “in das Netz”- häufig bei LANs: Suche nach lokalem Nameserver, Router etc.
4) Auskunft fragen (Namensdienst wie z.B. DNS; Lookup-Service)- wie realisiert man dies effizient und fehlertolerant?
2) Über Parameter erhalten oder von anderen Prozessen mitgeteilt
Vert. Sys., F. Ma. 144
Direkte Adressierung
- Direct Naming (1:1-Kommunikation):
S ENachrichtenkanal
send (...) to E receive (...) [from S]
Was aber ist ein Name? Woher kommt er?- “Konstante” bei Übersetzungszeit?- Referenz auf einen dynamischen Prozess?
Hier vielleichtauch eineMenge vonpotentiellenSendern?
- Empfänger (= Server) sollten nicht gezwungen sein,potentielle Sender (= Client) explizit zu nennen
- Direct naming ist insgesamt relativ unflexibel
- Symmetrie ist also i.a. gar nicht erwünscht
Vert. Sys., F. Ma. 145
Indirekte Adressierung - Mailbox- Ermöglicht m:n-Kommunikation
Sm En
send (...) to M receive (...) from M
S1E1
.
.
.
.
.
.M
- Eine Nachricht besitzt i.a. mehrere potentielle Empfänger
- Kann jeder Empfänger die Nachricht bearbeiten?- Mailbox i.a. typisiert: nimmt nur bestimmte Nachrichten auf- Empfänger kann sich u.U. Nachrichten der Mailbox ansehen / aussuchen...
- Wo wird die Mailbox angesiedelt? (→ Implementierung)- als ein einziges Objekt auf irgendeinem (geeigneten) Rechner?- repliziert bei den Empfängern? Abstimmung unter den Empfängern notwendig (→ verteiltes Cache-Kohärenz-Problem)- Nachricht verbleibt in einem Ausgangspuffer des Senders: Empfänger müssen sich bei allen (welche sind das?) potentiellen Sendern erkundigen
- aber wer garantiert, dass jede Nachricht irgendwann ausgewählt wird?
- Mailbox muss gegründet werden: Wer? Wann? Wo?
- Mailbox spezifiziert damit eine Gruppe von Empfängern
Vert. Sys., F. Ma. 146
Indirekte Adressierung - Ports- m:1-Kommunikation
- Ports sind Mailboxes mit genau einem Empfänger
- Ein Objekt kann i.a. mehrere Ports besitzen
thread
P1P2
P3send (...) to P2
receive (...) from P1
- Sind Ports statische oder dynamische Objekte?
- Sind Ports typisiert?
- Können Ports geöffnet und geschlossen werden?
- Wie erfährt ein Objekt den Portnamen eines anderen (dynamischen) Objektes?
Pragmatische Aspekte (Sprachdesign etc.):
- würde den selektiven Nachrichtenempfang unterstützen
- genaue Semantik?
- Port gehört diesem Empfänger- Kommunikationsendpunkt, der die interne Empfängerstruktur abkapselt
- können Namen von Ports verschickt werden?
- Grösse des Nachrichtenpuffers?
Vert. Sys., F. Ma. 147
Kanäle und Verbindungen- Neben Eingangsports (“in-port”) lassen sich auch
Ausgangsports (“out-port”) betrachten
I2
I1 O2
O1
I2I1
O1
I1O2
O1
- Ports können als Ausgangspunkte für das Einrichten von Verbindungen (“Kanäle”) gewählt werden
- Dazu werden je ein in- und out-Port miteinander verbunden. Dies kann z.B. mit einer connect- Anweisung geschehen: connect p1 to p2
- Die Programmierung und Instanziierung eines Objektes findet so in einer anderen Phase statt als die Festlegung der Verbindungen
- Grössere Flexibilität durch die dynamische Änderung der Verbindungsstruktur
send (...) to O2;receive (...) from I1;
- Kommunikationsbeziehung: wahlweise 1:1, n:1, 1:n, n:m
Konfigura-tionsphase
Alternativ: Kanälebenennen undetwas auf denKanal senden bzw.von ihm lesen
- denkbar sind auch broadcastfähige Kanäle
Vert. Sys., F. Ma. 148
Varianten beim Empfangen von
- Typischerweise ist ein “receive” blockierend
Nachrichten - Nichtblockierung
- Aber auch nichtblockierender Empfang ist denkbar:
Nach-richt vor-handen?
janein
- Sprachliche Realisierung z.B. durch“Returncode” eines als Funktions-aufruf benutzten “receive”
- Aktives Warten:
Nach-richt vor-handen? ja
neinNachrichtempfangen
AndereAktivitäten
- Nachbildung desblockierenden Wartenswenn “andere Aktivi-täten” leer
- Nur für kurze Wartezeitensinnvoll, da Monopolisierungder cpu, die ggf. für andereProzesse oder threads gebrauchtwerden könnte (“spin locks”)
- “Non-blocking receive”
- Weitere Möglichkeit: unterbrechungsgesteuertes (“asynchrones”) Empfangen der Nachricht (→ nicht unproblematisch!)
(“busy waiting”)
Vert. Sys., F. Ma. 149
Alternatives Empfangen
- Sprachliche Realisierung z.B. so:
select
guard1 → receive
Statements
guardn → receive
Statements
.
endselect
[ else . . . ]
.
.
else-Fall wird gewählt,wenn kein guard ‘true’ist bzw. dort momentankeine Nachricht anliegt
- Aktives Warten durch umschliessende while-Schleife
- bei else könnte im Fall von aktivem Warten die while-Bedingung auf false gesetzt werden, falls das Warten abgebrochen werden soll, oder es könnte mittels timer (“wait”) eine kurze Zeit gewartet werden
- else-Fall kann auch einfach das leere Statement enthalten
- Typischerweise nichtblockierend; aber blockierend, wenn else-Alternative fehlt
Boole’scher Ausdruck:zugehörige Anweisungsfolgekann nur ausgeführt werden,wenn dieser zu true evaluiertwird und beim zugehörigenreceive eine Nachricht anliegt
- Was geschieht, wenn mehrere guards “true” sind?→ nichtdeterministische Auswahl, Wahl des ersten Falles...
Vert. Sys., F. Ma. 150
Zeitüberwachte Kommunilation
- Empfangsanweisung soll maximal (?) eine gewisse Zeit lang blockieren (“timeout”)
- z.B. über return-Wert abfragen, ob Kommunikation geklappt hat
- Sinnvoll bei:
- Echtzeitprogrammierung
- Vermeidung von Blockaden im Fehlerfall (etwa: abgestürzter Kommunikationspartner)
→ dann sinnvolle Recovery-Massnahmen treffen (“exception”)→ timeout-Wert “sinnvoll” setzen!
Quelle vielfältiger Probleme...
- Analog ggf. auch für synchrones (!) Senden sinnvoll→ Verkompliziert zugrundeliegendes Protokoll: Implizite Acknowledgements kommen nun “asynchron” an...
- Timeout-Wert = 0 kann ggf. genutzt werden, um zu testen, ob eine Nachricht “jetzt” da ist
Vert. Sys., F. Ma. 151
- Sprachliche Einbindung besser z.B. so:
receive ... delay t
selectguard1 → receive ...
delay t → Anweisungen ...
...
endselect
Wird nach mind. t Zeitein-heiten ausgeführt, wennbis dahin noch keineNachricht empfangen
Blockiert maximalt Zeiteinheiten
Vorsicht!
- Genaue Semantik beachten: Es wird mindestens so lange auf Kommu- nikation gewartet. Danach kann (wie immer!) noch beliebig viel Zeit bis zur Fortsetzung des Programms verstreichen!
- Möglicher Realisierung:
- Durch einen Timer einen asynchronenInterrupt aufsetzen und Sprungziel benennen
- Sprungziel könnte z.B. eine Unterbrechungs-routine sein, die in einem eigenen Kontext ausge-führt wird, oder das Statement nach dem receive
→ “systemnahe”, unstrukturierte, fehleranfällige Lösung; schlechter Programmierstil!
Zeitüberwachter Nachrichtenempfang
- Frage: sollte “delay 0” äquivalent zu “else” sein?
- bzw. so:
Vert. Sys., F. Ma. 152
- Bedingung an den Inhalt (bzw. Typ, Format,...)
Selektives Empfangen
der zu empfangenden Nachricht
≠ alternatives!
- Dadurch werden gewisse (“unpassende”) Nach- richten einfach ausgeblendet
- Bedingung wird oft vom aktuellen Zustand des Empfängers abhängen
- Vorteil bei der Anwendung:
Empfänger muss nicht mehr alles akzeptieren undzwischenspeichern, sondern bekommt nur das,was ihn momentan interessiert
Vert. Sys., F. Ma. 153
Implizites Empfangen
- Keine receive, select...-Anweisung, sondern Spezifi- kation von Routinen, die bei Vorliegen einer Nachricht ausgeführt (“angesprungen”) werden
- z.B. RPC: remote procedure1
end procedure1
remote proceduren
end proceduren
...
- Analog auch für den “Empfang” einer Nachrichtohne Antwortverpflichtung denkbar
- Semantik:
- Interne Parallelität?- Mehr als eine gleichzeitig aktive Prozedur, Methode, thread... im Empfänger?
- Atomare Routinen?- Wird eine aktive Routine ggf. unterbrochen, um eine andere aktivierte auszuführen?
- Vielleicht sogar mehrere Instanzen der gleichen Routine?
bzw. asynchro-ne Variante oder
“Routine”
“Remote MethodInvocation” beiobjektorientiertenSystemen
Vert. Sys., F. Ma. 154
Kommunizierbare Datentypen?- Werte von “klassischen” einfachen Datentypen
- int, character, string, floating point,...
- Kompatibilität in heterogenen Systemen- Grösse von int?- Codierung von Text?- höherwertiges Bit links oder rechts?- ...
encode decode
- Vereinbarung einer Standardrepräsentation (z.B. XDR)- marshalling (encode / decode) kostet Zeit
- Was ist mit komplexen Datentypen wie
- Records, Strukturen
- Objekte
- Referenzen, Zeiger
- Zeigergeflechte
- sollen Adressen über Rechner- / Adressraumgrenzen erlaubt sein?
- sollen Referenzen symbolisch, relativ... interpretiert werden? Ist das stets möglich?
- Sind (Namen von) Ports, Prozessen... eigene Datentypen, deren Werte versendet werden können?
“first class objects”
- wie wird Typkompatibilität sichergestellt?
- Ggf. “Linearisieren” und ggf. Strukturbeschreibung mitschicken (u.U. “sprachunabhängig”)
Vert. Sys., F. Ma. 155
Gruppen-kommunikation
Vert. Sys., F. Ma. 156
Broadcast: Senden an die Gesamtheit aller Teilnehmer
Multicast: Senden an eine Untergruppe aller Teilnehmer
N
N
N
N
N
N
N
N
N
N
NN
M
M
M
M
M N
Gruppenkommunikation
- verschiedene Gruppen können sich ggf. überlappen- entspricht Broadcast bezogen auf die Gruppe
- jede Gruppen hat eine Multicastadresse
Vert. Sys., F. Ma. 157
Info
Ser-
Info
InfoInfo
Info Info Info Info
Anwendungen von
Info
Info
Info
Info
?
- Informieren
- Suchen
- “Logischer Unicast” an replizierte Komponenten
- z.B. Newsdienste
- z.B. Finden von Objekten und Diensten
logisch
tatsächlich
Typische Anwendungs-klasse von Replikation:Fehlertoleranz
Gruppenkommunikation
vice
1)
2)
Vert. Sys., F. Ma. 158
Gruppenkommunikation- idealisierte Semantik
P1
P2
P3
P1
P2
P3
Zeit
- Modellhaftes Vorbild: Speicherbasierte Kommuni-
- augenblicklicher Empfang
kation in zentralistischen Systemen
- vollständige Zuverlässigkeit (kein Nachrichtenverlust etc.)
- Nachrichtenbasierte Kommunikation: Idealisierte Sicht- (verzögerter) gleichzeitiger Empfang- vollständige Zuverlässigkeit
Vert. Sys., F. Ma. 159
Gruppenkommunikation- tatsächliche Situation
P1
P2
P3
- Beachte: Verlust von Nachrichten und sonstige Fehler sind bei Broadcast ein ernsteres Problem als beim “Unicast”! (Wieso?)
- möglichst gute Approximation einer speicherbasierten Kommunikation- möglichst hohe Verlässlichkeit und Effizienz
- Ziel von Broadcast / Multicast-Protokollen:
- indeterministische Zeitverzögerung → Empfang zu unterschiedlichen Zeiten
- nur bedingte Zuverlässigkeit der Übermittlung
- Nachrichtenkommunikation ist nicht “ideal”
- Hauptproblem bei der Realsierung von Broadcast: (1) Zuverlässigkeit und (2) garantierte Empfangsreihenfolge
- Medium (Netz) ist oft nicht multicastfähig- LANs teilweise (z.B. klassisches Ethernet), jedoch i.a. nur innerhalb von Teilstrukturen; WLAN als Funknetz
- multicastfähiges Netz ist effizient (Hardwareunterstützung), typischerweise jedoch nicht verlässlich (keine Empfangsgarantie)
- bei Punkt-zu-Punkt-Netzen: “Simulation” von Multicast durch ein Protokoll (z.B. Multicast-Server, der an alle einzeln weiterverteilt)
Vert. Sys., F. Ma. 160
Senderausfall beim Broadcast
- „günstiger“ Fall: Einigkeit unter den Überlebenden!
a) Sender fällt ganz aus: kein Empfänger erhält Nachricht
S EEEE
b) Sender fällt während des Sendevorgangs aus: nur einige Empfänger erhalten u.U. die Nachricht
- “ungünstiger” Fall: Uneinigkeit
S EEEE
- mögliche Abhilfe: Empfänger leiten die Nachricht untereinander weiter
Wenn Broadcast implementiert ist durch Senden vieler Einzelnachrichten
- Uneinigkeit der Empfänger kann die Ursache für sehr ärgerliche Folgeprobleme sein! (Da wäre es manchmal besser, gar kein Prozess hätte die Nachricht empfangen!)
Vert. Sys., F. Ma. 161
Zuverlässigkeitsgrad
- Euphemistische Bezeichnung, da keine extra Anstrengung- typischerweise einfache Realisierung ohne Acknowledgements etc.
- Keinerlei Garantien- unbestimmt, wieviele / welche Empfänger eine Broadcastnachricht im Fehlerfall tatsächlich empfangen
- Allerdings effizient (im Erfolgsfall)
- unbestimmte Empfangsreihenfolge
- Geeignet für die Verbreitung unkritischer Informationen
- Ggf. als Grundlage zur Realisierung höherer Protokolle
- z.B. Informationen, die ggf. Einfluss auf die Effizienz haben, nicht aber die Korrektheit betreffen
- oft basierend auf der A-priori-Broadcastfähigkeit von Netzen
- günstig bei zuverlässigen physischen Kommunikationsmedien (wenn Feh- lerfall sehr selten → aufwendiges Recovery auf höherer Ebene tolerierbar)
“best effort” bei Broadcasts
- Fehlermodell: Verlust von Nachrichten (und ggf. temporärer Crash von Prozessen)
- Nachrichten können aus unterschiedlichen Gründen verloren gehen (z.B. Netzüberlastung, Empfänger hört gerade nicht zu...)
Kann z.B. beim Software-update über Satellit zu einemziemlichen Chaos führen
Vert. Sys., F. Ma. 162
4
33 3
43 4
8 86 4
3
x ➝ x + 1
x ➝ 2x
(A)
(B)
(C)
k-Zuverlässigkeit
- Problem der Fehlerakkumulation:- der Zustand (repräsentiert durch eine Variable x) sei repliziert
- Zustandssynchronisation werde durch “function shipping”
Zeit
- Ergebnis nach einiger Zeit: Alle Replikate sind verschieden!
- in einem solchen Fall hilft also k-Zuverlässigkeit nicht viel
- Mindestens k Teilnehmer haben die Nachricht empfangen- grössere Werte von k sind “teurer”- Denkübungen: Wie realisiert man einen k-zuverlässigen Multicast? Ist ein “100%ig zuverlässiger” Broadcast überhaupt möglich? Wo lässt sich dies (für welches k?) sinnvoll verwenden?
mittels 2-zuverlässigem Broadcast realisiert
Vert. Sys., F. Ma. 163
?
“Reliable Broadcast”
- Quittung (“positives Acknowledgement”: ACK) für jede
- alle broadcasts werden vom Sender aufsteigend numeriert
- Skizze einer anderen Idee (“negatives Ack.”: NACK):
- Empfänger stellt beim nächsten Empfang u.U. eine Lücke fest
- für fehlende Nachrichten wird ein “negatives ack” (NACK) gesendet
- Sender muss daher Kopien von Nachrichten (wie lange?) aufbewahren
- “Nullnachrichten” sind u.U. sinnvoll (→ schnelles Erkennen von Lücken)
- Kombination von ACK / NACK mag sinnvoll sein
- Dies hilft aber nicht, wenn der Sender mittendrin crasht!
- Ziel: Unter gewissen Fehlermodellen einen “möglichst zuverlässigen” Broadcast-Dienst realisieren
Einzelnachricht ist teuer- im Verlustfall einzeln nachliefern oder (falls broadcastfähiges Medium
vorhanden) einen zweiten Broadcast-Versuch? (→ Duplikaterkennung!)
und fehlende nachliefern
Vert. Sys., F. Ma. 164
Sender s: Realisierung von broadcast(N)
– send(N, s, sequ_num) an alle Nachbarn (inklusive an s selber);
– sequ_num ++
Empfänger r: Realisierung des Nachrichtenempfangs
– receive(N, s, sequ_num);wenn r noch kein deliver(N) für sequ_num ausgeführt hat, dann:
wenn r ≠ s dann send(N, s, sequ_num) an alle Nachbarn von r ;Nachricht an die Anwendungsebene ausliefern (“deliver(N)”) ;
Reliable-Broadcast-Algorithmus
- Zweck: Jeder nicht gecrashte und zumindest indirekt erreichbare Prozess soll die Broadcast-Nachricht erhalten
- Voraussetzung: zusammenhängendes “gut vermaschtes”
- Fehlermodell: Knoten und Verbindungen mit Fail-Stop-Charakteristik
- Fragen:
- wie effizient ist das Verfahren (Anzahl der Einzelnachrichten)?- wie fehlertolerant? (wieviel darf kaputt sein / verloren gehen...?)- Optimierungen? Varianten?
Punkt-zu-Punkt-Netz
- Beachte: receive ≠ deliver- unterscheide Anwendungsebene und Transportebene
- kann man das gleiche auch ganz anders erreichen?
- Prinzip: “Fluten” des Netzes- vgl. dazu “Echo-Algorithmus” und Vorlesung “Verteilte Algorithmen”
- müssen die Kommunikationskanäle bidirektional sein?
Vert. Sys., F. Ma. 165
Broadcast: Empfangsreihenfolge
- FIFO-Ordnung:
Alle Multicast-Nachrichten eines (d.h.: ein und desselben) Senders an eine Gruppe kommen bei allenMitgliedern der Gruppe in FIFO-Reihenfolge an
- Denkübung: wie dies in einem Multicast-Protokoll garantieren?
- Es sind verschiedene “Ordnungsgrade” denkbar- z.B. ungeordnet, FIFO, kausal geordnet, total geordnet
- Wie ist die Empfangsreihenfolge von Nachrichten?- problematisch wegen der i.a. ungleichen Übermittlungszeiten
- Bsp.: Update einer replizierten Variablen mittels “function shipping”:
P1
P2
P3
x = 6 x = 7x = 3
x = 3 x = 4 x = 8
x ➝ 2x x ➝ x + 1
Vert. Sys., F. Ma. 166
==> Falsche Schlussfolgerung des Beobachters:“Aufgrund einer unbegreiflichen Pumpenaktivität wurde
Probleme mit FIFO-Broadcasts
Man sieht also:
- FIFO-Reihenfolge reicht oft nicht aus, um Semantik zu wahren
- eine Nachricht verursacht oft das Senden einer anderen
- “Irgendwie” kommt beim Beobachter die Reihenfolge durcheinander!
Kausalität
kleines Leck
“erhöhe Druck”
Pumpe
Druckmesser
Beobachter
Druck-
Druck-
verlust Zeit
ve
e’ v’
Druck-messer
Pumpe
erhöhung
(Leitstand)
- Annahme: Steuerelemente kommunizieren über FIFO-Broadcasts:
ein Leck erzeugt, wodurch schliesslich der Druck absank.”
Vert. Sys., F. Ma. 167
Wenn ein Zuschauer von der Ferne das Exercieren eines Batail-lons verfolgt, so sieht er übereinstimmende Bewegungen dessel-ben plötzlich eintreten, ehe er die Commandostimme oder dasHornsignal hört; aber aus seiner Kenntnis der Causalzusammen-hänge weiß er, daß die Bewegungen die Wirkung des gehörtenCommandos sind, dieses also jenen objectiv vorangehen muß,und er wird sich sofort der Täuschung bewußt, die in der Umkeh-rung der Zeitfolge in seinen Perceptionen liegt.Christoph von Sigwart (1830-1904) Logik (1889)
Bataillon
Commandant
Zuschauer
CommandoBewegung
Wirkung Ursache
??
Das “Broadcastproblem” ist nicht neu
hören
sehen
Zeit
- Licht- und Schallwellen werden in natürlicher Weise per Broadcast verteilt- Wann handelt es sich dabei um FIFO-Broadcasts?
- Wie ist es mit dem Kausalitätserhalt?
Vert. Sys., F. Ma. 168
Kausale Broadcasts
Wahrung von Kausalität bei der Kommunikation:
• Kausale Reihenfolge (Def.): Wenn eine Nachricht N kausal voneiner Nachricht M abhängt, und ein Prozess P die Nachrichten Nund M empfängt, dann muss er M vor N empfangen haben
Beachte:
• “Kausale Reihenfolge” und “kausale Abhängigkeit” lassen sichinsbesondere auch auf Broadcasts anwenden
• Kausale Reihenfolge impliziert FIFO-Reihenfolge: kausale Rei-henfolge ist eine Art “globales FIFO”
• Das Erzwingen der kausalen Reihenfolge ist mittels geeigneterAlgorithmen möglich (→ Vorlesung “Verteilte Algorithmen”,z.B. Verallgemeinerung der Sequenzzählermethode für FIFO)
Kausale Abhängigkeit zwischen Nachrichten (Def.):
• Nachricht Y hängt kausal von Nachricht X ab, wenn es im Raum-Zeit-Diagramm einen von links nach rechts verlaufenden Pfad gibt,der vom Sendeereignis von X zum Sendeereignis von Y führt
Beachte:
• Dies lässt sich bei geeigneter Modellierung auch abstrakter fassen(→ vgl. logische Zeit später in der Vorlesung und auch Vorlesung“Verteilte Algorithmen”)
X Y
X
Y
X
Y
Sendeereig-nis von X
Sendeereig-nis von Y
keinekausaleAbhängigkeit!
Y
Y ist eine Broad-cast-Nachricht!
“causal order”
Vert. Sys., F. Ma. 169
Konkrete Ursache des Problems:
• Broadcasts werden nicht überall “gleichzeitig” empfangen
• dies führt lokal zu verschiedenen Empfangsreihenfolgen
Abstrakte Ursache:
• die Nachrichtenübermittlung erfolgt (erkennbar!) nicht atomar
P1
P2
P3
x = 4 x = 8
x = 3
x ➝ 2x
x = 6 x = 7
P4
x ➝ x + 1
x = 3
x = 3
x = 3
x = 7
x = 8
Probleme mit kausalen Broadcasts ?
Beispiel: Aktualisierung einer replizierten Variablen x:
Problem: Statt überall 7 oder 8 als Ergebnis: Hier “beides”!
Also:
• auch kausale Broadcasts haben keine “perfekte” Semantik(d.h. Illusion einer speicherbasierten Kommunikation)