What are they?
Error semantics
A Remote procedure call or RPC is generally on UDP. Therefore it is a connectionless communication. This has the advantage that no traffic overhead is generated by Ack packets. However, the UDP packet size is not sufficient for large responses. Therefore, two kinds of RPC protocols must be used: request-reply and request-reply-ACK. This is to be noted since each of these 2 protocols have different sources of error and thus a different error handling is necessary. In the event of an error, no results, exactly one result or many results can be received depending on the implementation. For this purpose, the following “error semantics” are selected on the client side: maybe , at-least-once , exactly-once and at-most-once .
If errors occur, the following can happen, depending on the specified error tolerance:
(If no errors occur, all semantics guarantee the unique execution of the procedure.)
| Type | A request will be … | Filtering received duplicates | |
|---|---|---|---|
| Maybe | … not sent again. | no treatment | |
| At-least-once | … sent once again. | No | The remote procedure is executed repeatedly at a receiving duplicate (recommended only for idempotent operations). |
| At-most-once | … sent once again. | Yes | Duplicates are filtered, either complete execution of the job, or error message. |
| Exactly-once | … sent once again. | Yes | Duplicates are also filtered. Furthermore, the execution of the job beyond the restart is ensured even in the event of a system failure. However, in some books it is stated that exactly-once is not possible with distributed systems. |
In general however: no guarantee can be given. If, for example, a network node fails permanently, no single execution is possible in any case.
Context
Sometimes, message duplicity can be coped with by the application using a Message-oriented Middleware. Therefore, for scenarios where message duplicates are uncritical, it shall still be ensured that messages are received.
At-least-once Delivery
In case of failures that lead to message loss or take too long to recover from, messages are retransmitted to assure they are delivered at least once.
How can communication partners or a Message-oriented Middleware ensure that messages are received successfully?
Solution
For each message retrieved by a receiver an acknowledgement is sent back to the message sender. In case this acknowledgement is not received after a certain time frame, the message is resent.
Situation
At-most-once Delivery
In the case of failures a request is sent again in case of failure, but request is filtered on the server for duplicates.
Solution
For each message retrieved by a receiver an acknowledgement is sent back to the message sender. In case this acknowledgement is not received after a certain time frame, the message is resend.
Situation
Exactly-once Delivery
In case of failures that lead to message loss or take too long to recover from, messages are retransmitted to assure they are delivered at least once.
How can communication partners or a Message-oriented Middleware ensure that messages are received successfully?
Solution
For each message retrieved by a receiver an acknowledgement is sent back to the message sender. In case this acknowledgement is not received after a certain time frame, the message is resend.
Situation