51 lines
3.7 KiB
Plaintext
51 lines
3.7 KiB
Plaintext
|
@node cic-eth-services
|
|||
|
|
@section Services
|
|||
|
|
|
|||
|
|
There are four daemons that together orchestrate all of the aforementioned recipes. This section will provide a high level description of them.
|
|||
|
|
|
|||
|
|
Each of them have their own set of command line flags. These are available in the CLI help text provided by @kbd{-h} @kbd{--help} and are not recited here.
|
|||
|
|
|
|||
|
|
Daemon executable scripts are located in the @file{cic_eth.runnable.daemons} package. If @var{cic-eth} is installed as a python package, they are installed as executables in @var{PATH}.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@subsection tasker
|
|||
|
|
|
|||
|
|
This is the heart of the custodial system. Tasker is the parent process for the celery workers executing all tasks interacting with and changing the state of the queue and the chain. It is also the only service that interfaces with the signer/keystore.
|
|||
|
|
|
|||
|
|
The other @var{cic-eth} daemons all interface with this component, along with any client adapter bridging an end-user gateway (e.g. @var{cic-ussd}). However, the service itself does not have to be actively running for the other services to run; @var{Celery} handles queueing up the incoming tasks until the @var{tasker} comes back online.@footnote{Whereas this is true, there is currently no fail-safe implemented to handles the event of task backlog overflow in Celery. Furthermore, no targeted testing has yet been performed to asses the stability of the system over time if a sudden, sustained surge of resumed task executions occurs. It may be advisable to suspend activity that adds new queue items to the system if volume is high and/or the @var{cic-eth} outage endures. However, there is no panacea for this condition, as every usage scenario is different}
|
|||
|
|
|
|||
|
|
The tasker has a set of pre-requisites that must be fulfilled before it will start
|
|||
|
|
|
|||
|
|
@itemize
|
|||
|
|
@item It must be given a valid @var{ContractRegistry} address, which must include valid references to all contracts specified in @ref{cic-eth-dependencies-smart-contracts,Smart contract dependencies}
|
|||
|
|
@item The gas gifter balance must be above the minimum threshold (See "eth" section in configurations).
|
|||
|
|
@item There must be a valid alembic migration record in the storage database
|
|||
|
|
@item The redis backend must be reachable and writable
|
|||
|
|
@item There must be a reachable JSON-RPC server at the other end of the signer socket path (see "signer" section in configurations)
|
|||
|
|
@end itemize
|
|||
|
|
|
|||
|
|
|
|||
|
|
@subsection tracker
|
|||
|
|
|
|||
|
|
Implements the @var{chainsyncer}, and registers the filters described in @ref{cic-eth-incoming,Incoming Transactions} to be executed for every transaction. It consumes the appropriate @var{TASKS_TRANSFER_CALLBACKS} configuration setting to add externally defined filters at without having to change the daemon code.
|
|||
|
|
|
|||
|
|
The @var{tracker} has the same requisities for the @var{ContractRegistry} as the @var{tasker}.
|
|||
|
|
|
|||
|
|
@strong{Important! Guarantees of filter executions has some caveats. Refer to the @var{chainsyncer} documentation for more details.}
|
|||
|
|
|
|||
|
|
|
|||
|
|
@anchor{cic-eth-services-dispatcher}
|
|||
|
|
@subsection dispatcher
|
|||
|
|
|
|||
|
|
Uses the @code{get_upcoming_tx} method call from @var{chainqueue} to receive batches of queued transactions that are ready to send to the blockchain node. Every batch will only contain a single transaction by any one address, which will be the transaction with the next nonce not previously seen by the network. There is no limit currently set to how many transactions that will be included in a single batch.
|
|||
|
|
|
|||
|
|
|
|||
|
|
@subsection retrier
|
|||
|
|
|
|||
|
|
The responsibility of the @var{retrier} is to re-queue transactions that failed to be sent to the blockchain node, as well as create @emph{replacements} for transactions whose processing by the network has been delayed. @strong{[refer transaction obolestion]}.
|
|||
|
|
|
|||
|
|
It is in turn the responsiblity of the @var{dispatcher} to send these (re-)queued transactions to the blockchain node.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|