« Should Syslog use application acks? | Main | Actual failure experience (re ATNA-Syslog) »



So, when the client 'decides' that something bad happened, then it should abortively-reset the TCP connection. If the network is still intact, this will notify the service. If it is not intact, no harm done; but also anything that is queued can be freed quickly.

Then as you indicate, just send whatever you think didn't make it, which might be everything.

Rainer Gerhards

In rsyslog, I "solved" the problem by a dedicted protocol named RELP, but it really "solves" only extreme cases, just as you describe. Of course, even with app-level acks, you never know if just the ACK was lost or the message itself. RELP tries to circumvent this by keeping state on both sender and receiver and doing a check for outstanding transactions when a connection is re-established. However, this state may grow and so there may come some time when it is necessary (or at least very useful) to discard some of that state. In any case, it is a very exotic problem, and I doubt it is really a problem that must be solved under all circumstances. Idempotent messages are actually much better at solving this problem (if a solution is actually needed for the use case).

The comments to this entry are closed.