Senden

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
vs2.3
1
Pseudocode für Senden und Empfangen:
send MsgExpr [ to DestExpr ]
Typ T
Typ D<T>
recv MsgVar [ from SourceExpr | SourceVar ]
Typ T
Typ S<T>
MsgExpr:
DestExpr:
zu sendende Nachricht
Ziel, das die Nachricht empfangen soll
MsgVar:
SourceExpr:
- oder SourceVar:
Variable, die die empfangene Nachricht aufnimmt
Quelle, von der die Nachricht empfangen werden soll
Variable, die die Quelle der Nachricht aufnimmt
vs2.3
2
Beispiel 1: ungepufferte Interprozeßkommunikation (z.B. CSP)
P:
...
send "Hello "+"World" to Q
...
! Rendezvous "
Q:
...
recv var from P
...
Effekt wie: var := "Hello World"
Beispiel 2: Ethernet Controller (ohne Adressen-Filterung)
P:
...
send "Hello "+"World"
...
wartet auf send "
Q:
...
recv var
...
Effekt wie: var := "Hello World", aber nur wenn Q mit recv wartet
- sonst wirkungslos!
vs2.3
3
2.3.1 Übertragungssemantik
Pufferung, Empfangsfolge, Zuverlässigkeit, Flußsteuerung/Synchronisation
 Pufferung:
- keine
- begrenzt
- unbegrenzt
Achtung, Teil des
Kommunikationssystems!
 Empfangsfolge:
- permutiertes Präfix der Sendefolge
- Präfix der Sendefolge (reihenfolgetreu, FCFS;
Puffertyp = Sequence<T> )
- Strom (stream): Puffertyp = T = Sequence<Byte>
vs2.3
4
 Zuverlässigkeit:
Empfangsfolge der Nachrichten evtl. gefährdet durch
- Duplizierung
- Verlust
- Verstümmelung: wird mittels Prüfcode
erkannt und als Verlust betrachtet
vs2.3
5
 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
vs2.3
6
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
vs2.3
7
2.3.2 Adressierung
Beachte:
Kommunikation ist nicht beschränkt auf das Szenario
„2 miteinander verbundene Kommunikationspartner“
4 Varianten:
ohne Adressierung
 prozessbezogen
 prozessgruppenbezogen
 kanalbezogen
vs2.3
8
ohne Adressierung:
send MsgExpr
recv MsgVar [ from ProcVar ]
produziert Nachricht übernimmt Nachricht
(evtl. mit Absender) (und gegebenenfalls Absender)
! Generische Operationen,
z.B. mit Nachrichtentyp Sequence<Byte>
vs2.3
9
 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!)
vs2.3
10
 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 ]
vs2.3
11
 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:
vs2.3
12
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 msg to proc.port4
recv var from port4
alternativ:
Port = der „Eingang“ oder der „Ausgang“ eines Kanals,
sozusagen „eine Hälfte“ eines Kanals
vs2.3
13
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
vs2.3
14
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
vs2.3
15
2.3.4 Disjunktives Warten
Beispiel:
Auftraggeber
Auftragnehmer
client
Unterauftragnehmer
server
for(;;) {
.....
recv request from client; .....
send subrequest to server; .....
recv subresult from server;.....
send result to client;
.....
}
vs2.3
recv behindern
sich gegenseitig!
16
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
! Alternative: Threads verwenden !
vs2.3
17