Die Türen sind noch offen, oder? Ich komme ja noch ein paar. Wir hatten uns das letzte Mal über

Interprozesskommunikationsmechanismen unterhalten und ich will mal so die paar ganz wesentlichen

Geschichten, um die es ging, noch mal kurz rausgreifen. Also es ging um die Frage, welche Art von

Botschaftenaustausch haben, sind sie synchron oder asynchron, puffern wir oder puffern wir nicht,

blockiert, blockieren wir, also warten wir drauf letztendlich oder warten wir nicht, was ein ganzes

Stück weit natürlich mit Synchronität oder Asynchronität korrespondiert und ist die

Datenübertragung oder die Botschaftsübertragung zuverlässig oder unzuverlässig. Und abhängig

davon gibt es natürlich die unterschiedlichsten Semantiken, die man für Interprozesskommunikation

definieren kann und die Frage natürlich auch, wie geht man mit Zustellungsfehlern um und welche

Semantiken ergeben sich auch da wieder draus. Gut und dann hatten wir noch über die verschiedenen

Kommunikationsendpunkte gesprochen, also mit wem kommunizieren wir eigentlich. Vielleicht

mal so die paar wesentlichen Bilder davon noch mal rausgegriffen. Gut einerseits die Frage Synchrone

Kommunikation, bei Synchrone Kommunikation, dass wir uns letztendlich blockieren. Einerseits

darauf, dass jemand die Nachricht annimmt. Auf der anderen Seite auch als Nachrichtenempfänger uns

darauf blockieren können, dass jemand die Nachricht absendet, also je nachdem wer eben zuerst dran ist.

Während bei der Asynchronen Kommunikation letztendlich ein Puffermechanismus in der Mitte,

der die Nachricht entgegennimmt und Sender und Empfänger können eigentlich erstmal

unabhängig voneinander arbeiten. Der Empfänger natürlich auch nur, kann nur in der Situation

weiterarbeiten, dass er im Puffer natürlich schon eine Nachricht vorfindet. Aber er muss

nicht darauf warten, dass der Sender genau in dem Augenblick eben was lossendet.

So, dann zentrales Thema waren die verschiedenen Interprozesskommunikationssemanitiken. Ich denke,

die sind in diesem einen Bild ganz gut zusammengefasst. Also einerseits die Frage immer,

wie lange blockieren wir eigentlich, wie lange warten wir, wenn wir kommunizieren,

warten wir nur so lange, bis wir die Nachricht im Endeffekt hier im lokalen Betriebssystem

losgeworden sind und es ist uns egal, was dann danach passiert oder warten wir so lange,

bis wir, bis die Nachricht im Kommunikationsmedium zumindest angekommen ist, also bis der lokale

Rechner sie losgeschickt hat, dass wir das blocking send, das reliable blocking send,

warten wir zumindest so lange, bis auch beim Empfänger die Nachricht angekommen ist, also

auf dem Empfangsrechner oder sogar das synchronisation send, warten wir so lange,

bis beim eigentlichen, tatsächlichen Empfänger, also nicht nur auf dem Rechner, sondern beim

Adressaten die Nachricht angekommen ist und schließlich das remote invocation send,

warten wir auch noch darauf, dass eine Antwort zurückgekommen ist. Also diese Abstufungen

gibt es letztendlich und je nachdem, was man erreichen will, kann man eben die eine oder

andere Variante eben dann einsetzen und wir werden das dann auch noch sehen, wie das in der Praxis

dann aussieht. Gut, dann die Fragestellung natürlich mit Fehlern. Wie geht man mit Fehlern um? Es können

die Fehler an unterschiedlichster Stelle passieren, beim Absenden der Nachricht kann der Fehler

passieren, er kann beim Senden der Antwort passieren, es kann auch gar keiner passieren

und der oder eigentlich keiner passieren und der Sender ist nur zu ungeduldig und sein Timeout,

den er sich aufzieht, bis er den Request wiederholt, ist einfach zu kurz gewählt und

dann kommt die Nachricht an und dann eben die Fragestellung einerseits. Wie geht, was identisch

ist zu der Fragestellung, wenn der Reply verloren geht, wie geht der Server damit um, dass der gleiche

Request zweimal gekommen ist und in diesem Fall zusätzlich noch die Frage, wie geht der Client

damit um, dass die Antwort dann zweimal eintrifft. Ich meine, im Endeffekt, es schickt hier die

Wiederholung los und kann eigentlich jetzt nicht so richtig erkennen, ob diese Antwort hier bereits

die auf diesen Request ist oder ob diese Antwort hier quasi die Antwort zum ersten Request ist,

also das kriegt er nicht auseinander, das heißt, er muss im Endeffekt hier, wenn die zweite Antwort

kommt, einfach zu erkennen, das ist eine wiederholte Antwort und die halt irgendwie verwerfen. Während

natürlich auf der Serverseite der Mechanismus komplexer ist, wenn die Nachricht bearbeitet wurde

und die Antwort geschickt wurde, muss letztendlich diese Antwort aufgehoben werden und im Zweifelsfall

eben nochmal wiederholt werden. Gut, ja und dann hatten wir über die verschiedenen Kommunikationsendpunkte