backend.texi (1631B)
1 @node chainsyncer-backend 2 @section Backend implementations 3 4 While syncing the chain, we need to keep track of where we are in the syncing process. The syncer backend is the pluggable component that records this state. 5 6 The state consists of three parts, in hierarchical order: 7 8 @enumerate 9 @item Block height 10 @item Transaction index in block 11 @item Individual code filters to execute per transaction 12 @end enumerate 13 14 @subsection Syncer types 15 16 By default there are two types of syncers. 17 18 There is the @emph{live syncer} which continues to consume new blocks as they are available. 19 20 There is also the @emph{history syncer} which syncs blocks between two specific points. 21 22 A typical first-time syncer invocation defines a starting block height from which to retrieve blocks, in which case two syncers will be created; 23 24 @itemize 25 @item A history syncer syncing from the start height until the height at the time of the invocation. 26 @item A live syncer syncing from the height at the time of the invocation, indefinitely retrieveing new blocks. 27 @end itemize 28 29 A typical resumed syncer invocation will involve additional syncers, depending on the state that was left off: 30 31 @itemize 32 @item History syncers for each previously incomplete history syncer run. 33 @item A new history syncer resuming where the last live syncer left off, until the height at the time of invocation of the resume. 34 @item A new live syncer syncing from the height at the time of the invocation, indefinitely retrieving new blocks. 35 @end itemize 36 37 In short, the consequence for the above is that one additional syncer will be spawned every time a syncer session is resumed.