* 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
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 |