package tezos-dal-node-lib

  1. Overview
  2. Docs
Legend:
Library
Module
Module type
Parameter
Class
Class type

The transport layer module exposes the needed primitives, interface and default parameters for the instantiation of the Octez-p2p library.

module Interface : module type of Transport_layer_interface
type t
val create : network_name:string -> public_addr:Tezos_base.TzPervasives.P2p_point.Id.t -> is_bootstrap_peer:bool -> Tezos_p2p.P2p.config -> Tezos_p2p_services.P2p_limits.t -> t Tezos_base.TzPervasives.tzresult Lwt.t

create ~network_name ~is_bootstrap_peer ~public_addr config limits creates a new instance of type t. It is a wrapper on top of P2p.create.

val activate : ?additional_points:Tezos_base.TzPervasives.P2p_point.Id.t list -> t -> unit Lwt.t

activate ?additional_points t activates the given transport layer t. It is a wrapper on top of P2p.activate. If some additional_points are given, they are added to t's known points.

connect t ?timeout point initiates a connection to the point point. The promise returned by this function is resolved once the P2P handhshake successfully completes. If the timeout is set, an error is returned if the P2P handshake takes more than timeout to complete.

val disconnect_point : t -> ?wait:bool -> Tezos_base.TzPervasives.P2p_point.Id.t -> unit Lwt.t

disconnect_point t ?wait point initiaties a disconnection to the point point. The promise returned by this function is fullfiled when the socket is closed on our side. If wait is true, we do not close the socket before having canceled all the current messages in the write buffer. Should not matter in practice.

Due to the following issue https://gitlab.com/tezos/tezos/-/issues/5319

it may occur that a discconnection takes several minutes.

val disconnect_peer : t -> ?wait:bool -> Tezos_crypto.Crypto_box.Public_key_hash.t -> unit Lwt.t

disconnect_peer t ?wait point initiaties a disconnection to the point peer. The promise returned by this function is fullfiled when the socket is closed on our side. If wait is true, we do not close the socket before having canceled all the current messages in the write buffer. Should not matter in practice.

Due to the following issue https://gitlab.com/tezos/tezos/-/issues/5319

it may occur that a discconnection takes several minutes.

get_points ?connected t returns a list of points. If connected is true (default), it returns only points we are currently connected. Otherwise, it returns a list of known points (points for which we were already successfully connected in the past.)

get_points_info ?connected t returns a list of info for points. If connected is true (default), it returns only info for points we are currently connected. Otherwise, it returns a list of infos for known points (points for which we were already successfully connected in the past.)

get_point_info t point returns the info of the corresponding point if found.

get_peers ?connected t returns a list of peers. If connected is true (default), it returns only the peers we are connected to. Otherwise, it returns a list of known peers (peers for which we were already successfully connected in the past.)

get_peers_info ?connected t returns a list of info for peers. If connected is true (default), it returns only info for peers we are currently connected. Otherwise, it returns a list of infos for known peers (peers for which we were already successfully connected in the past.)

get_peer_info t peer returns the info of the corresponding peer if found.