a-processes.tex (2539B)
1 \subsection{Processes} 2 \label{sec-implementation-processes} 3 4 This section describes the different processes running in the background transitioning the state of a withdrawal. These transitions are triggered because of requests received by one of the components through the respective API. 5 6 \subsubsection{Confirmation} 7 \label{sec-implementation-processes-confirmation} 8 9 The confirmation of a transaction is crucial, since this is the action which allows the exchange to create a reserve and can proof to the provider and customer, that the transaction was successful and therefore can put the liability for the money on the provider. The confirmation process is implemented using a provider client interface and a provider transaction interface. This allows the process to be the same for each individual provider and new providers can be added by providing a specific implementation of the interfaces. 10 11 \subsubsection{Confirmation Retrier} 12 13 If the confirmation fails, but the transaction is not in the refund state as specified by the provider's transaction, the problem could simply be that the service was not available or the transaction was not yet processed by the provider's backend. In order to not need to abort the transaction directly and give the system some robustness a retry mechanism was implemented. It allows retrying the confirmation step. This retry mechanism is run in a separate process started through the main process. 14 15 The retry will only be executed, when the transaction confirmation failed because the transaction was not in the abort state or if for some reason the transaction information could not have been retrieved. 16 17 \subsubsection{Transfer Retrier} 18 19 The Exchange may send a transfer request to the C2EC component, due to the closing of a reserve or an issue. This will trigger a refund process at the providers backend. This refund process may fail and therefore like in the confirmation case to increase the robustness of the system, a retry mechanism is implemented, which will retry the transfer before ultimatively failing the transfer. 20 21 \textbf{Randomizing delays due to potential self synchronization issues} 22 23 All processes doing retries use a randomized exponential backoff algorithm for scheduling the retries. The randomization prevents that the retry processes are all triggered at the exact same time and could crash the server due to heavy load. For the implementation a hard coded threshold of 20 percent of the targeted delay was chosen. The value can be adjusted by changing the constant.