Vs2.3 1 2.3 Klassifizierung von Kommunikationsdiensten synonym:Nachrichtensystem/dienst(message service) Kommunikationssystem/dienst(communication service)

Präsentation zum Thema: "Vs2.3 1 2.3 Klassifizierung von Kommunikationsdiensten synonym:Nachrichtensystem/dienst(message service) Kommunikationssystem/dienst(communication service)"—  Präsentation transkript:

1 vs2.3 1 2.3 Klassifizierung von Kommunikationsdiensten synonym:Nachrichtensystem/dienst(message service) Kommunikationssystem/dienst(communication service) Transportsystem/dienst(transport service) Grundsätzliche semantische Gemeinsamkeit: Senden/Empfangen einer Nachricht beinhaltet Kopieren – zwei (oder mehr) disjunkte Prozesse/Prozessoren A, B (C,...) kooperieren zum Zweck des Kopierens eines Wertes von A nach B (C,...) Kommunikationsdienste variieren im Hinblick auf [  2.3.1]Übertragungssemantik [  2.3.2]Adressierung der Kommunikationspartner [  2.3.3]Konfigurierung von Prozessen und Kanälen [  2.3.4]Disjunktives Warten

2 vs2.3 2 Pseudocode für Senden send MsgExpr [ to DestExpr ] Typ TTyp D MsgExpr:zu sendende Nachricht DestExpr:Ziel, das die Nachricht empfangen soll MsgVar:Variable, die die empfangene Nachricht aufnimmt SourceExpr:Quelle, von der die Nachricht empfangen werden soll - oder - SourceVar:Variable, die die Quelle der Nachricht aufnimmt recv MsgVar [ from SourceExpr | SourceVar ] Typ T Typ S und Empfangen:

3 vs2.3 3 Beispiel 1: ungepufferte Interprozeßkommunikation (z.B. CSP) P:... send "Hello "+"World" to Q... Q:... recv var from P... Beispiel 2: Ethernet Controller (ohne Adressen-Filterung) P:... send "Hello "+"World"... Q:... recv var... Effekt wie: var := "Hello World"  Rendezvous  Effekt wie: var := "Hello World", aber nur wenn Q mit recv wartet - sonst wirkungslos! wartet auf send 

4 vs2.3 4 2.3.1 Übertragungssemantik Pufferung, Empfangsfolge, Zuverlässigkeit, Flußsteuerung/Synchronisation  Pufferung:- keine - begrenzt - unbegrenzt  Empfangsfolge: - permutiertes Präfix der Sendefolge - Präfix der Sendefolge (reihenfolgetreu, FCFS; Puffertyp = Sequence ) - Strom (stream): Puffertyp = T = Sequence Achtung, Teil des Kommunikations- systems!

5 vs2.3 5  Zuverlässigkeit: Empfangsfolge der Nachrichten evtl. gefährdet durch - Duplizierung - Verlust - Verstümmelung: wird mittels Prüfcode erkannt und als Verlust betrachtet

6 vs2.3 6  Flußsteuerung und Synchronisation: Empfangen mit recv : blockierend (blocking) bis neue Nachricht vorliegt, nichtblockierend (non-blocking), d.h. wenn keine neue Nachricht: - Leeroperation, evtl. mit späterer Unterbrechung, wenn Nachricht eingetroffen (signal), oder - nochmaliges Lesen einer zuvor empfangenen Nachricht Senden mit send : blockierend bis Nachricht absendbar, nichtblockierend, d.h. - Leeroperation, evtl. mit Ausnahmemeldung, oder - Überschreiben einer zuvor gesendeten und noch nicht empfangenen Nachricht

7 vs2.3 7 Synchrone vs. asynchrone Übertragung: asynchrone Übertragung: send ist beendet, sobald der Wert von MsgExpr an das Nachrichtensystem übergeben ist synchrone Übertragung: send ist beendet, sobald die Nachricht durch recv übernommen wurde

8 vs2.3 8 2.3.2 Adressierung Beachte: Kommunikation ist nicht beschränkt auf das Szenario „2 miteinander verbundene Kommunikationspartner“ 4 Varianten:  ohne Adressierung  prozessbezogen  prozessgruppenbezogen  kanalbezogen

9 vs2.3 9  ohne Adressierung: send MsgExpr recv MsgVar [ from ProcVar ] produziert Nachrichtübernimmt Nachricht (evtl. mit Absender)(und gegebenenfalls Absender) ! Generische Operationen, z.B. mit Nachrichtentyp T = Sequence

10 vs2.3 10  prozeßbezogen:(typischerweise auch generisch) send MsgExpr to ProcExpr recv MsgVar from ProcExpr send MsgExpr to ProcExpr recv MsgVar [ from ProcVar ] (Modell hier: jeder Prozeß verfügt über eigene mailbox) send MsgExpr [ to ProcVar ] recv MsgVar from ProcExpr (Umkehrung des obigen Modells – eher akademisch!)

11 vs2.3 11  prozeßgruppenbezogen (group communication, auch „Rundsendung“, multicast): Es gibt einen Typ ProcessGroup, und Prozesse können einer Gruppe beitreten und sie verlassen:... group.enter();... ; group.leave();... Damit dann send msg to group recv var [ from procvar ]

12 vs2.3 12  kanalbezogen/portbezogen Kanal als eigenständiges, explizit benennbares Pufferobjekt, meist unidirektional („Simplex-Kanal“): send MsgExpr to ChanExpr recv MsgVar from ChanExpr channel.send(msg);msg = channel.recv(); Wichtiger Begriff in Zusammenhang mit Kanälen: Port - mit verschiedenen Bedeutungen:

13 vs2.3 13 Port =formaler Kanalparameter eines Prozesses, häufig exklusiv entweder nur als Eingabe-Port für recv oder nur als Ausgabe-Port für send ( Beispiel: Unix-stdin/stdout über 0 bzw. 1) alternativ: Port =einem Prozeß fest zugeordneter Kanal: send msg1 to proc.port4recv var1 from port4 send msg2 to proc.port2recv var2 from port2 alternativ: Port =der „Eingang“ oder der „Ausgang“ eines Kanals, sozusagen „eine Hälfte“ eines Kanals

14 vs2.3 14 2.3.3 Konfigurierung bedeutet Einrichten von Prozessen und evtl. Kanälen sowie Binden, d.h. Aktualisierung formaler Parameter vom Typ Prozeß, Kanal, Port Statisches Binden: Hardware: durch „Strippenziehen“ zwischen Rechnern Software:mittels Konfigurationssprache, z.B. Unix Shell für Pipelines: who | sort | lpr Adressierung kanalbezogen:Kanal = pipe Ports = stdin, stdout

15 vs2.3 15 Dynamisches Binden: Prozesse besorgen die Konfigurierung selbst + jederzeit dynamische Umkonfigurierung möglich - Wiederverwendbarkeit in anderen Kontexten begrenzt Dynamische Erzeugung von Prozessen und Kanälen, dabei Binden durch geeignetes Initialisieren Namensdienste erlauben das Auffinden von bereits vorhandenen Prozess- bzw. Kanalobjekten

16 vs2.3 16 2.3.4 Disjunktives Warten Beispiel: clientserver for(;;) {..... recv request from client;..... send subrequest to server;..... recv subresult from server;..... send result to client;..... } blockierende recv behindern sich gegenseitig! Auftrag- nehmer Auftrag- geber Unter- auftrag- nehmer

17 vs2.3 17 Besser: nichtdeterministisch disjunktives Warten for(;;) {... select recv request from client; send subrequest to server; | recv subresult from server; send result to client; | timeout t do cleanup endselect;... } t = 0 wirkt wie ein otherwise/else-Konstrukt t =  wirkt wie fehlende Timeout-Klausel

18 vs2.3 18 Alternative: nebenläufige Ausführung (mit Threads o.ä.) cobegin for(;;) {... recv request from client;... send subrequest to server;... } || for(;;) {... recv subresult from server;... send result to client;... } coend ! Nachteil: Höhere Ressourcen-Anforderungen !