ligo/src/lib_shell/bootstrap_pipeline.mli

(**************************************************************************)
(*                                                                        *)
(*    Copyright (c) 2014 - 2018.                                          *)
(*    Dynamic Ledger Solutions, Inc. <contact@tezos.com>                  *)
(*                                                                        *)
(*    All rights reserved. No warranty, explicit or implicit, provided.   *)
(*                                                                        *)
(**************************************************************************)

type t

val create:
  ?notify_new_block: (State.Block.t -> unit) ->
  block_header_timeout:float ->
  block_operations_timeout: float ->
  Block_validator.t ->
  P2p_peer.Id.t -> Distributed_db.chain_db ->
  Block_locator.t -> t

val wait: t -> unit tzresult Lwt.t

val cancel: t -> unit Lwt.t
Shell: use one 'validation worker' per peer. The single validation module is split in multiple (simpler) modules. In the process, we introduce one "validation worker" per peer. This worker handle all the `New_head` and `New_branch` advertised by a given peer. For so, it sends "fetching request" and "validation request" to respectively the `Distributed_db` and and the `Block_validator`. These two global workers are responsible of the 'fair' allocation of network and CPU ressources amongst the connected 'peers'. 2017-11-11 06:34:12 +04:00			`(**************************************************************************)`
			`(* *)`
Update copyright notice (2018) 2018-02-06 00:17:03 +04:00			`(* Copyright (c) 2014 - 2018. *)`
Shell: use one 'validation worker' per peer. The single validation module is split in multiple (simpler) modules. In the process, we introduce one "validation worker" per peer. This worker handle all the `New_head` and `New_branch` advertised by a given peer. For so, it sends "fetching request" and "validation request" to respectively the `Distributed_db` and and the `Block_validator`. These two global workers are responsible of the 'fair' allocation of network and CPU ressources amongst the connected 'peers'. 2017-11-11 06:34:12 +04:00			`(* Dynamic Ledger Solutions, Inc. <contact@tezos.com> *)`
			`(* *)`
			`(* All rights reserved. No warranty, explicit or implicit, provided. *)`
			`(* *)`
			`(**************************************************************************)`

			`type t`

			`val create:`
			`?notify_new_block: (State.Block.t -> unit) ->`
Shell: add configuration variable for various timeouts. 2017-11-13 17:25:02 +04:00			`block_header_timeout:float ->`
			`block_operations_timeout: float ->`
Shell: use one 'validation worker' per peer. The single validation module is split in multiple (simpler) modules. In the process, we introduce one "validation worker" per peer. This worker handle all the `New_head` and `New_branch` advertised by a given peer. For so, it sends "fetching request" and "validation request" to respectively the `Distributed_db` and and the `Block_validator`. These two global workers are responsible of the 'fair' allocation of network and CPU ressources amongst the connected 'peers'. 2017-11-11 06:34:12 +04:00			`Block_validator.t ->`
Shell: Rename `net_id` into `chain_id` 2018-02-16 04:26:24 +04:00			`P2p_peer.Id.t -> Distributed_db.chain_db ->`
Shell: use one 'validation worker' per peer. The single validation module is split in multiple (simpler) modules. In the process, we introduce one "validation worker" per peer. This worker handle all the `New_head` and `New_branch` advertised by a given peer. For so, it sends "fetching request" and "validation request" to respectively the `Distributed_db` and and the `Block_validator`. These two global workers are responsible of the 'fair' allocation of network and CPU ressources amongst the connected 'peers'. 2017-11-11 06:34:12 +04:00			`Block_locator.t -> t`

			`val wait: t -> unit tzresult Lwt.t`

			`val cancel: t -> unit Lwt.t`