W3C home > Mailing lists > Public > public-interledger@w3.org > July 2017

Re: Alternative algorithm for timeouts

From: David Fuelling <dfuelling@sappenin.com>
Date: Wed, 19 Jul 2017 01:42:50 +0000
Message-ID: <CABq1t67BCPRWY0ZTYHNwJd7A6sPii6kcbuUDVmwUqd4Xz=u2og@mail.gmail.com>
To: Enrique Arizon Benito <enrique.arizon.benito@everis.com>, "public-interledger@w3.org" <public-interledger@w3.org>
Hey Enrique, can you clarify the meaning of M, N, and K?

Thanks!
David
On Fri, Jun 30, 2017 at 6:08 AM Enrique Arizon Benito <
enrique.arizon.benito@everis.com> wrote:

> 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
>    1. YES -> timeout transaction
>       2. 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
>
>
> ------------------------------
>
> AVISO DE CONFIDENCIALIDAD.
> Este correo y la información contenida o adjunta al mismo es privada y
> confidencial y va dirigida exclusivamente a su destinatario. everis informa
> a quien pueda haber recibido este correo por error que contiene información
> confidencial cuyo uso, copia, reproducción o distribución está expresamente
> prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por
> error, le rogamos lo ponga en conocimiento del emisor y proceda a su
> eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.
>
> CONFIDENTIALITY WARNING.
> This message and the information contained in or attached to it are
> private and confidential and intended exclusively for the addressee. everis
> informs to whom it may receive it in error that it contains privileged
> information and its use, copy, reproduction or distribution is prohibited.
> If you are not an intended recipient of this E-mail, please notify the
> sender, delete it and do not read, act upon, print, disclose, copy, retain
> or redistribute any portion of this E-mail.
>
Received on Wednesday, 19 July 2017 01:43:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 19 July 2017 01:43:31 UTC