Der Unterschied zwischen Fernaufrufen und normalen Aufrufen ist natürlich, dass Fernaufrufe

deutlich fehleranfälliger als konventionelle Prozeduraufrufe sind.

Damit haben wir uns am Ende der letzten Vorlesung beschäftigt.

Der Situation, dass das verteilte System ein ganz anderes Fehlermodell hat.

Die Basis für Mechanismen, um Fehler- Toleranz-Maßnahmen durchführen zu können, sind diese Request-Reply-Protokolle

mit den verschiedenen Möglichkeiten.

Wir können also entweder die Anforderungsnachricht wiederholen, also mit Request-Replay-3 machen,

solange bis eine Antwort eintrifft oder wir davon ausgehen müssen, dass der Anbieter

ausgefallen ist.

Der zweite Mechanismus ist die Filterung von Aufforderungsduplikaten, wenn eine Aufforderung

bereits empfangen wurde und noch in Arbeit ist.

Das dritte wäre die Wiederholung der Antwortnachricht, wenn eine weitere Aufforderung eintrifft,

dass man dann die Antwortnachricht wiederholt oder dass man sie auch regelmäßig wiederholt,

bis die nächste Anforderung oder eine Bestätigung eintrifft.

Daraus kann man verschiedene Aufruf-Semantiken bauen.

Die drei am meisten verwendeten Semantiken sind die May-be-Semantik, die At-least-once-Semantik

und die At-most-once-Semantik.

Die May-be-Semantik ist eine Semantik, die man in der… ich überlege jetzt gerade im

Moment… das habe ich am Ende von der letzten Vorlesung nicht mehr gemacht.

Also irgendwie… okay gut, dann.

Ich habe mich jetzt so daran erinnert, diese Semantiken, die kommen auch irgendwo, die

kommen natürlich auch bei diesen Aufrufen, tauchen letztendlich auch auf.

Das wiederholt sich ja so ein Stückchen zwischen den Remote-Positor-Core-Semantiken und deswegen

war ich mir jetzt ein bisschen unsicher.

Also May-be-Semantik heißt letztendlich, es kann sein, dass der Aufruf ausgeführt

wurde oder vielleicht auch nicht.

Der Aufrufer weiß letztendlich im Fehlerfall eben nicht, ob überhaupt was passiert ist.

Kann man sich natürlich sagen, macht es überhaupt Sinn, diese mit so einer Semantik zu arbeiten,

aber gerade wenn es darum geht, irgendwelche Informationsdienste zu bauen, die regelmäßig

irgendwelche Informationen weiter schicken oder regelmäßig Informationen abfragen,

kann es durchaus Situationen geben, wo es einfach egal ist.

Dann passiert der nächste Aufruf halt in einer halben Minute oder ein paar Sekunden später

und dann geht halt der gut und zwischendrin ist vielleicht auch mal einer verloren gegangen.

Das ist dann egal.

Ist aber natürlich nur in ganz speziellen Anwendungsfällen einsetzbar.

Wesentlich weiterverwendbar ist die At-least-one-Semantik.

Heißt letztendlich, dass mindestens einmal der Aufruf ausgeführt wird, aber eine mehrfache

Ausführung möglich ist.

An dieser Stelle wartet der Client eine gewisse Zeitspanne und wenn nach dieser Zeitspanne

die Antwort nicht eingetreten ist, dann wird einfach der Aufruf wiederholt.

Und die maximale Anzahl der Wiederholungen kann begrenzt sein, muss aber nicht begrenzt

sein.

Man könnte also sagen, nach dieser gewissen Anzahl tritt eine Ausnahmesituation ein,

aber es gibt durchaus Systeme, die an der Stelle letztendlich beliebig oft wiederholen.

Also gerade wenn man jetzt zum Beispiel das Network-File-System ansieht, der Remote Procedure

Call Mechanismus, der dem NFS zugrunde liegt, arbeitet letztendlich mit so einer At-least-one-Semantik

und da ist es typischerweise so, wenn der Server ausfällt, dann wiederholt der Client

halt einfach so lange, bis er eine Antwort bekommt und ansonsten hängt er halt derweil.

Das ist insofern eine ganz angenehme Vorgehensweise, weil man da relativ schön mit Server-Ausfällen

auch klar kommt.