Files
rippled/src
Edward Hennis 2c71802e38 Propagate validator lists (VLs or UNLs) over the peer network:
* Whenever a node downloads a new VL, send it to all peers that
  haven't already sent or received it. It also saves it to the
  database_dir as a Json text file named "cache." plus the public key of
  the list signer. Any files that exist for public keys provided in
  [validator_list_keys] will be loaded and processed if any download
  from [validator_list_sites] fails or no [validator_list_sites] are
  configured.
* Whenever a node receives a broadcast VL message, it treats it as if
  it had downloaded it on it's own, broadcasting to other peers as
  described above.
* Because nodes normally download the VL once every 5 minutes, a single
  node downloading a VL with an updated sequence number could
  potentially propagate across a large part of a well-connected network
  before any other nodes attempt to download, decreasing the amount of
  time that different parts of the network are using different VLs.
* Send all of our current valid VLs to new peers on connection.
  This is probably the "noisiest" part of this change, but will give
  poorly connected or poorly networked nodes the best chance of syncing
  quickly. Nodes which have no http(s) access configured or available
  can get a VL with no extra effort.
* Requests on the peer port to the /vl/<pubkey> endpoint will return
  that VL in the same JSON format as is used to download now, IF the
  node trusts and has a valid instance of that VL.
* Upgrade protocol version to 2.1. VLs will only be sent to 2.1 and
  higher nodes.
* Resolves #2953
2020-02-12 10:19:23 -08:00
..
2019-03-18 16:19:24 -07:00

rippled Source

Some of these directories come from entire outside repositories brought in using [git-subtree][]. This means that the source files are inserted directly into the rippled repository. They can be edited and committed just as if they were normal files. [git-subtree]: https://github.com/apenwarr/git-subtree

If you create a commit that contains files both from a subtree, and from the rippled source tree, please use care when designing the commit message, since it will appear in the subtree's individual repository when the changes are pushed back to the upstream. Better yet, do not mix files from subtrees and ripple in the same commit at all.

Source folders:

Folder Upstream Repo Description
beast N/A legacy utility code that was formerly associated with boost::beast
ed25519-donna https://github.com/floodyberry/ed25519-donna Ed25519 digital signatures
ripple N/A Core source code for rippled
secp256k1 https://github.com/bitcoin-core/secp256k1 ECDSA digital signatures using the secp256k1 curve
test N/A Unit tests for rippled

The following dependencies are downloaded and built using ExternalProject (or FetchContent, where possible). Refer to CMakeLists.txt file for details about how these sources are built :

Name Upstream Repo Description
lz4 https://github.com/lz4/lz4 LZ4 lossless compression algorithm
nudb https://github.com/vinniefalco/NuDB Constant-time insert-only key/value database for SSD drives (Less memory usage than RocksDB.)
snappy https://github.com/google/snappy "Snappy" lossless compression algorithm.
soci https://github.com/SOCI/soci Abstraction layer for database access.
sqlite https://www.sqlite.org/src An embedded database engine that writes to simple files.
rocksdb https://github.com/facebook/rocksdb Fast key/value database. (Supports rotational disks better than NuDB.)
protobuf https://github.com/google/protobuf Protocol buffer data interchange format. Only downloaded/built if a suitable version is not found by find_package, or if the local_protobuf option is explicitly set