At lease once - Semantik

[daniel-schreiber]

Wie kann 'at lease once' sichergestellt werden, wenn der Server bei/vor Ausführung des Requests crasht bzw. alle Requests verloren gehen?
(dies ist ja die Begründung, dass bei 'at-most-once' es passieren kann, dass der Request/die Berechnung nicht ausgeführt wird)

[yourmaninamsterdam]

Nur mal ne Anmerkung: Das soll doch mit aller Sicherheit "at-least-once" heißen, oder?

[Christoph-D]

Ein Proxy vor dem Server könnte z.B. beim Empfangen einer Nachricht diese irgendwo speichern und erst dann löschen, wenn vom Server das passende "ich bin fertig mit der Berechnung" kommt. Wenn dann der Server crasht, schickt der Proxy alle gespeicherten Nachrichten nochmal zum Server. Manchmal ist aber nur eine "ich bin fertig"-Meldung beim Proxy nicht angekommen, der Server bearbeitet also eine bestimmte Nachricht möglicherweise mehrmals.

Das deckt bestimmmt nicht alle Fehlerfälle ab (z.B. "Proxy crasht" fehlt), aber meistens wird so ein System eine Nachricht "at least once" ausführen, denk ich.

Schwieriger finde ich da schon die "at most once"-Semantik zu implementieren, denn dafür braucht man dann Transactions und Roll-Backs oder ähnliches, wenn ich nicht gerade eine ganz einfache Möglichkeit übersehe.
Edit: Ok, ich hab wohl das einfachste von allem übersehen: Den Servercrash ignorieren und beim Server-Neustart alle alten Aufträge komplett wegschmeißen, falls noch Reste vorhanden sind. Ein Problem ist dann vielleicht, das ein Auftrag halbfertig sein könnte, und erst um *das* zu vermeiden braucht man sowas was ich oben genannt hatte.

btw, ich nehme an, dass das ein Tippfehler in den Folien ist und es eigentlich "at least once" heißen sollte, hat ja nichts mit leasing zu tun.

[Edoat]

Nur mal ne Anmerkung: Das soll doch mit aller Sicherheit "at-least-once" heißen, oder?

Denke ich auch, steht im Foliensatz 7 auf S.23 falsch und auf S.24 richtig.

Ein Proxy vor dem Server könnte z.B. beim Empfangen einer Nachricht diese irgendwo speichern und erst dann löschen, wenn vom Server das passende "ich bin fertig mit der Berechnung" kommt.

Ich hätte jetzt eher vermutet, dass der Client einen Timeout setzt und wenn er dann kein Ergebnis hat, einfach noch mal einen Request schickt und sich das wiederholt, bis der Server geantwortet hat.

[Christoph-D]

Ein Proxy vor dem Server könnte z.B. beim Empfangen einer Nachricht diese irgendwo speichern und erst dann löschen, wenn vom Server das passende "ich bin fertig mit der Berechnung" kommt.

Ich hätte jetzt eher vermutet, dass der Client einen Timeout setzt und wenn er dann kein Ergebnis hat, einfach noch mal einen Request schickt und sich das wiederholt, bis der Server geantwortet hat.

Stimmt, das ist auch viel einfacher und zuverlässiger zu implementieren als meine Idee.

[daniel-schreiber]

Danke erstmal für die Antworten.

Aber meine eigentliche Frage wurde nicht wirklich beantwortet.
Das Problem ist, dass ich bei 'at-least-once' nicht sicherstellen kann, da z.B. ALLE (auch zukünftige) Anfragen auf dem Weg verloren gehen können!

[Daraus folgt auch eine weitere Frage. Wenn man 'at-least-once' und 'at-most-once' wirklich realisieren könnte, dann könnte man auch 'exactly-once' realisieren, oder schließen die beiden Ansätze sich gegenseitig aus? Wenn ja aus welchem grund?]

[Christoph B]

du willst sicherstellen können das alle Anfragen auf dem Weg verloren gehn können?

naja, wenn du annimmst das at-least-once nicht sicherstellen kann, das jemals ne Anfrage / ne Antwort ankommt, dann musst du da schon zugrunde legen das der Server auf der Mülldeponie gelandet, das Netzwerk für alle zeiten abgeschaltet ist oder sonstwas, und dann ist das Modell ja eh hinfällig.

Ansonsten stimmen die Semantiken so und sollen ja nur Fehler des Systems regeln, und nicht den Fall das das System garnich so existiert.

[Edoat]

Aber meine eigentliche Frage wurde nicht wirklich beantwortet.

Dann versuche doch mal, deine Frage deutlicher zu formulieren.

Ich habe das "at-least-once" so verstanden, dass man so lange Requests sendet, bis es klappt (deshalb "infinite retries" auf S. 23 bei den Distributed Programming Folien).