# Alternative algorithm for timeouts

From: Enrique Arizon Benito <enrique.arizon.benito@everis.com>
Date: Fri, 30 Jun 2017 12:07:00 +0000

```At this moment the algorithm to establish a timeout is something like:

1.  start transaction
2.  set timeout as "NOW" + Constant_Timeout_time
3.  wait
4.  "NOW" > timeout
*   YES -> timeout transaction
*   NOW -> Got to 3

This introduces random false timeouts due to race-conditions. It could be possible for the receiving ledger to execute the transfer and for the originating ledger to time out due to the finite time to propagate the fulfillment back through all connectors.

I think next alternative algorithm minimized (nearly avoids) all false timeouts due to race conditions?

- The sending ledger keeps a list of txs not yet executed (that can timeout)  *for each* destination ledger.

Those txs are stored in an ordered list acording to the sending time [tx1, tx2, tx3, tx4, ...]

- When tx"M" with M = N + K arrives, a timeout is established for tx"N" for each "N" < M - K

- Finally after a given timeout,  tx"N" is cancelled

Said it otherway:

-  transaction in the list does NOT time-out unless two next condition happens:

- tx"M" fulfillment with M > N + K has arrived

- tx"N" has timed out.

The logic is next:

- It's possible that at some point there is an overload in the destination ledger. At this point the average time to process the incomming transfer, executing and returning the fulfillment will increase approaching the initial timeout. The closer it is to the timeout the more probable for race condition during the "travel back".

- Due to the destination ledger system overload, is quite possible that all TXs are delayed and it makes sense for the originating ledger to wait more than ussual.
- Suppose now that tx"M" arrives. At this moment sending ledger setup a timeout for each tx"N" with N < M - K.

It's quite sensible to think that if there was a system overload in the destination ledger once it's back to normal all pending transfer will arrive shortly after.

It's also quite sensible to think that if tx"M" arrives, and timeout passes, most probably tx"N" has really timeout (it never reached the destinantion ledger) and that no race condition will arise since they never reached the destination ledger.

Regards,

Enrique

________________________________