- From: David Fuelling <dfuelling@sappenin.com>
- Date: Wed, 19 Jul 2017 01:42:50 +0000
- To: Enrique Arizon Benito <enrique.arizon.benito@everis.com>, "public-interledger@w3.org" <public-interledger@w3.org>
- Message-ID: <CABq1t67BCPRWY0ZTYHNwJd7A6sPii6kcbuUDVmwUqd4Xz=u2og@mail.gmail.com>
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