From c0642023638a70d034109cbe636fb7fde675e3d2 Mon Sep 17 00:00:00 2001 From: bthomee Date: Fri, 25 Jul 2025 15:58:19 +0000 Subject: [PATCH] deploy: 921aef9934fba3a947fe3d6d38de756abd3a6adc --- Application_8cpp_source.html | 6 +- Application_8h_source.html | 2 +- CaptureLogs_8h_source.html | 4 +- CheckMessageLogs_8h_source.html | 4 +- Config_8cpp_source.html | 2 +- Config__test_8cpp_source.html | 20 +- DatabaseCon_8cpp_source.html | 2 +- DatabaseCon_8h_source.html | 2 +- Env_8h_source.html | 2 +- FileDirGuard_8h_source.html | 331 ++-- FileUtilities_8cpp_source.html | 158 +- FileUtilities_8h_source.html | 4 +- FileUtilities__test_8cpp_source.html | 8 +- JobQueue_8cpp_source.html | 2 +- JobQueue_8h_source.html | 2 +- JobTypeData_8h_source.html | 2 +- LogLevel_8cpp_source.html | 4 +- Log_8cpp_source.html | 32 +- Log_8h_source.html | 466 +++--- Main_8cpp_source.html | 4 +- RPCCall_8cpp_source.html | 2 +- RPCSub_8cpp_source.html | 2 +- RPCSub_8h_source.html | 2 +- RippleCalc_8cpp_source.html | 2 +- RippleCalc_8h_source.html | 2 +- ServerStatus__test_8cpp_source.html | 2 +- SociDB_8cpp_source.html | 2 +- SociDB_8h_source.html | 2 +- TrustedPublisherServer_8h_source.html | 1423 ++++++++--------- ValidatorList_8cpp_source.html | 2 +- ValidatorRPC__test_8cpp_source.html | 6 +- ValidatorSite__test_8cpp_source.html | 12 +- WorkFile_8h_source.html | 2 +- classripple_1_1Logs.html | 16 +- classripple_1_1Logs_1_1File.html | 10 +- classripple_1_1Logs_1_1Sink.html | 6 +- classripple_1_1ValidatorList.html | 2 +- classripple_1_1ValidatorSite.html | 2 +- classripple_1_1detail_1_1RippledCfgGuard.html | 20 +- ...ipple_1_1detail_1_1ValidatorsTxtGuard.html | 20 +- classripple_1_1test_1_1CaptureLogs.html | 14 +- classripple_1_1test_1_1CheckMessageLogs.html | 14 +- ...ple_1_1test_1_1TrustedPublisherServer.html | 62 +- ...sripple_1_1test_1_1detail_1_1DirGuard.html | 18 +- ...ple_1_1test_1_1detail_1_1FileDirGuard.html | 26 +- classripple_1_1test_1_1jtx_1_1SuiteLogs.html | 14 +- compression__test_8cpp_source.html | 2 +- index.html | 18 +- md____w_rippled_rippled_BUILD.html | 25 +- ...ed_rippled_Builds_levelization_README.html | 2 +- md____w_rippled_rippled_CONTRIBUTING.html | 122 +- md____w_rippled_rippled_SECURITY.html | 16 +- ...rippled_docs_0001_negative_unl_README.html | 54 +- ...ippled_docs_0010_ledger_replay_README.html | 4 +- md____w_rippled_rippled_docs_CheatSheet.html | 4 +- md____w_rippled_rippled_docs_CodingStyle.html | 6 +- ..._w_rippled_rippled_docs_HeapProfiling.html | 4 +- md____w_rippled_rippled_docs_README.html | 6 +- md____w_rippled_rippled_docs_build_conan.html | 4 +- ...__w_rippled_rippled_docs_build_depend.html | 4 +- ...ippled_rippled_docs_build_environment.html | 4 +- ..._w_rippled_rippled_docs_build_install.html | 6 +- md____w_rippled_rippled_docs_consensus.html | 42 +- ...ed_rippled_include_xrpl_basics_README.html | 2 +- ...ude_xrpl_proto_org_xrpl_rpc_v1_README.html | 14 +- ..._rippled_include_xrpl_protocol_README.html | 6 +- ..._rippled_include_xrpl_resource_README.html | 10 +- md_test_README.html | 2 +- md_test_csf_README.html | 14 +- md_xrpld_app_ledger_README.html | 64 +- md_xrpld_app_misc_FeeEscalation.html | 22 +- md_xrpld_app_misc_README.html | 8 +- md_xrpld_app_rdb_README.html | 12 +- md_xrpld_nodestore_README.html | 12 +- md_xrpld_overlay_README.html | 36 +- md_xrpld_peerfinder_README.html | 42 +- md_xrpld_rpc_README.html | 6 +- md_xrpld_shamap_README.html | 32 +- namespaceripple.html | 6 +- namespaceripple_1_1test.html | 2 +- overlay_2Slot_8h_source.html | 2 +- reduce__relay__test_8cpp_source.html | 2 +- ...1_1TrustedPublisherServer_1_1BlobInfo.html | 8 +- ..._1TrustedPublisherServer_1_1Validator.html | 8 +- ...t_1_1TrustedPublisherServer_1_1lambda.html | 16 +- 85 files changed, 1690 insertions(+), 1701 deletions(-) diff --git a/Application_8cpp_source.html b/Application_8cpp_source.html index d763fe3d85..fa53ef3f05 100644 --- a/Application_8cpp_source.html +++ b/Application_8cpp_source.html @@ -157,7 +157,7 @@ $(function() {
79#include <chrono>
80#include <condition_variable>
81#include <cstring>
-
82#include <iostream>
+
82#include <fstream>
83#include <limits>
84#include <mutex>
85#include <optional>
@@ -2481,7 +2481,7 @@ $(function() {
ripple::LedgerReplayer
Manages the lifetime of ledger replay tasks.
Definition: LedgerReplayer.h:73
ripple::LoadFeeTrack
Manages the current fee schedule.
Definition: LoadFeeTrack.h:45
ripple::LoadManager
Manages load sources.
Definition: LoadManager.h:46
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::ManifestCache
Remembers manifests with the highest sequence number.
Definition: Manifest.h:256
ripple::NetworkOPs
Provides server functionality for clients.
Definition: NetworkOPs.h:89
ripple::NodeFamily
Definition: NodeFamily.h:31
@@ -2532,11 +2532,11 @@ $(function() {
std::string::empty
T empty(T... args)
std::endl
T endl(T... args)
std::exception
+
fstream
std::reference_wrapper::get
T get(T... args)
std::thread::hardware_concurrency
T hardware_concurrency(T... args)
std::hash
std::uint64_t
-
iostream
limits
std::atomic::load
T load(T... args)
std::max
T max(T... args)
diff --git a/Application_8h_source.html b/Application_8h_source.html index 129136f271..3050483f11 100644 --- a/Application_8h_source.html +++ b/Application_8h_source.html @@ -443,7 +443,7 @@ $(function() {
ripple::Ledger
Holds a ledger.
Definition: Ledger.h:80
ripple::LoadFeeTrack
Manages the current fee schedule.
Definition: LoadFeeTrack.h:45
ripple::LoadManager
Manages load sources.
Definition: LoadManager.h:46
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::ManifestCache
Remembers manifests with the highest sequence number.
Definition: Manifest.h:256
ripple::NetworkOPs
Provides server functionality for clients.
Definition: NetworkOPs.h:89
ripple::NodeStore::Database
Persistency layer for NodeObject.
Definition: Database.h:52
diff --git a/CaptureLogs_8h_source.html b/CaptureLogs_8h_source.html index a9e60977c5..c1db5bd37e 100644 --- a/CaptureLogs_8h_source.html +++ b/CaptureLogs_8h_source.html @@ -170,8 +170,8 @@ $(function() {
std::stringstream
beast::Journal::Sink
Abstraction for the underlying message destination.
Definition: Journal.h:76
beast::Journal::Sink::threshold
virtual Severity threshold() const
Returns the minimum severity level this sink will report.
Definition: beast_Journal.cpp:116
-
ripple::Logs::Sink
Definition: Log.h:54
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs::Sink
Definition: Log.h:55
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::Logs::threshold
beast::severities::Severity threshold() const
Definition: Log.cpp:166
ripple::test::CaptureLogs::CaptureSink
sink for writing all log messages to a stringstream
Definition: CaptureLogs.h:44
ripple::test::CaptureLogs::CaptureSink::strmMutex_
std::mutex & strmMutex_
Definition: CaptureLogs.h:45
diff --git a/CheckMessageLogs_8h_source.html b/CheckMessageLogs_8h_source.html index c28593f688..92b71ae61f 100644 --- a/CheckMessageLogs_8h_source.html +++ b/CheckMessageLogs_8h_source.html @@ -158,8 +158,8 @@ $(function() {
std::string
beast::Journal::Sink
Abstraction for the underlying message destination.
Definition: Journal.h:76
beast::Journal::Sink::threshold
virtual Severity threshold() const
Returns the minimum severity level this sink will report.
Definition: beast_Journal.cpp:116
-
ripple::Logs::Sink
Definition: Log.h:54
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs::Sink
Definition: Log.h:55
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::Logs::threshold
beast::severities::Severity threshold() const
Definition: Log.cpp:166
ripple::test::CheckMessageLogs::CheckMessageSink
Definition: CheckMessageLogs.h:36
ripple::test::CheckMessageLogs::CheckMessageSink::CheckMessageSink
CheckMessageSink(beast::severities::Severity threshold, CheckMessageLogs &owner)
Definition: CheckMessageLogs.h:40
diff --git a/Config_8cpp_source.html b/Config_8cpp_source.html index 41fb4fff05..8f5ea03fe5 100644 --- a/Config_8cpp_source.html +++ b/Config_8cpp_source.html @@ -1341,7 +1341,7 @@ $(function() {
ripple::getEnvVar
static std::string getEnvVar(char const *name)
Definition: Config.cpp:252
ripple::getRegisteredFeature
std::optional< uint256 > getRegisteredFeature(std::string const &name)
Definition: Feature.cpp:382
ripple::AttestationMatch::match
@ match
-
ripple::getFileContents
std::string getFileContents(boost::system::error_code &ec, boost::filesystem::path const &sourcePath, std::optional< std::size_t > maxSize=std::nullopt)
Definition: FileUtilities.cpp:39
+
ripple::getFileContents
std::string getFileContents(boost::system::error_code &ec, boost::filesystem::path const &sourcePath, std::optional< std::size_t > maxSize=std::nullopt)
Definition: FileUtilities.cpp:40
ripple::setup_FeeVote
FeeSetup setup_FeeVote(Section const &section)
Definition: Config.cpp:1128
ripple::isProperlyFormedTomlDomain
bool isProperlyFormedTomlDomain(std::string_view domain)
Determines if the given string looks like a TOML-file hosting domain.
Definition: StringUtilities.cpp:132
ripple::IniFileSections
std::unordered_map< std::string, std::vector< std::string > > IniFileSections
Definition: BasicConfig.h:37
diff --git a/Config__test_8cpp_source.html b/Config__test_8cpp_source.html index 742cb7745f..f347e7f088 100644 --- a/Config__test_8cpp_source.html +++ b/Config__test_8cpp_source.html @@ -1655,16 +1655,16 @@ $(function() {
ripple::detail::ValidatorsTxtGuard::validatorsFile
std::string validatorsFile() const
Definition: Config_test.cpp:268
ripple::detail::ValidatorsTxtGuard::validatorsFileExists
bool validatorsFileExists() const
Definition: Config_test.cpp:262
ripple::detail::ValidatorsTxtGuard::ValidatorsTxtGuard
ValidatorsTxtGuard(beast::unit_test::suite &test, path subDir, path const &validatorsFileName, bool useCounter=true)
Definition: Config_test.cpp:245
-
ripple::test::detail::DirGuard
Create a directory and remove it when it's done.
Definition: FileDirGuard.h:37
-
ripple::test::detail::DirGuard::subdir
path const & subdir() const
Definition: FileDirGuard.h:100
-
ripple::test::detail::DirGuard::rmDir
auto rmDir(path const &toRm)
Definition: FileDirGuard.h:49
-
ripple::test::detail::DirGuard::test_
beast::unit_test::suite & test_
Definition: FileDirGuard.h:46
-
ripple::test::detail::DirGuard::path
boost::filesystem::path path
Definition: FileDirGuard.h:39
-
ripple::test::detail::FileDirGuard
Write a file in a directory and remove when done.
Definition: FileDirGuard.h:110
-
ripple::test::detail::FileDirGuard::file_
path const file_
Definition: FileDirGuard.h:112
-
ripple::test::detail::FileDirGuard::fileExists
bool fileExists() const
Definition: FileDirGuard.h:172
-
ripple::test::detail::FileDirGuard::file
path const & file() const
Definition: FileDirGuard.h:166
-
ripple::test::detail::FileDirGuard::FileDirGuard
FileDirGuard(beast::unit_test::suite &test, path subDir, path file, std::string const &contents, bool useCounter=true, bool create=true)
Definition: FileDirGuard.h:116
+
ripple::test::detail::DirGuard
Create a directory and remove it when it's done.
Definition: FileDirGuard.h:39
+
ripple::test::detail::DirGuard::subdir
path const & subdir() const
Definition: FileDirGuard.h:102
+
ripple::test::detail::DirGuard::rmDir
auto rmDir(path const &toRm)
Definition: FileDirGuard.h:51
+
ripple::test::detail::DirGuard::test_
beast::unit_test::suite & test_
Definition: FileDirGuard.h:48
+
ripple::test::detail::DirGuard::path
boost::filesystem::path path
Definition: FileDirGuard.h:41
+
ripple::test::detail::FileDirGuard
Write a file in a directory and remove when done.
Definition: FileDirGuard.h:112
+
ripple::test::detail::FileDirGuard::file_
path const file_
Definition: FileDirGuard.h:114
+
ripple::test::detail::FileDirGuard::fileExists
bool fileExists() const
Definition: FileDirGuard.h:174
+
ripple::test::detail::FileDirGuard::file
path const & file() const
Definition: FileDirGuard.h:168
+
ripple::test::detail::FileDirGuard::FileDirGuard
FileDirGuard(beast::unit_test::suite &test, path subDir, path file, std::string const &contents, bool useCounter=true, bool create=true)
Definition: FileDirGuard.h:118
std::chrono::seconds
std::string::empty
T empty(T... args)
std::endl
T endl(T... args)
diff --git a/DatabaseCon_8cpp_source.html b/DatabaseCon_8cpp_source.html index 13193ba13e..f1776eb10b 100644 --- a/DatabaseCon_8cpp_source.html +++ b/DatabaseCon_8cpp_source.html @@ -383,7 +383,7 @@ $(function() {
ripple::DatabaseCon::session_
std::shared_ptr< soci::session > const session_
Definition: DatabaseCon.h:247
ripple::DatabaseCon::checkpointer_
std::shared_ptr< Checkpointer > checkpointer_
Definition: DatabaseCon.h:248
ripple::JobQueue
A pool of threads to perform work.
Definition: JobQueue.h:58
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
std::chrono::milliseconds
std::string::empty
T empty(T... args)
std::uintptr_t
diff --git a/DatabaseCon_8h_source.html b/DatabaseCon_8h_source.html index cdb0cb47d5..6af362290f 100644 --- a/DatabaseCon_8h_source.html +++ b/DatabaseCon_8h_source.html @@ -373,7 +373,7 @@ $(function() {
ripple::LockedSociSession::LockedSociSession
LockedSociSession(std::shared_ptr< soci::session > it, mutex &m)
Definition: DatabaseCon.h:50
ripple::LockedSociSession::session_
std::shared_ptr< soci::session > session_
Definition: DatabaseCon.h:46
ripple::LockedSociSession::operator->
soci::session * operator->()
Definition: DatabaseCon.h:74
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
std::shared_ptr::get
T get(T... args)
std::uintptr_t
mutex
diff --git a/Env_8h_source.html b/Env_8h_source.html index f651e14d68..b9ebaf47db 100644 --- a/Env_8h_source.html +++ b/Env_8h_source.html @@ -678,7 +678,7 @@ $(function() {
ripple::Application::checkSigs
virtual bool checkSigs() const =0
ripple::FeatureBitset
Definition: Feature.h:158
ripple::Issue
A currency issued by an account.
Definition: Issue.h:33
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::Logs::threshold
beast::severities::Severity threshold() const
Definition: Log.cpp:166
ripple::MPTIssue
Definition: MPTIssue.h:33
ripple::OpenLedger::current
std::shared_ptr< OpenView const > current() const
Returns a view to the current open ledger.
Definition: OpenLedger.cpp:51
diff --git a/FileDirGuard_8h_source.html b/FileDirGuard_8h_source.html index 3b8f5f6f8c..3a3cf43bbb 100644 --- a/FileDirGuard_8h_source.html +++ b/FileDirGuard_8h_source.html @@ -104,177 +104,180 @@ $(function() {
26
27#include <boost/filesystem.hpp>
28
-
29namespace ripple {
-
30namespace test {
-
31namespace detail {
-
32
-
36class DirGuard
-
37{
-
38protected:
-
39 using path = boost::filesystem::path;
-
40
-
41private:
-
42 path subDir_;
-
43 bool rmSubDir_{false};
-
44
-
45protected:
-
46 beast::unit_test::suite& test_;
-
47
-
48 auto
-
49 rmDir(path const& toRm)
-
50 {
-
51 if (is_directory(toRm) && is_empty(toRm))
-
52 remove(toRm);
-
53 else
-
54 test_.log << "Expected " << toRm.string()
-
55 << " to be an empty existing directory." << std::endl;
-
56 }
-
57
-
58public:
-
59 DirGuard(beast::unit_test::suite& test, path subDir, bool useCounter = true)
-
60 : subDir_(std::move(subDir)), test_(test)
-
61 {
-
62 using namespace boost::filesystem;
-
63
-
64 static auto subDirCounter = 0;
-
65 if (useCounter)
-
66 subDir_ += std::to_string(++subDirCounter);
-
67 if (!exists(subDir_))
-
68 {
-
69 create_directory(subDir_);
-
70 rmSubDir_ = true;
-
71 }
-
72 else if (is_directory(subDir_))
-
73 rmSubDir_ = false;
-
74 else
-
75 {
-
76 // Cannot run the test. Someone created a file where we want to
-
77 // put our directory
-
78 Throw<std::runtime_error>(
-
79 "Cannot create directory: " + subDir_.string());
-
80 }
-
81 }
-
82
-
83 ~DirGuard()
-
84 {
-
85 try
-
86 {
-
87 using namespace boost::filesystem;
-
88
-
89 if (rmSubDir_)
-
90 rmDir(subDir_);
-
91 }
-
92 catch (std::exception& e)
-
93 {
-
94 // if we throw here, just let it die.
-
95 test_.log << "Error in ~DirGuard: " << e.what() << std::endl;
-
96 };
-
97 }
-
98
-
99 path const&
-
100 subdir() const
-
101 {
-
102 return subDir_;
-
103 }
-
104};
-
105
-
109class FileDirGuard : public DirGuard
-
110{
-
111protected:
-
112 path const file_;
-
113 bool created_ = false;
-
114
-
115public:
-
116 FileDirGuard(
-
117 beast::unit_test::suite& test,
-
118 path subDir,
-
119 path file,
-
120 std::string const& contents,
-
121 bool useCounter = true,
-
122 bool create = true)
-
123 : DirGuard(test, subDir, useCounter)
-
124 , file_(file.is_absolute() ? file : subdir() / file)
-
125 {
-
126 if (!exists(file_))
-
127 {
-
128 if (create)
-
129 {
-
130 std::ofstream o(file_.string());
-
131 o << contents;
-
132 created_ = true;
-
133 }
-
134 }
-
135 else
-
136 {
-
137 Throw<std::runtime_error>(
-
138 "Refusing to overwrite existing file: " + file_.string());
-
139 }
-
140 }
-
141
-
142 ~FileDirGuard()
-
143 {
-
144 try
-
145 {
-
146 using namespace boost::filesystem;
-
147 if (exists(file_))
-
148 {
-
149 remove(file_);
-
150 }
-
151 else
-
152 {
-
153 if (created_)
-
154 test_.log << "Expected " << file_.string()
-
155 << " to be an existing file." << std::endl;
-
156 }
-
157 }
-
158 catch (std::exception& e)
-
159 {
-
160 // if we throw here, just let it die.
-
161 test_.log << "Error in ~FileGuard: " << e.what() << std::endl;
-
162 };
-
163 }
-
164
-
165 path const&
-
166 file() const
-
167 {
-
168 return file_;
-
169 }
-
170
-
171 bool
-
172 fileExists() const
-
173 {
-
174 return boost::filesystem::exists(file_);
-
175 }
-
176};
-
177
-
178} // namespace detail
-
179} // namespace test
-
180} // namespace ripple
-
181
-
182#endif // TEST_UNIT_TEST_DIRGUARD_H
+
29#include <fstream>
+
30
+
31namespace ripple {
+
32namespace test {
+
33namespace detail {
+
34
+
38class DirGuard
+
39{
+
40protected:
+
41 using path = boost::filesystem::path;
+
42
+
43private:
+
44 path subDir_;
+
45 bool rmSubDir_{false};
+
46
+
47protected:
+
48 beast::unit_test::suite& test_;
+
49
+
50 auto
+
51 rmDir(path const& toRm)
+
52 {
+
53 if (is_directory(toRm) && is_empty(toRm))
+
54 remove(toRm);
+
55 else
+
56 test_.log << "Expected " << toRm.string()
+
57 << " to be an empty existing directory." << std::endl;
+
58 }
+
59
+
60public:
+
61 DirGuard(beast::unit_test::suite& test, path subDir, bool useCounter = true)
+
62 : subDir_(std::move(subDir)), test_(test)
+
63 {
+
64 using namespace boost::filesystem;
+
65
+
66 static auto subDirCounter = 0;
+
67 if (useCounter)
+
68 subDir_ += std::to_string(++subDirCounter);
+
69 if (!exists(subDir_))
+
70 {
+
71 create_directory(subDir_);
+
72 rmSubDir_ = true;
+
73 }
+
74 else if (is_directory(subDir_))
+
75 rmSubDir_ = false;
+
76 else
+
77 {
+
78 // Cannot run the test. Someone created a file where we want to
+
79 // put our directory
+
80 Throw<std::runtime_error>(
+
81 "Cannot create directory: " + subDir_.string());
+
82 }
+
83 }
+
84
+
85 ~DirGuard()
+
86 {
+
87 try
+
88 {
+
89 using namespace boost::filesystem;
+
90
+
91 if (rmSubDir_)
+
92 rmDir(subDir_);
+
93 }
+
94 catch (std::exception& e)
+
95 {
+
96 // if we throw here, just let it die.
+
97 test_.log << "Error in ~DirGuard: " << e.what() << std::endl;
+
98 };
+
99 }
+
100
+
101 path const&
+
102 subdir() const
+
103 {
+
104 return subDir_;
+
105 }
+
106};
+
107
+
111class FileDirGuard : public DirGuard
+
112{
+
113protected:
+
114 path const file_;
+
115 bool created_ = false;
+
116
+
117public:
+
118 FileDirGuard(
+
119 beast::unit_test::suite& test,
+
120 path subDir,
+
121 path file,
+
122 std::string const& contents,
+
123 bool useCounter = true,
+
124 bool create = true)
+
125 : DirGuard(test, subDir, useCounter)
+
126 , file_(file.is_absolute() ? file : subdir() / file)
+
127 {
+
128 if (!exists(file_))
+
129 {
+
130 if (create)
+
131 {
+
132 std::ofstream o(file_.string());
+
133 o << contents;
+
134 created_ = true;
+
135 }
+
136 }
+
137 else
+
138 {
+
139 Throw<std::runtime_error>(
+
140 "Refusing to overwrite existing file: " + file_.string());
+
141 }
+
142 }
+
143
+
144 ~FileDirGuard()
+
145 {
+
146 try
+
147 {
+
148 using namespace boost::filesystem;
+
149 if (exists(file_))
+
150 {
+
151 remove(file_);
+
152 }
+
153 else
+
154 {
+
155 if (created_)
+
156 test_.log << "Expected " << file_.string()
+
157 << " to be an existing file." << std::endl;
+
158 }
+
159 }
+
160 catch (std::exception& e)
+
161 {
+
162 // if we throw here, just let it die.
+
163 test_.log << "Error in ~FileGuard: " << e.what() << std::endl;
+
164 };
+
165 }
+
166
+
167 path const&
+
168 file() const
+
169 {
+
170 return file_;
+
171 }
+
172
+
173 bool
+
174 fileExists() const
+
175 {
+
176 return boost::filesystem::exists(file_);
+
177 }
+
178};
+
179
+
180} // namespace detail
+
181} // namespace test
+
182} // namespace ripple
+
183
+
184#endif // TEST_UNIT_TEST_DIRGUARD_H
std::ofstream
std::string
beast::unit_test::suite
A testsuite class.
Definition: suite.h:55
beast::unit_test::suite::log
log_os< char > log
Logging output stream.
Definition: suite.h:152
-
ripple::test::detail::DirGuard
Create a directory and remove it when it's done.
Definition: FileDirGuard.h:37
-
ripple::test::detail::DirGuard::~DirGuard
~DirGuard()
Definition: FileDirGuard.h:83
-
ripple::test::detail::DirGuard::subDir_
path subDir_
Definition: FileDirGuard.h:42
-
ripple::test::detail::DirGuard::rmSubDir_
bool rmSubDir_
Definition: FileDirGuard.h:43
-
ripple::test::detail::DirGuard::subdir
path const & subdir() const
Definition: FileDirGuard.h:100
-
ripple::test::detail::DirGuard::DirGuard
DirGuard(beast::unit_test::suite &test, path subDir, bool useCounter=true)
Definition: FileDirGuard.h:59
-
ripple::test::detail::DirGuard::rmDir
auto rmDir(path const &toRm)
Definition: FileDirGuard.h:49
-
ripple::test::detail::DirGuard::test_
beast::unit_test::suite & test_
Definition: FileDirGuard.h:46
-
ripple::test::detail::DirGuard::path
boost::filesystem::path path
Definition: FileDirGuard.h:39
-
ripple::test::detail::FileDirGuard
Write a file in a directory and remove when done.
Definition: FileDirGuard.h:110
-
ripple::test::detail::FileDirGuard::file_
path const file_
Definition: FileDirGuard.h:112
-
ripple::test::detail::FileDirGuard::created_
bool created_
Definition: FileDirGuard.h:113
-
ripple::test::detail::FileDirGuard::fileExists
bool fileExists() const
Definition: FileDirGuard.h:172
-
ripple::test::detail::FileDirGuard::file
path const & file() const
Definition: FileDirGuard.h:166
-
ripple::test::detail::FileDirGuard::~FileDirGuard
~FileDirGuard()
Definition: FileDirGuard.h:142
-
ripple::test::detail::FileDirGuard::FileDirGuard
FileDirGuard(beast::unit_test::suite &test, path subDir, path file, std::string const &contents, bool useCounter=true, bool create=true)
Definition: FileDirGuard.h:116
+
ripple::test::detail::DirGuard
Create a directory and remove it when it's done.
Definition: FileDirGuard.h:39
+
ripple::test::detail::DirGuard::~DirGuard
~DirGuard()
Definition: FileDirGuard.h:85
+
ripple::test::detail::DirGuard::subDir_
path subDir_
Definition: FileDirGuard.h:44
+
ripple::test::detail::DirGuard::rmSubDir_
bool rmSubDir_
Definition: FileDirGuard.h:45
+
ripple::test::detail::DirGuard::subdir
path const & subdir() const
Definition: FileDirGuard.h:102
+
ripple::test::detail::DirGuard::DirGuard
DirGuard(beast::unit_test::suite &test, path subDir, bool useCounter=true)
Definition: FileDirGuard.h:61
+
ripple::test::detail::DirGuard::rmDir
auto rmDir(path const &toRm)
Definition: FileDirGuard.h:51
+
ripple::test::detail::DirGuard::test_
beast::unit_test::suite & test_
Definition: FileDirGuard.h:48
+
ripple::test::detail::DirGuard::path
boost::filesystem::path path
Definition: FileDirGuard.h:41
+
ripple::test::detail::FileDirGuard
Write a file in a directory and remove when done.
Definition: FileDirGuard.h:112
+
ripple::test::detail::FileDirGuard::file_
path const file_
Definition: FileDirGuard.h:114
+
ripple::test::detail::FileDirGuard::created_
bool created_
Definition: FileDirGuard.h:115
+
ripple::test::detail::FileDirGuard::fileExists
bool fileExists() const
Definition: FileDirGuard.h:174
+
ripple::test::detail::FileDirGuard::file
path const & file() const
Definition: FileDirGuard.h:168
+
ripple::test::detail::FileDirGuard::~FileDirGuard
~FileDirGuard()
Definition: FileDirGuard.h:144
+
ripple::test::detail::FileDirGuard::FileDirGuard
FileDirGuard(beast::unit_test::suite &test, path subDir, path file, std::string const &contents, bool useCounter=true, bool create=true)
Definition: FileDirGuard.h:118
ripple::test::jtx::path
Add a path.
Definition: paths.h:58
std::endl
T endl(T... args)
std::exception
+
fstream
ripple::test::jtx::create
Json::Value create(AccountID const &account, AccountID const &to, STAmount const &amount, NetClock::duration const &settleDelay, PublicKey const &pk, std::optional< NetClock::time_point > const &cancelAfter, std::optional< std::uint32_t > const &dstTag)
Definition: TestHelpers.cpp:217
ripple
Use hash_* containers for keys that do not need a cryptographically secure hashing algorithm.
Definition: algorithm.h:25
std
STL namespace.
diff --git a/FileUtilities_8cpp_source.html b/FileUtilities_8cpp_source.html index 12dfcfc827..41e237dbcc 100644 --- a/FileUtilities_8cpp_source.html +++ b/FileUtilities_8cpp_source.html @@ -106,92 +106,98 @@ $(function() {
28
29#include <cerrno>
30#include <cstddef>
-
31#include <ios>
-
32#include <iterator>
-
33#include <optional>
-
34#include <string>
-
35
-
36namespace ripple {
-
37
-
38std::string
-
39getFileContents(
-
40 boost::system::error_code& ec,
-
41 boost::filesystem::path const& sourcePath,
-
42 std::optional<std::size_t> maxSize)
-
43{
-
44 using namespace boost::filesystem;
-
45 using namespace boost::system::errc;
-
46
-
47 path fullPath{canonical(sourcePath, ec)};
-
48 if (ec)
-
49 return {};
-
50
-
51 if (maxSize && (file_size(fullPath, ec) > *maxSize || ec))
-
52 {
-
53 if (!ec)
-
54 ec = make_error_code(file_too_large);
-
55 return {};
-
56 }
-
57
-
58 ifstream fileStream(fullPath, std::ios::in);
-
59
-
60 if (!fileStream)
-
61 {
-
62 ec = make_error_code(static_cast<errc_t>(errno));
-
63 return {};
-
64 }
-
65
-
66 std::string const result{
-
67 std::istreambuf_iterator<char>{fileStream},
-
68 std::istreambuf_iterator<char>{}};
-
69
-
70 if (fileStream.bad())
-
71 {
-
72 ec = make_error_code(static_cast<errc_t>(errno));
-
73 return {};
-
74 }
-
75
-
76 return result;
-
77}
-
78
-
79void
-
80writeFileContents(
-
81 boost::system::error_code& ec,
-
82 boost::filesystem::path const& destPath,
-
83 std::string const& contents)
-
84{
-
85 using namespace boost::filesystem;
-
86 using namespace boost::system::errc;
-
87
-
88 ofstream fileStream(destPath, std::ios::out | std::ios::trunc);
-
89
-
90 if (!fileStream)
-
91 {
-
92 ec = make_error_code(static_cast<errc_t>(errno));
-
93 return;
-
94 }
-
95
-
96 fileStream << contents;
+
31#include <fstream>
+
32#include <ios>
+
33#include <iterator>
+
34#include <optional>
+
35#include <string>
+
36
+
37namespace ripple {
+
38
+
39std::string
+
40getFileContents(
+
41 boost::system::error_code& ec,
+
42 boost::filesystem::path const& sourcePath,
+
43 std::optional<std::size_t> maxSize)
+
44{
+
45 using namespace boost::filesystem;
+
46 using namespace boost::system::errc;
+
47
+
48 path fullPath{canonical(sourcePath, ec)};
+
49 if (ec)
+
50 return {};
+
51
+
52 if (maxSize && (file_size(fullPath, ec) > *maxSize || ec))
+
53 {
+
54 if (!ec)
+
55 ec = make_error_code(file_too_large);
+
56 return {};
+
57 }
+
58
+
59 std::ifstream fileStream(fullPath.string(), std::ios::in);
+
60
+
61 if (!fileStream)
+
62 {
+
63 ec = make_error_code(static_cast<errc_t>(errno));
+
64 return {};
+
65 }
+
66
+
67 std::string const result{
+
68 std::istreambuf_iterator<char>{fileStream},
+
69 std::istreambuf_iterator<char>{}};
+
70
+
71 if (fileStream.bad())
+
72 {
+
73 ec = make_error_code(static_cast<errc_t>(errno));
+
74 return {};
+
75 }
+
76
+
77 return result;
+
78}
+
79
+
80void
+
81writeFileContents(
+
82 boost::system::error_code& ec,
+
83 boost::filesystem::path const& destPath,
+
84 std::string const& contents)
+
85{
+
86 using namespace boost::filesystem;
+
87 using namespace boost::system::errc;
+
88
+
89 std::ofstream fileStream(
+
90 destPath.string(), std::ios::out | std::ios::trunc);
+
91
+
92 if (!fileStream)
+
93 {
+
94 ec = make_error_code(static_cast<errc_t>(errno));
+
95 return;
+
96 }
97
-
98 if (fileStream.bad())
-
99 {
-
100 ec = make_error_code(static_cast<errc_t>(errno));
-
101 return;
-
102 }
-
103}
-
104
-
105} // namespace ripple
+
98 fileStream << contents;
+
99
+
100 if (fileStream.bad())
+
101 {
+
102 ec = make_error_code(static_cast<errc_t>(errno));
+
103 return;
+
104 }
+
105}
+
106
+
107} // namespace ripple
+
std::ifstream::bad
T bad(T... args)
+
std::ifstream
+
std::ofstream
std::string
cerrno
cstddef
+
fstream
ios
std::istreambuf_iterator
iterator
ripple
Use hash_* containers for keys that do not need a cryptographically secure hashing algorithm.
Definition: algorithm.h:25
ripple::ECDSACanonicality::canonical
@ canonical
ripple::make_error_code
std::error_code make_error_code(ripple::TokenCodecErrc e)
Definition: token_errors.h:97
-
ripple::getFileContents
std::string getFileContents(boost::system::error_code &ec, boost::filesystem::path const &sourcePath, std::optional< std::size_t > maxSize=std::nullopt)
Definition: FileUtilities.cpp:39
-
ripple::writeFileContents
void writeFileContents(boost::system::error_code &ec, boost::filesystem::path const &destPath, std::string const &contents)
Definition: FileUtilities.cpp:80
+
ripple::getFileContents
std::string getFileContents(boost::system::error_code &ec, boost::filesystem::path const &sourcePath, std::optional< std::size_t > maxSize=std::nullopt)
Definition: FileUtilities.cpp:40
+
ripple::writeFileContents
void writeFileContents(boost::system::error_code &ec, boost::filesystem::path const &destPath, std::string const &contents)
Definition: FileUtilities.cpp:81
optional
string
diff --git a/FileUtilities_8h_source.html b/FileUtilities_8h_source.html index d40e6ebfec..ffa0913816 100644 --- a/FileUtilities_8h_source.html +++ b/FileUtilities_8h_source.html @@ -122,8 +122,8 @@ $(function() {
44#endif
std::string
ripple
Use hash_* containers for keys that do not need a cryptographically secure hashing algorithm.
Definition: algorithm.h:25
-
ripple::getFileContents
std::string getFileContents(boost::system::error_code &ec, boost::filesystem::path const &sourcePath, std::optional< std::size_t > maxSize=std::nullopt)
Definition: FileUtilities.cpp:39
-
ripple::writeFileContents
void writeFileContents(boost::system::error_code &ec, boost::filesystem::path const &destPath, std::string const &contents)
Definition: FileUtilities.cpp:80
+
ripple::getFileContents
std::string getFileContents(boost::system::error_code &ec, boost::filesystem::path const &sourcePath, std::optional< std::size_t > maxSize=std::nullopt)
Definition: FileUtilities.cpp:40
+
ripple::writeFileContents
void writeFileContents(boost::system::error_code &ec, boost::filesystem::path const &destPath, std::string const &contents)
Definition: FileUtilities.cpp:81
optional
diff --git a/FileUtilities__test_8cpp_source.html b/FileUtilities__test_8cpp_source.html index d879a209b7..bf065dadee 100644 --- a/FileUtilities__test_8cpp_source.html +++ b/FileUtilities__test_8cpp_source.html @@ -164,14 +164,14 @@ $(function() {
ripple::FileUtilities_test
Definition: FileUtilities_test.cpp:29
ripple::FileUtilities_test::testGetFileContents
void testGetFileContents()
Definition: FileUtilities_test.cpp:32
ripple::FileUtilities_test::run
void run() override
Runs the suite.
Definition: FileUtilities_test.cpp:76
-
ripple::test::detail::FileDirGuard
Write a file in a directory and remove when done.
Definition: FileDirGuard.h:110
-
ripple::test::detail::FileDirGuard::file
path const & file() const
Definition: FileDirGuard.h:166
+
ripple::test::detail::FileDirGuard
Write a file in a directory and remove when done.
Definition: FileDirGuard.h:112
+
ripple::test::detail::FileDirGuard::file
path const & file() const
Definition: FileDirGuard.h:168
ripple::test::jtx::path
Add a path.
Definition: paths.h:58
ripple::test::detail
Definition: ValidatorSite_test.cpp:41
ripple
Use hash_* containers for keys that do not need a cryptographically secure hashing algorithm.
Definition: algorithm.h:25
ripple::kilobytes
constexpr auto kilobytes(T value) noexcept
Definition: ByteUtilities.h:27
-
ripple::getFileContents
std::string getFileContents(boost::system::error_code &ec, boost::filesystem::path const &sourcePath, std::optional< std::size_t > maxSize=std::nullopt)
Definition: FileUtilities.cpp:39
-
ripple::writeFileContents
void writeFileContents(boost::system::error_code &ec, boost::filesystem::path const &destPath, std::string const &contents)
Definition: FileUtilities.cpp:80
+
ripple::getFileContents
std::string getFileContents(boost::system::error_code &ec, boost::filesystem::path const &sourcePath, std::optional< std::size_t > maxSize=std::nullopt)
Definition: FileUtilities.cpp:40
+
ripple::writeFileContents
void writeFileContents(boost::system::error_code &ec, boost::filesystem::path const &destPath, std::string const &contents)
Definition: FileUtilities.cpp:81
diff --git a/JobQueue_8cpp_source.html b/JobQueue_8cpp_source.html index 9908478d07..4996416222 100644 --- a/JobQueue_8cpp_source.html +++ b/JobQueue_8cpp_source.html @@ -585,7 +585,7 @@ $(function() {
ripple::Job::doJob
void doJob()
Definition: Job.cpp:62
ripple::Job::queue_time
clock_type::time_point const & queue_time() const
Returns the time when the job was queued.
Definition: Job.cpp:56
ripple::Job::getType
JobType getType() const
Definition: Job.cpp:50
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::Workers::getNumberOfThreads
int getNumberOfThreads() const noexcept
Retrieve the desired number of threads.
Definition: Workers.cpp:54
ripple::Workers::addTask
void addTask()
Add a task to be performed.
Definition: Workers.cpp:129
ripple::perf::PerfLog
Singleton class that maintains performance counters and optionally writes Json-formatted data to a di...
Definition: PerfLog.h:52
diff --git a/JobQueue_8h_source.html b/JobQueue_8h_source.html index 6ba4ea587c..5e9aeea6ff 100644 --- a/JobQueue_8h_source.html +++ b/JobQueue_8h_source.html @@ -505,7 +505,7 @@ $(function() {
ripple::JobQueue::addJob
bool addJob(JobType type, std::string const &name, JobHandler &&jobHandler)
Adds a job to the JobQueue.
Definition: JobQueue.h:168
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::Workers
Workers is effectively a thread pool.
Definition: Workers.h:82
ripple::perf::PerfLog
Singleton class that maintains performance counters and optionally writes Json-formatted data to a di...
Definition: PerfLog.h:52
diff --git a/JobTypeData_8h_source.html b/JobTypeData_8h_source.html index c0eee75490..6b22831785 100644 --- a/JobTypeData_8h_source.html +++ b/JobTypeData_8h_source.html @@ -195,7 +195,7 @@ $(function() {
ripple::LoadMonitor::setTargetLatency
void setTargetLatency(std::chrono::milliseconds avg, std::chrono::milliseconds pk)
Definition: LoadMonitor.cpp:144
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple
Use hash_* containers for keys that do not need a cryptographically secure hashing algorithm.
Definition: algorithm.h:25
ripple::JobType
JobType
Definition: Job.h:35
diff --git a/LogLevel_8cpp_source.html b/LogLevel_8cpp_source.html index bae44f0ae7..a28f29be3e 100644 --- a/LogLevel_8cpp_source.html +++ b/LogLevel_8cpp_source.html @@ -182,8 +182,8 @@ $(function() {
ripple::rpcINVALID_PARAMS
@ rpcINVALID_PARAMS
Definition: ErrorCodes.h:84
ripple::rpcError
Json::Value rpcError(int iError)
Definition: RPCErr.cpp:31
ripple::doLogLevel
Json::Value doLogLevel(RPC::JsonContext &)
Definition: LogLevel.cpp:34
-
ripple::LogSeverity
LogSeverity
Definition: Log.h:37
-
ripple::lsINVALID
@ lsINVALID
Definition: Log.h:38
+
ripple::LogSeverity
LogSeverity
Definition: Log.h:38
+
ripple::lsINVALID
@ lsINVALID
Definition: Log.h:39
ripple::RPC::Context::app
Application & app
Definition: Context.h:41
ripple::RPC::JsonContext::params
Json::Value params
Definition: Context.h:63
diff --git a/Log_8cpp_source.html b/Log_8cpp_source.html index 190f98cf20..6faad350bb 100644 --- a/Log_8cpp_source.html +++ b/Log_8cpp_source.html @@ -575,18 +575,18 @@ $(function() {
ripple::Logs::File::writeln
void writeln(char const *text)
write to the log file and append an end of line marker.
Definition: Log.cpp:123
ripple::Logs::File::File
File()
Construct with no associated system file.
Definition: Log.cpp:68
ripple::Logs::File::open
bool open(boost::filesystem::path const &path)
Associate a system file with the log.
Definition: Log.cpp:79
- +
ripple::Logs::Sink::write
void write(beast::severities::Severity level, std::string const &text) override
Write text to the sink at the specified severity.
Definition: Log.cpp:50
ripple::Logs::Sink::writeAlways
void writeAlways(beast::severities::Severity level, std::string const &text) override
Bypass filter and write text to the sink at the specified severity.
Definition: Log.cpp:59
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::Logs::get
beast::Journal::Sink & get(std::string const &name)
Definition: Log.cpp:146
-
ripple::Logs::thresh_
beast::severities::Severity thresh_
Definition: Log.h:166
+
ripple::Logs::thresh_
beast::severities::Severity thresh_
Definition: Log.h:167
ripple::Logs::fromString
static LogSeverity fromString(std::string const &s)
Definition: Log.cpp:302
ripple::Logs::write
void write(beast::severities::Severity level, std::string const &partition, std::string const &text, bool console)
Definition: Log.cpp:192
-
ripple::Logs::sinks_
std::map< std::string, std::unique_ptr< beast::Journal::Sink >, boost::beast::iless > sinks_
Definition: Log.h:165
-
ripple::Logs::file_
File file_
Definition: Log.h:167
+
ripple::Logs::sinks_
std::map< std::string, std::unique_ptr< beast::Journal::Sink >, boost::beast::iless > sinks_
Definition: Log.h:166
+
ripple::Logs::file_
File file_
Definition: Log.h:168
ripple::Logs::threshold
beast::severities::Severity threshold() const
Definition: Log.cpp:166
-
ripple::Logs::mutex_
std::mutex mutex_
Definition: Log.h:160
+
ripple::Logs::mutex_
std::mutex mutex_
Definition: Log.h:161
ripple::Logs::toString
static std::string toString(LogSeverity s)
Definition: Log.cpp:279
ripple::Logs::journal
beast::Journal journal(std::string const &name)
Definition: Log.cpp:160
ripple::Logs::makeSink
virtual std::unique_ptr< beast::Journal::Sink > makeSink(std::string const &partition, beast::severities::Severity startingLevel)
Definition: Log.cpp:220
@@ -595,10 +595,10 @@ $(function() {
ripple::Logs::format
static void format(std::string &output, std::string const &message, beast::severities::Severity severity, std::string const &partition)
Definition: Log.cpp:327
ripple::Logs::open
bool open(boost::filesystem::path const &pathToLogFile)
Definition: Log.cpp:140
ripple::Logs::partition_severities
std::vector< std::pair< std::string, std::string > > partition_severities() const
Definition: Log.cpp:181
-
ripple::Logs::silent_
bool silent_
Definition: Log.h:168
+
ripple::Logs::silent_
bool silent_
Definition: Log.h:169
ripple::Logs::operator[]
beast::Journal::Sink & operator[](std::string const &name)
Definition: Log.cpp:154
ripple::Logs::Logs
Logs(beast::severities::Severity level)
Definition: Log.cpp:134
-
ripple::Logs::maximumMessageCharacters
@ maximumMessageCharacters
Definition: Log.h:243
+
ripple::Logs::maximumMessageCharacters
@ maximumMessageCharacters
Definition: Log.h:244
ripple::Logs::fromSeverity
static LogSeverity fromSeverity(beast::severities::Severity level)
Definition: Log.cpp:226
std::vector::emplace_back
T emplace_back(T... args)
@@ -622,14 +622,14 @@ $(function() {
ripple::get
T get(Section const &section, std::string const &name, T const &defaultValue=T{})
Retrieve a key/value pair from a section.
Definition: BasicConfig.h:355
ripple::setDebugLogSink
std::unique_ptr< beast::Journal::Sink > setDebugLogSink(std::unique_ptr< beast::Journal::Sink > sink)
Set the sink for the debug journal.
Definition: Log.cpp:462
ripple::debugSink
static DebugSink & debugSink()
Definition: Log.cpp:455
-
ripple::LogSeverity
LogSeverity
Definition: Log.h:37
-
ripple::lsDEBUG
@ lsDEBUG
Definition: Log.h:41
-
ripple::lsINFO
@ lsINFO
Definition: Log.h:42
-
ripple::lsERROR
@ lsERROR
Definition: Log.h:45
-
ripple::lsWARNING
@ lsWARNING
Definition: Log.h:43
-
ripple::lsTRACE
@ lsTRACE
Definition: Log.h:39
-
ripple::lsINVALID
@ lsINVALID
Definition: Log.h:38
-
ripple::lsFATAL
@ lsFATAL
Definition: Log.h:46
+
ripple::LogSeverity
LogSeverity
Definition: Log.h:38
+
ripple::lsDEBUG
@ lsDEBUG
Definition: Log.h:42
+
ripple::lsINFO
@ lsINFO
Definition: Log.h:43
+
ripple::lsERROR
@ lsERROR
Definition: Log.h:46
+
ripple::lsWARNING
@ lsWARNING
Definition: Log.h:44
+
ripple::lsTRACE
@ lsTRACE
Definition: Log.h:40
+
ripple::lsINVALID
@ lsINVALID
Definition: Log.h:39
+
ripple::lsFATAL
@ lsFATAL
Definition: Log.h:47
std::string::replace
T replace(T... args)
diff --git a/Log_8h_source.html b/Log_8h_source.html index 615dccd24d..34f219b868 100644 --- a/Log_8h_source.html +++ b/Log_8h_source.html @@ -104,251 +104,252 @@ $(function() {
26#include <boost/beast/core/string.hpp>
27#include <boost/filesystem.hpp>
28
-
29#include <map>
-
30#include <memory>
-
31#include <mutex>
-
32#include <utility>
-
33
-
34namespace ripple {
-
35
-
36// DEPRECATED use beast::severities::Severity instead
-
37enum LogSeverity {
-
38 lsINVALID = -1, // used to indicate an invalid severity
-
39 lsTRACE = 0, // Very low-level progress information, details inside
-
40 // an operation
-
41 lsDEBUG = 1, // Function-level progress information, operations
-
42 lsINFO = 2, // Server-level progress information, major operations
-
43 lsWARNING = 3, // Conditions that warrant human attention, may indicate
-
44 // a problem
-
45 lsERROR = 4, // A condition that indicates a problem
-
46 lsFATAL = 5 // A severe condition that indicates a server problem
-
47};
-
48
-
50class Logs
-
51{
-
52private:
-
53 class Sink : public beast::Journal::Sink
-
54 {
-
55 private:
-
56 Logs& logs_;
-
57 std::string partition_;
-
58
-
59 public:
-
60 Sink(
-
61 std::string const& partition,
-
62 beast::severities::Severity thresh,
-
63 Logs& logs);
-
64
-
65 Sink(Sink const&) = delete;
-
66 Sink&
-
67 operator=(Sink const&) = delete;
-
68
-
69 void
-
70 write(beast::severities::Severity level, std::string const& text)
-
71 override;
-
72
-
73 void
-
74 writeAlways(beast::severities::Severity level, std::string const& text)
-
75 override;
-
76 };
-
77
-
85 class File
-
86 {
-
87 public:
-
92 File();
-
93
-
97 ~File() = default;
-
98
-
103 bool
-
104 isOpen() const noexcept;
-
105
-
114 bool
-
115 open(boost::filesystem::path const& path);
-
116
-
121 bool
-
122 closeAndReopen();
-
123
-
125 void
-
126 close();
-
127
-
131 void
-
132 write(char const* text);
-
133
-
137 void
-
138 writeln(char const* text);
-
139
-
142 void
-
143 write(std::string const& str)
-
144 {
-
145 write(str.c_str());
-
146 }
-
147
-
148 void
-
149 writeln(std::string const& str)
-
150 {
-
151 writeln(str.c_str());
-
152 }
-
155 private:
-
156 std::unique_ptr<std::ofstream> m_stream;
-
157 boost::filesystem::path m_path;
-
158 };
-
159
-
160 std::mutex mutable mutex_;
-
161 std::map<
-
162 std::string,
-
163 std::unique_ptr<beast::Journal::Sink>,
-
164 boost::beast::iless>
-
165 sinks_;
-
166 beast::severities::Severity thresh_;
-
167 File file_;
-
168 bool silent_ = false;
-
169
-
170public:
-
171 Logs(beast::severities::Severity level);
-
172
-
173 Logs(Logs const&) = delete;
-
174 Logs&
-
175 operator=(Logs const&) = delete;
-
176
-
177 virtual ~Logs() = default;
-
178
-
179 bool
-
180 open(boost::filesystem::path const& pathToLogFile);
-
181
-
182 beast::Journal::Sink&
-
183 get(std::string const& name);
-
184
-
185 beast::Journal::Sink&
-
186 operator[](std::string const& name);
-
187
-
188 beast::Journal
-
189 journal(std::string const& name);
-
190
-
191 beast::severities::Severity
-
192 threshold() const;
-
193
-
194 void
-
195 threshold(beast::severities::Severity thresh);
-
196
-
197 std::vector<std::pair<std::string, std::string>>
-
198 partition_severities() const;
-
199
-
200 void
-
201 write(
-
202 beast::severities::Severity level,
-
203 std::string const& partition,
-
204 std::string const& text,
-
205 bool console);
-
206
-
207 std::string
-
208 rotate();
-
209
-
215 void
-
216 silent(bool bSilent)
-
217 {
-
218 silent_ = bSilent;
-
219 }
-
220
-
221 virtual std::unique_ptr<beast::Journal::Sink>
-
222 makeSink(
-
223 std::string const& partition,
-
224 beast::severities::Severity startingLevel);
-
225
-
226public:
-
227 static LogSeverity
-
228 fromSeverity(beast::severities::Severity level);
-
229
-
230 static beast::severities::Severity
-
231 toSeverity(LogSeverity level);
-
232
-
233 static std::string
-
234 toString(LogSeverity s);
-
235
-
236 static LogSeverity
-
237 fromString(std::string const& s);
-
238
-
239private:
-
240 enum {
-
241 // Maximum line length for log messages.
-
242 // If the message exceeds this length it will be truncated with elipses.
-
243 maximumMessageCharacters = 12 * 1024
-
244 };
-
245
-
246 static void
-
247 format(
-
248 std::string& output,
-
249 std::string const& message,
-
250 beast::severities::Severity severity,
-
251 std::string const& partition);
-
252};
-
253
-
254// Wraps a Journal::Stream to skip evaluation of
-
255// expensive argument lists if the stream is not active.
-
256#ifndef JLOG
-
257#define JLOG(x) \
-
258 if (!x) \
-
259 { \
-
260 } \
-
261 else \
-
262 x
-
263#endif
-
264
-
265#ifndef CLOG
-
266#define CLOG(ss) \
-
267 if (!ss) \
-
268 ; \
-
269 else \
-
270 *ss
-
271#endif
-
272
-
273//------------------------------------------------------------------------------
-
274// Debug logging:
-
275
-
281std::unique_ptr<beast::Journal::Sink>
-
282setDebugLogSink(std::unique_ptr<beast::Journal::Sink> sink);
-
283
-
289beast::Journal
-
290debugLog();
-
291
-
292} // namespace ripple
-
293
-
294#endif
+
29#include <fstream>
+
30#include <map>
+
31#include <memory>
+
32#include <mutex>
+
33#include <utility>
+
34
+
35namespace ripple {
+
36
+
37// DEPRECATED use beast::severities::Severity instead
+
38enum LogSeverity {
+
39 lsINVALID = -1, // used to indicate an invalid severity
+
40 lsTRACE = 0, // Very low-level progress information, details inside
+
41 // an operation
+
42 lsDEBUG = 1, // Function-level progress information, operations
+
43 lsINFO = 2, // Server-level progress information, major operations
+
44 lsWARNING = 3, // Conditions that warrant human attention, may indicate
+
45 // a problem
+
46 lsERROR = 4, // A condition that indicates a problem
+
47 lsFATAL = 5 // A severe condition that indicates a server problem
+
48};
+
49
+
51class Logs
+
52{
+
53private:
+
54 class Sink : public beast::Journal::Sink
+
55 {
+
56 private:
+
57 Logs& logs_;
+
58 std::string partition_;
+
59
+
60 public:
+
61 Sink(
+
62 std::string const& partition,
+
63 beast::severities::Severity thresh,
+
64 Logs& logs);
+
65
+
66 Sink(Sink const&) = delete;
+
67 Sink&
+
68 operator=(Sink const&) = delete;
+
69
+
70 void
+
71 write(beast::severities::Severity level, std::string const& text)
+
72 override;
+
73
+
74 void
+
75 writeAlways(beast::severities::Severity level, std::string const& text)
+
76 override;
+
77 };
+
78
+
86 class File
+
87 {
+
88 public:
+
93 File();
+
94
+
98 ~File() = default;
+
99
+
104 bool
+
105 isOpen() const noexcept;
+
106
+
115 bool
+
116 open(boost::filesystem::path const& path);
+
117
+
122 bool
+
123 closeAndReopen();
+
124
+
126 void
+
127 close();
+
128
+
132 void
+
133 write(char const* text);
+
134
+
138 void
+
139 writeln(char const* text);
+
140
+
143 void
+
144 write(std::string const& str)
+
145 {
+
146 write(str.c_str());
+
147 }
+
148
+
149 void
+
150 writeln(std::string const& str)
+
151 {
+
152 writeln(str.c_str());
+
153 }
+
156 private:
+
157 std::unique_ptr<std::ofstream> m_stream;
+
158 boost::filesystem::path m_path;
+
159 };
+
160
+
161 std::mutex mutable mutex_;
+
162 std::map<
+
163 std::string,
+
164 std::unique_ptr<beast::Journal::Sink>,
+
165 boost::beast::iless>
+
166 sinks_;
+
167 beast::severities::Severity thresh_;
+
168 File file_;
+
169 bool silent_ = false;
+
170
+
171public:
+
172 Logs(beast::severities::Severity level);
+
173
+
174 Logs(Logs const&) = delete;
+
175 Logs&
+
176 operator=(Logs const&) = delete;
+
177
+
178 virtual ~Logs() = default;
+
179
+
180 bool
+
181 open(boost::filesystem::path const& pathToLogFile);
+
182
+
183 beast::Journal::Sink&
+
184 get(std::string const& name);
+
185
+
186 beast::Journal::Sink&
+
187 operator[](std::string const& name);
+
188
+
189 beast::Journal
+
190 journal(std::string const& name);
+
191
+
192 beast::severities::Severity
+
193 threshold() const;
+
194
+
195 void
+
196 threshold(beast::severities::Severity thresh);
+
197
+
198 std::vector<std::pair<std::string, std::string>>
+
199 partition_severities() const;
+
200
+
201 void
+
202 write(
+
203 beast::severities::Severity level,
+
204 std::string const& partition,
+
205 std::string const& text,
+
206 bool console);
+
207
+
208 std::string
+
209 rotate();
+
210
+
216 void
+
217 silent(bool bSilent)
+
218 {
+
219 silent_ = bSilent;
+
220 }
+
221
+
222 virtual std::unique_ptr<beast::Journal::Sink>
+
223 makeSink(
+
224 std::string const& partition,
+
225 beast::severities::Severity startingLevel);
+
226
+
227public:
+
228 static LogSeverity
+
229 fromSeverity(beast::severities::Severity level);
+
230
+
231 static beast::severities::Severity
+
232 toSeverity(LogSeverity level);
+
233
+
234 static std::string
+
235 toString(LogSeverity s);
+
236
+
237 static LogSeverity
+
238 fromString(std::string const& s);
+
239
+
240private:
+
241 enum {
+
242 // Maximum line length for log messages.
+
243 // If the message exceeds this length it will be truncated with elipses.
+
244 maximumMessageCharacters = 12 * 1024
+
245 };
+
246
+
247 static void
+
248 format(
+
249 std::string& output,
+
250 std::string const& message,
+
251 beast::severities::Severity severity,
+
252 std::string const& partition);
+
253};
+
254
+
255// Wraps a Journal::Stream to skip evaluation of
+
256// expensive argument lists if the stream is not active.
+
257#ifndef JLOG
+
258#define JLOG(x) \
+
259 if (!x) \
+
260 { \
+
261 } \
+
262 else \
+
263 x
+
264#endif
+
265
+
266#ifndef CLOG
+
267#define CLOG(ss) \
+
268 if (!ss) \
+
269 ; \
+
270 else \
+
271 *ss
+
272#endif
+
273
+
274//------------------------------------------------------------------------------
+
275// Debug logging:
+
276
+
282std::unique_ptr<beast::Journal::Sink>
+
283setDebugLogSink(std::unique_ptr<beast::Journal::Sink> sink);
+
284
+
290beast::Journal
+
291debugLog();
+
292
+
293} // namespace ripple
+
294
+
295#endif
std::string::c_str
T c_str(T... args)
beast::Journal::Sink
Abstraction for the underlying message destination.
Definition: Journal.h:76
beast::Journal
A generic endpoint for log messages.
Definition: Journal.h:60
-
ripple::Logs::File
Manages a system file containing logged output.
Definition: Log.h:86
+
ripple::Logs::File
Manages a system file containing logged output.
Definition: Log.h:87
ripple::Logs::File::isOpen
bool isOpen() const noexcept
Determine if a system file is associated with the log.
Definition: Log.cpp:73
ripple::Logs::File::closeAndReopen
bool closeAndReopen()
Close and re-open the system file associated with the log This assists in interoperating with externa...
Definition: Log.cpp:102
-
ripple::Logs::File::m_stream
std::unique_ptr< std::ofstream > m_stream
Definition: Log.h:156
-
ripple::Logs::File::writeln
void writeln(std::string const &str)
Definition: Log.h:149
+
ripple::Logs::File::m_stream
std::unique_ptr< std::ofstream > m_stream
Definition: Log.h:157
+
ripple::Logs::File::writeln
void writeln(std::string const &str)
Definition: Log.h:150
ripple::Logs::File::close
void close()
Close the system file if it is open.
Definition: Log.cpp:110
ripple::Logs::File::write
void write(char const *text)
write to the log file.
Definition: Log.cpp:116
ripple::Logs::File::writeln
void writeln(char const *text)
write to the log file and append an end of line marker.
Definition: Log.cpp:123
-
ripple::Logs::File::m_path
boost::filesystem::path m_path
Definition: Log.h:157
+
ripple::Logs::File::m_path
boost::filesystem::path m_path
Definition: Log.h:158
ripple::Logs::File::File
File()
Construct with no associated system file.
Definition: Log.cpp:68
ripple::Logs::File::~File
~File()=default
Destroy the object.
- +
ripple::Logs::Sink::write
void write(beast::severities::Severity level, std::string const &text) override
Write text to the sink at the specified severity.
Definition: Log.cpp:50
ripple::Logs::Sink::operator=
Sink & operator=(Sink const &)=delete
-
ripple::Logs::Sink::partition_
std::string partition_
Definition: Log.h:57
-
ripple::Logs::Sink::logs_
Logs & logs_
Definition: Log.h:56
+
ripple::Logs::Sink::partition_
std::string partition_
Definition: Log.h:58
+
ripple::Logs::Sink::logs_
Logs & logs_
Definition: Log.h:57
ripple::Logs::Sink::writeAlways
void writeAlways(beast::severities::Severity level, std::string const &text) override
Bypass filter and write text to the sink at the specified severity.
Definition: Log.cpp:59
ripple::Logs::Sink::Sink
Sink(Sink const &)=delete
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
-
ripple::Logs::silent
void silent(bool bSilent)
Set flag to write logs to stderr (false) or not (true).
Definition: Log.h:216
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
+
ripple::Logs::silent
void silent(bool bSilent)
Set flag to write logs to stderr (false) or not (true).
Definition: Log.h:217
ripple::Logs::get
beast::Journal::Sink & get(std::string const &name)
Definition: Log.cpp:146
-
ripple::Logs::thresh_
beast::severities::Severity thresh_
Definition: Log.h:166
+
ripple::Logs::thresh_
beast::severities::Severity thresh_
Definition: Log.h:167
ripple::Logs::fromString
static LogSeverity fromString(std::string const &s)
Definition: Log.cpp:302
ripple::Logs::Logs
Logs(Logs const &)=delete
ripple::Logs::write
void write(beast::severities::Severity level, std::string const &partition, std::string const &text, bool console)
Definition: Log.cpp:192
ripple::Logs::operator=
Logs & operator=(Logs const &)=delete
-
ripple::Logs::sinks_
std::map< std::string, std::unique_ptr< beast::Journal::Sink >, boost::beast::iless > sinks_
Definition: Log.h:165
-
ripple::Logs::file_
File file_
Definition: Log.h:167
+
ripple::Logs::sinks_
std::map< std::string, std::unique_ptr< beast::Journal::Sink >, boost::beast::iless > sinks_
Definition: Log.h:166
+
ripple::Logs::file_
File file_
Definition: Log.h:168
ripple::Logs::~Logs
virtual ~Logs()=default
ripple::Logs::threshold
beast::severities::Severity threshold() const
Definition: Log.cpp:166
-
ripple::Logs::mutex_
std::mutex mutex_
Definition: Log.h:160
+
ripple::Logs::mutex_
std::mutex mutex_
Definition: Log.h:161
ripple::Logs::toString
static std::string toString(LogSeverity s)
Definition: Log.cpp:279
ripple::Logs::journal
beast::Journal journal(std::string const &name)
Definition: Log.cpp:160
ripple::Logs::makeSink
virtual std::unique_ptr< beast::Journal::Sink > makeSink(std::string const &partition, beast::severities::Severity startingLevel)
Definition: Log.cpp:220
@@ -356,10 +357,11 @@ $(function() {
ripple::Logs::toSeverity
static beast::severities::Severity toSeverity(LogSeverity level)
Definition: Log.cpp:253
ripple::Logs::format
static void format(std::string &output, std::string const &message, beast::severities::Severity severity, std::string const &partition)
Definition: Log.cpp:327
ripple::Logs::partition_severities
std::vector< std::pair< std::string, std::string > > partition_severities() const
Definition: Log.cpp:181
-
ripple::Logs::silent_
bool silent_
Definition: Log.h:168
+
ripple::Logs::silent_
bool silent_
Definition: Log.h:169
ripple::Logs::operator[]
beast::Journal::Sink & operator[](std::string const &name)
Definition: Log.cpp:154
-
ripple::Logs::maximumMessageCharacters
@ maximumMessageCharacters
Definition: Log.h:243
+
ripple::Logs::maximumMessageCharacters
@ maximumMessageCharacters
Definition: Log.h:244
ripple::Logs::fromSeverity
static LogSeverity fromSeverity(beast::severities::Severity level)
Definition: Log.cpp:226
+ @@ -369,14 +371,14 @@ $(function() {
ripple::ConsensusPhase::open
@ open
We haven't closed our ledger yet, but others might have.
ripple::debugLog
beast::Journal debugLog()
Returns a debug journal.
Definition: Log.cpp:468
ripple::setDebugLogSink
std::unique_ptr< beast::Journal::Sink > setDebugLogSink(std::unique_ptr< beast::Journal::Sink > sink)
Set the sink for the debug journal.
Definition: Log.cpp:462
-
ripple::LogSeverity
LogSeverity
Definition: Log.h:37
-
ripple::lsDEBUG
@ lsDEBUG
Definition: Log.h:41
-
ripple::lsINFO
@ lsINFO
Definition: Log.h:42
-
ripple::lsERROR
@ lsERROR
Definition: Log.h:45
-
ripple::lsWARNING
@ lsWARNING
Definition: Log.h:43
-
ripple::lsTRACE
@ lsTRACE
Definition: Log.h:39
-
ripple::lsINVALID
@ lsINVALID
Definition: Log.h:38
-
ripple::lsFATAL
@ lsFATAL
Definition: Log.h:46
+
ripple::LogSeverity
LogSeverity
Definition: Log.h:38
+
ripple::lsDEBUG
@ lsDEBUG
Definition: Log.h:42
+
ripple::lsINFO
@ lsINFO
Definition: Log.h:43
+
ripple::lsERROR
@ lsERROR
Definition: Log.h:46
+
ripple::lsWARNING
@ lsWARNING
Definition: Log.h:44
+
ripple::lsTRACE
@ lsTRACE
Definition: Log.h:40
+
ripple::lsINVALID
@ lsINVALID
Definition: Log.h:39
+
ripple::lsFATAL
@ lsFATAL
Definition: Log.h:47
std
STL namespace.
diff --git a/Main_8cpp_source.html b/Main_8cpp_source.html index 4440010756..3e03c4cb9c 100644 --- a/Main_8cpp_source.html +++ b/Main_8cpp_source.html @@ -117,7 +117,7 @@ $(function() {
39#include <google/protobuf/stubs/common.h>
40
41#include <cstdlib>
-
42#include <iostream>
+
42#include <fstream>
43#include <stdexcept>
44#include <utility>
45
@@ -979,8 +979,8 @@ $(function() {
std::endl
T endl(T... args)
std::for_each
T for_each(T... args)
+ -
std::log
T log(T... args)
std::max
T max(T... args)
beast::severities
A namespace for easy access to logging severity values.
Definition: Journal.h:30
diff --git a/RPCCall_8cpp_source.html b/RPCCall_8cpp_source.html index 39d16f7844..0c50f31a1a 100644 --- a/RPCCall_8cpp_source.html +++ b/RPCCall_8cpp_source.html @@ -1820,7 +1820,7 @@ $(function() {
ripple::Config::rpc_ip
std::optional< beast::IP::Endpoint > rpc_ip
Definition: Config.h:274
ripple::Config::quiet
bool quiet() const
Definition: Config.h:326
ripple::HTTPClient::request
static void request(bool bSSL, boost::asio::io_service &io_service, std::string strSite, unsigned short const port, std::function< void(boost::asio::streambuf &sb, std::string const &strHost)> build, std::size_t responseMax, std::chrono::seconds timeout, std::function< bool(boost::system::error_code const &ecResult, int iStatus, std::string const &strData)> complete, beast::Journal &j)
Definition: HTTPClient.cpp:586
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::Logs::journal
beast::Journal journal(std::string const &name)
Definition: Log.cpp:160
ripple::RPCParser::parseLedger
Json::Value parseLedger(Json::Value const &jvParams)
Definition: RPCCall.cpp:622
diff --git a/RPCSub_8cpp_source.html b/RPCSub_8cpp_source.html index 3d2e4d2df0..b0b5715473 100644 --- a/RPCSub_8cpp_source.html +++ b/RPCSub_8cpp_source.html @@ -313,7 +313,7 @@ $(function() {
ripple::InfoSub::mLock
std::mutex mLock
Definition: InfoSub.h:239
ripple::JobQueue
A pool of threads to perform work.
Definition: JobQueue.h:58
ripple::JobQueue::addJob
bool addJob(JobType type, std::string const &name, JobHandler &&jobHandler)
Adds a job to the JobQueue.
Definition: JobQueue.h:168
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::RPCSubImp::m_io_service
boost::asio::io_service & m_io_service
Definition: RPCSub.cpp:180
diff --git a/RPCSub_8h_source.html b/RPCSub_8h_source.html index cb6f022481..5107b8aaf9 100644 --- a/RPCSub_8h_source.html +++ b/RPCSub_8h_source.html @@ -135,7 +135,7 @@ $(function() {
ripple::InfoSub::Source
Abstracts the source of subscription data.
Definition: InfoSub.h:68
ripple::InfoSub
Manages a client's subscription to data feeds.
Definition: InfoSub.h:52
ripple::JobQueue
A pool of threads to perform work.
Definition: JobQueue.h:58
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::RPCSub
Subscription object for JSON RPC.
Definition: RPCSub.h:32
ripple::RPCSub::setPassword
virtual void setPassword(std::string const &strPassword)=0
ripple::RPCSub::setUsername
virtual void setUsername(std::string const &strUsername)=0
diff --git a/RippleCalc_8cpp_source.html b/RippleCalc_8cpp_source.html index 5601402cc6..c8058ca10a 100644 --- a/RippleCalc_8cpp_source.html +++ b/RippleCalc_8cpp_source.html @@ -216,7 +216,7 @@ $(function() {
138} // namespace path
139} // namespace ripple
beast::Journal::fatal
Stream fatal() const
Definition: Journal.h:352
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::Logs::journal
beast::Journal journal(std::string const &name)
Definition: Log.cpp:160
ripple::PaymentSandbox
A wrapper which makes credits unavailable to balances.
Definition: PaymentSandbox.h:114
ripple::PaymentSandbox::apply
void apply(RawView &to)
Apply changes to base view.
Definition: PaymentSandbox.cpp:256
diff --git a/RippleCalc_8h_source.html b/RippleCalc_8h_source.html index 4130e46be1..9d4b9ca503 100644 --- a/RippleCalc_8h_source.html +++ b/RippleCalc_8h_source.html @@ -203,7 +203,7 @@ $(function() {
130} // namespace ripple
131
132#endif
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::PaymentSandbox
A wrapper which makes credits unavailable to balances.
Definition: PaymentSandbox.h:114
diff --git a/ServerStatus__test_8cpp_source.html b/ServerStatus__test_8cpp_source.html index ab8e23472b..27afea4d7e 100644 --- a/ServerStatus__test_8cpp_source.html +++ b/ServerStatus__test_8cpp_source.html @@ -759,7 +759,7 @@ $(function() {
681 resp["Upgrade"] == "websocket");
682 BEAST_EXPECT(
683 resp.find("Connection") != resp.end() &&
-
684 resp["Connection"] == "upgrade");
+
684 resp["Connection"] == "Upgrade");
685 }
686
687 void
diff --git a/SociDB_8cpp_source.html b/SociDB_8cpp_source.html index 529ddb34e8..4b4706aa2c 100644 --- a/SociDB_8cpp_source.html +++ b/SociDB_8cpp_source.html @@ -432,7 +432,7 @@ $(function() {
ripple::DBConfig::open
void open(soci::session &s) const
Definition: SociDB.cpp:95
ripple::DBConfig::connectionString
std::string connectionString() const
Definition: SociDB.cpp:89
ripple::JobQueue
A pool of threads to perform work.
Definition: JobQueue.h:58
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
std::string::data
T data(T... args)
std::string::empty
T empty(T... args)
std::vector::end
T end(T... args)
diff --git a/SociDB_8h_source.html b/SociDB_8h_source.html index 9dd16f955b..2ac6747800 100644 --- a/SociDB_8h_source.html +++ b/SociDB_8h_source.html @@ -197,7 +197,7 @@ $(function() {
ripple::DBConfig::connectionString_
std::string connectionString_
Definition: SociDB.h:62
ripple::DBConfig::connectionString
std::string connectionString() const
Definition: SociDB.cpp:89
ripple::JobQueue
A pool of threads to perform work.
Definition: JobQueue.h:58
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
diff --git a/TrustedPublisherServer_8h_source.html b/TrustedPublisherServer_8h_source.html index 4dc4d5ca74..6befdc5f6f 100644 --- a/TrustedPublisherServer_8h_source.html +++ b/TrustedPublisherServer_8h_source.html @@ -111,196 +111,196 @@ $(function() {
33#include <boost/asio.hpp>
34#include <boost/asio/ip/tcp.hpp>
35#include <boost/asio/ssl/stream.hpp>
-
36#include <boost/beast/http.hpp>
-
37#include <boost/beast/ssl.hpp>
-
38#include <boost/beast/version.hpp>
-
39#include <boost/lexical_cast.hpp>
-
40
-
41#include <memory>
-
42#include <thread>
-
43
-
44namespace ripple {
-
45namespace test {
-
46
-
47class TrustedPublisherServer
-
48 : public std::enable_shared_from_this<TrustedPublisherServer>
-
49{
-
50 using endpoint_type = boost::asio::ip::tcp::endpoint;
-
51 using address_type = boost::asio::ip::address;
-
52 using socket_type = boost::asio::ip::tcp::socket;
-
53
-
54 using req_type =
-
55 boost::beast::http::request<boost::beast::http::string_body>;
-
56 using resp_type =
-
57 boost::beast::http::response<boost::beast::http::string_body>;
-
58 using error_code = boost::system::error_code;
-
59
-
60 socket_type sock_;
-
61 endpoint_type ep_;
-
62 boost::asio::ip::tcp::acceptor acceptor_;
-
63 // Generates a version 1 validator list, using the int parameter as the
-
64 // actual version.
-
65 std::function<std::string(int)> getList_;
-
66 // Generates a version 2 validator list, using the int parameter as the
-
67 // actual version.
-
68 std::function<std::string(int)> getList2_;
-
69
-
70 // The SSL context is required, and holds certificates
-
71 bool useSSL_;
-
72 boost::asio::ssl::context sslCtx_{boost::asio::ssl::context::tlsv12};
-
73
-
74 SecretKey publisherSecret_;
-
75 PublicKey publisherPublic_;
-
76
-
77 // Load a signed certificate into the ssl context, and configure
-
78 // the context for use with a server.
-
79 inline void
-
80 load_server_certificate()
-
81 {
-
82 sslCtx_.set_password_callback(
-
83 [](std::size_t, boost::asio::ssl::context_base::password_purpose) {
-
84 return "test";
-
85 });
-
86
-
87 sslCtx_.set_options(
-
88 boost::asio::ssl::context::default_workarounds |
-
89 boost::asio::ssl::context::no_sslv2 |
-
90 boost::asio::ssl::context::single_dh_use);
-
91
-
92 sslCtx_.use_certificate_chain(
-
93 boost::asio::buffer(cert().data(), cert().size()));
-
94
-
95 sslCtx_.use_private_key(
-
96 boost::asio::buffer(key().data(), key().size()),
-
97 boost::asio::ssl::context::file_format::pem);
-
98
-
99 sslCtx_.use_tmp_dh(boost::asio::buffer(dh().data(), dh().size()));
-
100 }
-
101
-
102 struct BlobInfo
-
103 {
-
104 BlobInfo(std::string b, std::string s) : blob(b), signature(s)
-
105 {
-
106 }
-
107
-
108 // base-64 encoded JSON containing the validator list.
-
109 std::string blob;
-
110 // hex-encoded signature of the blob using the publisher's signing key
-
111 std::string signature;
-
112 };
-
113
-
114public:
-
115 struct Validator
-
116 {
-
117 PublicKey masterPublic;
-
118 PublicKey signingPublic;
-
119 std::string manifest;
-
120 };
-
121
-
122 static std::string
-
123 makeManifestString(
-
124 PublicKey const& pk,
-
125 SecretKey const& sk,
-
126 PublicKey const& spk,
-
127 SecretKey const& ssk,
-
128 int seq)
-
129 {
-
130 STObject st(sfGeneric);
-
131 st[sfSequence] = seq;
-
132 st[sfPublicKey] = pk;
-
133 st[sfSigningPubKey] = spk;
-
134
-
135 sign(st, HashPrefix::manifest, *publicKeyType(spk), ssk);
-
136 sign(
-
137 st,
-
138 HashPrefix::manifest,
-
139 *publicKeyType(pk),
-
140 sk,
-
141 sfMasterSignature);
-
142
-
143 Serializer s;
-
144 st.add(s);
-
145
-
146 return base64_encode(
-
147 std::string(static_cast<char const*>(s.data()), s.size()));
-
148 }
-
149
-
150 static Validator
-
151 randomValidator()
-
152 {
-
153 auto const secret = randomSecretKey();
-
154 auto const masterPublic = derivePublicKey(KeyType::ed25519, secret);
-
155 auto const signingKeys = randomKeyPair(KeyType::secp256k1);
-
156 return {
-
157 masterPublic,
-
158 signingKeys.first,
-
159 makeManifestString(
-
160 masterPublic,
-
161 secret,
-
162 signingKeys.first,
-
163 signingKeys.second,
-
164 1)};
-
165 }
-
166
-
167 // TrustedPublisherServer must be accessed through a shared_ptr.
-
168 // This constructor is only public so std::make_shared has access.
-
169 // The function`make_TrustedPublisherServer` should be used to create
-
170 // instances.
-
171 // The `futures` member is expected to be structured as
-
172 // effective / expiration time point pairs for use in version 2 UNLs
-
173 TrustedPublisherServer(
-
174 boost::asio::io_context& ioc,
-
175 std::vector<Validator> const& validators,
-
176 NetClock::time_point validUntil,
-
177 std::vector<
-
178 std::pair<NetClock::time_point, NetClock::time_point>> const&
-
179 futures,
-
180 bool useSSL = false,
-
181 int version = 1,
-
182 bool immediateStart = true,
-
183 int sequence = 1)
-
184 : sock_{ioc}
-
185 , ep_{beast::IP::Address::from_string(
-
186 ripple::test::getEnvLocalhostAddr()),
-
187 // 0 means let OS pick the port based on what's available
-
188 0}
-
189 , acceptor_{ioc}
-
190 , useSSL_{useSSL}
-
191 , publisherSecret_{randomSecretKey()}
-
192 , publisherPublic_{derivePublicKey(KeyType::ed25519, publisherSecret_)}
-
193 {
-
194 auto const keys = randomKeyPair(KeyType::secp256k1);
-
195 auto const manifest = makeManifestString(
-
196 publisherPublic_, publisherSecret_, keys.first, keys.second, 1);
-
197
-
198 std::vector<BlobInfo> blobInfo;
-
199 blobInfo.reserve(futures.size() + 1);
-
200 auto const [data, blob] = [&]() -> std::pair<std::string, std::string> {
-
201 // Builds the validator list, then encodes it into a blob.
-
202 std::string data = "{\"sequence\":" + std::to_string(sequence) +
-
203 ",\"expiration\":" +
-
204 std::to_string(validUntil.time_since_epoch().count()) +
-
205 ",\"validators\":[";
-
206
-
207 for (auto const& val : validators)
-
208 {
-
209 data += "{\"validation_public_key\":\"" +
-
210 strHex(val.masterPublic) + "\",\"manifest\":\"" +
-
211 val.manifest + "\"},";
-
212 }
-
213 data.pop_back();
-
214 data += "]}";
-
215 std::string blob = base64_encode(data);
-
216 return std::make_pair(data, blob);
-
217 }();
-
218 auto const sig = strHex(sign(keys.first, keys.second, makeSlice(data)));
-
219 blobInfo.emplace_back(blob, sig);
-
220 getList_ = [blob = blob, sig, manifest, version](int interval) {
-
221 // Build the contents of a version 1 format UNL file
-
222 std::stringstream l;
-
223 l << "{\"blob\":\"" << blob << "\""
-
224 << ",\"signature\":\"" << sig << "\""
-
225 << ",\"manifest\":\"" << manifest << "\""
+
36#include <boost/beast/core/flat_buffer.hpp>
+
37#include <boost/beast/http.hpp>
+
38#include <boost/beast/ssl.hpp>
+
39#include <boost/beast/version.hpp>
+
40#include <boost/lexical_cast.hpp>
+
41
+
42#include <memory>
+
43#include <thread>
+
44
+
45namespace ripple {
+
46namespace test {
+
47
+
48class TrustedPublisherServer
+
49 : public std::enable_shared_from_this<TrustedPublisherServer>
+
50{
+
51 using endpoint_type = boost::asio::ip::tcp::endpoint;
+
52 using address_type = boost::asio::ip::address;
+
53 using socket_type = boost::asio::ip::tcp::socket;
+
54
+
55 using req_type =
+
56 boost::beast::http::request<boost::beast::http::string_body>;
+
57 using resp_type =
+
58 boost::beast::http::response<boost::beast::http::string_body>;
+
59 using error_code = boost::system::error_code;
+
60
+
61 socket_type sock_;
+
62 endpoint_type ep_;
+
63 boost::asio::ip::tcp::acceptor acceptor_;
+
64 // Generates a version 1 validator list, using the int parameter as the
+
65 // actual version.
+
66 std::function<std::string(int)> getList_;
+
67 // Generates a version 2 validator list, using the int parameter as the
+
68 // actual version.
+
69 std::function<std::string(int)> getList2_;
+
70
+
71 // The SSL context is required, and holds certificates
+
72 bool useSSL_;
+
73 boost::asio::ssl::context sslCtx_{boost::asio::ssl::context::tlsv12};
+
74
+
75 SecretKey publisherSecret_;
+
76 PublicKey publisherPublic_;
+
77
+
78 // Load a signed certificate into the ssl context, and configure
+
79 // the context for use with a server.
+
80 inline void
+
81 load_server_certificate()
+
82 {
+
83 sslCtx_.set_password_callback(
+
84 [](std::size_t, boost::asio::ssl::context_base::password_purpose) {
+
85 return "test";
+
86 });
+
87
+
88 sslCtx_.set_options(
+
89 boost::asio::ssl::context::default_workarounds |
+
90 boost::asio::ssl::context::no_sslv2 |
+
91 boost::asio::ssl::context::single_dh_use);
+
92
+
93 sslCtx_.use_certificate_chain(
+
94 boost::asio::buffer(cert().data(), cert().size()));
+
95
+
96 sslCtx_.use_private_key(
+
97 boost::asio::buffer(key().data(), key().size()),
+
98 boost::asio::ssl::context::file_format::pem);
+
99
+
100 sslCtx_.use_tmp_dh(boost::asio::buffer(dh().data(), dh().size()));
+
101 }
+
102
+
103 struct BlobInfo
+
104 {
+
105 BlobInfo(std::string b, std::string s) : blob(b), signature(s)
+
106 {
+
107 }
+
108
+
109 // base-64 encoded JSON containing the validator list.
+
110 std::string blob;
+
111 // hex-encoded signature of the blob using the publisher's signing key
+
112 std::string signature;
+
113 };
+
114
+
115public:
+
116 struct Validator
+
117 {
+
118 PublicKey masterPublic;
+
119 PublicKey signingPublic;
+
120 std::string manifest;
+
121 };
+
122
+
123 static std::string
+
124 makeManifestString(
+
125 PublicKey const& pk,
+
126 SecretKey const& sk,
+
127 PublicKey const& spk,
+
128 SecretKey const& ssk,
+
129 int seq)
+
130 {
+
131 STObject st(sfGeneric);
+
132 st[sfSequence] = seq;
+
133 st[sfPublicKey] = pk;
+
134 st[sfSigningPubKey] = spk;
+
135
+
136 sign(st, HashPrefix::manifest, *publicKeyType(spk), ssk);
+
137 sign(
+
138 st,
+
139 HashPrefix::manifest,
+
140 *publicKeyType(pk),
+
141 sk,
+
142 sfMasterSignature);
+
143
+
144 Serializer s;
+
145 st.add(s);
+
146
+
147 return base64_encode(
+
148 std::string(static_cast<char const*>(s.data()), s.size()));
+
149 }
+
150
+
151 static Validator
+
152 randomValidator()
+
153 {
+
154 auto const secret = randomSecretKey();
+
155 auto const masterPublic = derivePublicKey(KeyType::ed25519, secret);
+
156 auto const signingKeys = randomKeyPair(KeyType::secp256k1);
+
157 return {
+
158 masterPublic,
+
159 signingKeys.first,
+
160 makeManifestString(
+
161 masterPublic,
+
162 secret,
+
163 signingKeys.first,
+
164 signingKeys.second,
+
165 1)};
+
166 }
+
167
+
168 // TrustedPublisherServer must be accessed through a shared_ptr.
+
169 // This constructor is only public so std::make_shared has access.
+
170 // The function`make_TrustedPublisherServer` should be used to create
+
171 // instances.
+
172 // The `futures` member is expected to be structured as
+
173 // effective / expiration time point pairs for use in version 2 UNLs
+
174 TrustedPublisherServer(
+
175 boost::asio::io_context& ioc,
+
176 std::vector<Validator> const& validators,
+
177 NetClock::time_point validUntil,
+
178 std::vector<
+
179 std::pair<NetClock::time_point, NetClock::time_point>> const&
+
180 futures,
+
181 bool useSSL = false,
+
182 int version = 1,
+
183 bool immediateStart = true,
+
184 int sequence = 1)
+
185 : sock_{ioc}
+
186 , ep_{beast::IP::Address::from_string(
+
187 ripple::test::getEnvLocalhostAddr()),
+
188 // 0 means let OS pick the port based on what's available
+
189 0}
+
190 , acceptor_{ioc}
+
191 , useSSL_{useSSL}
+
192 , publisherSecret_{randomSecretKey()}
+
193 , publisherPublic_{derivePublicKey(KeyType::ed25519, publisherSecret_)}
+
194 {
+
195 auto const keys = randomKeyPair(KeyType::secp256k1);
+
196 auto const manifest = makeManifestString(
+
197 publisherPublic_, publisherSecret_, keys.first, keys.second, 1);
+
198
+
199 std::vector<BlobInfo> blobInfo;
+
200 blobInfo.reserve(futures.size() + 1);
+
201 auto const [data, blob] = [&]() -> std::pair<std::string, std::string> {
+
202 // Builds the validator list, then encodes it into a blob.
+
203 std::string data = "{\"sequence\":" + std::to_string(sequence) +
+
204 ",\"expiration\":" +
+
205 std::to_string(validUntil.time_since_epoch().count()) +
+
206 ",\"validators\":[";
+
207
+
208 for (auto const& val : validators)
+
209 {
+
210 data += "{\"validation_public_key\":\"" +
+
211 strHex(val.masterPublic) + "\",\"manifest\":\"" +
+
212 val.manifest + "\"},";
+
213 }
+
214 data.pop_back();
+
215 data += "]}";
+
216 std::string blob = base64_encode(data);
+
217 return std::make_pair(data, blob);
+
218 }();
+
219 auto const sig = strHex(sign(keys.first, keys.second, makeSlice(data)));
+
220 blobInfo.emplace_back(blob, sig);
+
221 getList_ = [blob = blob, sig, manifest, version](int interval) {
+
222 // Build the contents of a version 1 format UNL file
+
223 std::stringstream l;
+
224 l << "{\"blob\":\"" << blob << "\"" << ",\"signature\":\"" << sig
+
225 << "\"" << ",\"manifest\":\"" << manifest << "\""
226 << ",\"refresh_interval\": " << interval
227 << ",\"version\":" << version << '}';
228 return l.str();
@@ -335,486 +335,485 @@ $(function() {
257 std::stringstream l;
258 for (auto const& info : blobInfo)
259 {
-
260 l << "{\"blob\":\"" << info.blob << "\""
-
261 << ",\"signature\":\"" << info.signature << "\"},";
+
260 l << "{\"blob\":\"" << info.blob << "\"" << ",\"signature\":\""
+
261 << info.signature << "\"},";
262 }
263 std::string blobs = l.str();
264 blobs.pop_back();
265 l.str(std::string());
266 l << "{\"blobs_v2\": [ " << blobs << "],\"manifest\":\"" << manifest
-
267 << "\""
-
268 << ",\"refresh_interval\": " << interval
-
269 << ",\"version\":" << (version + 1) << '}';
-
270 return l.str();
-
271 };
-
272
-
273 if (useSSL_)
-
274 {
-
275 // This holds the self-signed certificate used by the server
-
276 load_server_certificate();
-
277 }
-
278 }
-
279
-
280 void
-
281 start()
-
282 {
-
283 error_code ec;
-
284 acceptor_.open(ep_.protocol());
-
285 acceptor_.set_option(
-
286 boost::asio::ip::tcp::acceptor::reuse_address(true), ec);
-
287 acceptor_.bind(ep_);
-
288 acceptor_.listen(boost::asio::socket_base::max_connections);
-
289 acceptor_.async_accept(
-
290 sock_,
-
291 [wp = std::weak_ptr<TrustedPublisherServer>{shared_from_this()}](
-
292 error_code ec) {
-
293 if (auto p = wp.lock())
-
294 {
-
295 p->on_accept(ec);
-
296 }
-
297 });
-
298 }
-
299
-
300 void
-
301 stop()
-
302 {
-
303 error_code ec;
-
304 acceptor_.close(ec);
-
305 // TODO consider making this join
-
306 // any running do_peer threads
-
307 }
-
308
-
309 ~TrustedPublisherServer()
-
310 {
-
311 stop();
-
312 }
-
313
-
314 endpoint_type
-
315 local_endpoint() const
-
316 {
-
317 return acceptor_.local_endpoint();
-
318 }
-
319
-
320 PublicKey const&
-
321 publisherPublic() const
-
322 {
-
323 return publisherPublic_;
-
324 }
-
325
-
326 /* CA/self-signed certs :
-
327 *
-
328 * The following three methods return certs/keys used by
-
329 * server and/or client to do the SSL handshake. These strings
-
330 * were generated using the script below. The server key and cert
-
331 * are used to configure the server (see load_server_certificate
-
332 * above). The ca.crt should be used to configure the client
-
333 * when ssl verification is enabled.
-
334 *
-
335 * note:
-
336 * cert() ==> server.crt
-
337 * key() ==> server.key
-
338 * ca_cert() ==> ca.crt
-
339 * dh() ==> dh.pem
-
340 ```
-
341 #!/usr/bin/env bash
-
342
-
343 mkdir -p /tmp/__certs__
-
344 pushd /tmp/__certs__
-
345 rm *.crt *.key *.pem
-
346
-
347 # generate CA
-
348 openssl genrsa -out ca.key 2048
-
349 openssl req -new -x509 -nodes -days 10000 -key ca.key -out ca.crt \
-
350 -subj "/C=US/ST=CA/L=Los
-
351 Angeles/O=rippled-unit-tests/CN=example.com" # generate private cert
-
352 openssl genrsa -out server.key 2048
-
353 # Generate certificate signing request
-
354 # since our unit tests can run in either ipv4 or ipv6 mode,
-
355 # we need to use extensions (subjectAltName) so that we can
-
356 # associate both ipv4 and ipv6 localhost addresses with this cert
-
357 cat >"extras.cnf" <<EOF
-
358 [req]
-
359 req_extensions = v3_req
-
360 distinguished_name = req_distinguished_name
-
361
-
362 [req_distinguished_name]
-
363
-
364 [v3_req]
-
365 subjectAltName = @alt_names
-
366
-
367 [alt_names]
-
368 DNS.1 = localhost
-
369 IP.1 = ::1
-
370 EOF
-
371 openssl req -new -key server.key -out server.csr \
-
372 -config extras.cnf \
-
373 -subj "/C=US/ST=California/L=San
-
374 Francisco/O=rippled-unit-tests/CN=127.0.0.1" \
-
375
-
376 # Create public certificate by signing with our CA
-
377 openssl x509 -req -days 10000 -in server.csr -CA ca.crt -CAkey ca.key
-
378 -out server.crt \ -extfile extras.cnf -set_serial 01 -extensions v3_req
-
379
-
380 # generate DH params for server
-
381 openssl dhparam -out dh.pem 2048
-
382 # verify certs
-
383 openssl verify -CAfile ca.crt server.crt
-
384 openssl x509 -in server.crt -text -noout
-
385 popd
-
386 ```
-
387 */
-
388 static std::string const&
-
389 cert()
-
390 {
-
391 static std::string const cert{R"cert(
-
392-----BEGIN CERTIFICATE-----
-
393MIIDczCCAlugAwIBAgIBATANBgkqhkiG9w0BAQsFADBjMQswCQYDVQQGEwJVUzEL
-
394MAkGA1UECAwCQ0ExFDASBgNVBAcMC0xvcyBBbmdlbGVzMRswGQYDVQQKDBJyaXBw
-
395bGVkLXVuaXQtdGVzdHMxFDASBgNVBAMMC2V4YW1wbGUuY29tMB4XDTIyMDIwNTIz
-
396NDk0M1oXDTQ5MDYyMzIzNDk0M1owazELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNh
-
397bGlmb3JuaWExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xGzAZBgNVBAoMEnJpcHBs
-
398ZWQtdW5pdC10ZXN0czESMBAGA1UEAwwJMTI3LjAuMC4xMIIBIjANBgkqhkiG9w0B
-
399AQEFAAOCAQ8AMIIBCgKCAQEAueZ1hgRxwPgfeVx2AdngUYx7zYcaxcGYXyqi7izJ
-
400qTuBUcVcTRC/9Ip67RAEhfcgGudRS/a4Sv1ljwiRknSCcD/ZjzOFDLgbqYGSZNEs
-
401+T/qkwmc/L+Pbzf85HM7RjeGOd6NDQy9+oOBbUtqpTxcSGa4ln+YBFUSeoS1Aa9f
-
402n9vrxnWX9LgTu5dSWzH5TqFIti+Zs/v0PFjEivBIAOHPslmnzg/wCr99I6z9CAR3
-
403zVDe7+sxR//ivpeVE7FWjgkGixnUpZAqn69zNkJjMLNXETgOYskZdMIgbVOMr+0q
-
404S1Uj77mhwxKfpnB6TqUVvWLBvmBDzPjf0m0NcCf9UAjqPwIDAQABoyowKDAmBgNV
-
405HREEHzAdgglsb2NhbGhvc3SHEAAAAAAAAAAAAAAAAAAAAAEwDQYJKoZIhvcNAQEL
-
406BQADggEBAJkUFNS0CeEAKvo0ttzooXnCDH3esj2fwmLJQYLUGsAF8DFrFHTqZEcx
-
407hFRdr0ftEb/VKpV9dVF6xtSoMU56kHOnhbHEWADyqdKUkCDjrGBet5QdWmEwNV2L
-
408nYrwGQBAybMt/+1XMUV8HeLFJNHnyxfQYcW0fUsrmNGk8W0kzWuuq88qbhfXZAIx
-
409KiXrzYpLlM0RlpWXRfYQ6mTdSrRrLnEo5MklizVgNB8HYX78lxa06zP08oReQcfT
-
410GSGO8NEEq8BTVmp69zD1JyfvQcXzsi7WtkAX+/EOFZ7LesnZ6VsyjZ74wECCaQuD
-
411X1yu/XxHqchM+DOzzVw6wRKaM7Zsk80=
-
412-----END CERTIFICATE-----
-
413)cert"};
-
414 return cert;
-
415 }
-
416
-
417 static std::string const&
-
418 key()
-
419 {
-
420 static std::string const key{R"pkey(
-
421-----BEGIN RSA PRIVATE KEY-----
-
422MIIEpAIBAAKCAQEAueZ1hgRxwPgfeVx2AdngUYx7zYcaxcGYXyqi7izJqTuBUcVc
-
423TRC/9Ip67RAEhfcgGudRS/a4Sv1ljwiRknSCcD/ZjzOFDLgbqYGSZNEs+T/qkwmc
-
424/L+Pbzf85HM7RjeGOd6NDQy9+oOBbUtqpTxcSGa4ln+YBFUSeoS1Aa9fn9vrxnWX
-
4259LgTu5dSWzH5TqFIti+Zs/v0PFjEivBIAOHPslmnzg/wCr99I6z9CAR3zVDe7+sx
-
426R//ivpeVE7FWjgkGixnUpZAqn69zNkJjMLNXETgOYskZdMIgbVOMr+0qS1Uj77mh
-
427wxKfpnB6TqUVvWLBvmBDzPjf0m0NcCf9UAjqPwIDAQABAoIBAEC9MDpOu+quvg8+
-
428kt4MKSFdIhQuM7WguNaTe5AkSspDrcJzT7SK275mp259QIYCzMxxuA8TSZTb8A1C
-
429t6dgKbi7k6FaGMCYMRHzzK6NZfMbPi6cj245q9LYlZpdQswuM/FdPpPH1zUxrNYK
-
430CIaooZ6ZHzlSD/eaRMgkBQEkONHrZZtEinLIvKedwssPCaXkIISmt7MFQTDOlxkf
-
431K0Mt1mnRREPYbYSfPEEfIyy/KDIiB5AzgGt+uPOn8Oeb1pSqy69jpYcfhSj+bo4S
-
432UV6qTuTfBd4qkkNI6d/Z7DcDJFFlfloG/vVgGk/beWNnL2e39vzxiebB3w+MQn4F
-
433Wyx5mCECgYEA22z1/ihqt9LIAWtP42oSS3S/RxlFzpp5d7QfNqFnEoVgeRhQzleP
-
434pRJIzVXpMYBxexZYqZA/q8xBSggz+2gmRoYnW20VIzl14DsSH378ye3FRwJB0tLy
-
435dWU8DC7ZB5XQCTvI9UY3voJNToknODw7RCNO1h3V3T1y6JRLdcLskk8CgYEA2OLy
-
436aE5bvsUaLBSv7W9NFhSuZ0p9Y0pFmRgHI7g8i/AgRZ0BgiE8u8OZSHmPJPMaNs/h
-
437YIEIrlsgDci1PzwrUYseRp/aiVE1kyev09/ihqRXTPpLQu6h/d63KRe/06W3t5X3
-
438Dmfj49hH5zGPBI/0y1ECV/n0fwnRhxSv7fNr3RECgYBEuFpOUAAkNApZj29ErNqv
-
4398Q9ayAp5yx1RpQLFjEUIoub05e2gwgGF1DUiwc43p59iyjvYVwnp1x13fxwwl4yt
-
440N6Sp2H7vOja1lCp33MB0yVeohodw7InsxFjLA/0KiBvQWH32exhIPOzTNNcooIx7
-
441KYeuPUfWc0FCn/cGGZcXtwKBgQC1hp1k99CKBuY05suoanOWe5DNGud/ZvaBgD7Z
-
442gqYKadxY52QPyknOzZNJuZQ5VM8n+S2lW9osNFDLuKUaW/3Vrh6U9c4vCC1TEPB0
-
4434PnzvzDiWMsNJjWnCfU7C4meVyFBIt84y3NNjAQCWNRe+S3lzdOsVqRwf4NDD+l/
-
444uzEYQQKBgQCJczIlwobm1Y6O41hbGZhZL/CGMNS6Z0INi2yasV0WDqYlh7XayHMD
-
445cK55dMILcbHqeIBq/wR6sIhw6IJcaDBfFfrJiKKDilfij2lHxR2FQrEngtTCCRV+
-
446ZzARzaWhQPvbDqEtLJDWuXZNXfL8/PTIs5NmuKuQ8F4+gQJpkQgwaw==
-
447-----END RSA PRIVATE KEY-----
-
448)pkey"};
-
449 return key;
-
450 }
-
451
-
452 static std::string const&
-
453 ca_cert()
-
454 {
-
455 static std::string const cert{R"cert(
-
456-----BEGIN CERTIFICATE-----
-
457MIIDpzCCAo+gAwIBAgIUWc45WqaaNuaSLoFYTMC/Mjfqw/gwDQYJKoZIhvcNAQEL
-
458BQAwYzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQHDAtMb3MgQW5n
-
459ZWxlczEbMBkGA1UECgwScmlwcGxlZC11bml0LXRlc3RzMRQwEgYDVQQDDAtleGFt
-
460cGxlLmNvbTAeFw0yMjAyMDUyMzQ5MDFaFw00OTA2MjMyMzQ5MDFaMGMxCzAJBgNV
-
461BAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UEBwwLTG9zIEFuZ2VsZXMxGzAZBgNV
-
462BAoMEnJpcHBsZWQtdW5pdC10ZXN0czEUMBIGA1UEAwwLZXhhbXBsZS5jb20wggEi
-
463MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0f2JBW2XNW2wT5/ajX2qxmUY+
-
464aNJGfpV6gZ5CmwdQpbHrPPvJoskxwsCyr3GifzT/GtCpmb1fiu59uUAPxQEYCxiq
-
465V+HchX4g4Vl27xKJ0P+usxuEED9v7TCteKum9u9eMZ8UDF0fspXcnWGs9fXlyoTj
-
466uTRP1SBQllk44DPc/KzlrtH+QNXmr9XQnP8XvwWCgJXMx87voxEGiFFOVhkSSAOv
-
467v+OUGgEuq0NPgwv2LHBlYHSdkoU9F5Z/TmkCAFMShbyoUjldIz2gcWXjN2tespGo
-
468D6qYvasvPIpmcholBBkc0z8QDt+RNq+Wzrults7epJXy/u+txGK9cHCNlLCpAgMB
-
469AAGjUzBRMB0GA1UdDgQWBBS1oydh+YyqDNOFKYOvOtVMWKqV4zAfBgNVHSMEGDAW
-
470gBS1oydh+YyqDNOFKYOvOtVMWKqV4zAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3
-
471DQEBCwUAA4IBAQCDPyGKQwQ8Lz0yEgvIl/Uo9BtwAzlvjrLM/39qhStLQqDGSs2Q
-
472xFIbtjzjuLf5vR3q6OJ62CCvzqXgHkJ+hzVN/tAvyliGTdjJrK+xv1M5a+XipO2f
-
473c9lb4gRbFL/DyoeoWgb1Rkv3gFf0FlCYH+ZUcYb9ZYCRlGtFgOcxJI2g+T7jSLFp
-
4748+hSzQ6W5Sp9L6b5iJyCww1vjBvBqzNyZMNeB4gXGtd6z9vMDSvKboTdGD7wcFB+
-
475mRMyNekaRw+Npy4Hjou5sx272cXHHmPCSF5TjwdaibSaGjx1k0Q50mOf7S9KG5b5
-
4767X1e3FekJlaD02EBEhtkXURIxogOQALdFncj
-
477-----END CERTIFICATE-----
-
478)cert"};
-
479 return cert;
-
480 }
-
481
-
482 static std::string const&
-
483 dh()
-
484 {
-
485 static std::string const dh{R"dh(
-
486-----BEGIN DH PARAMETERS-----
-
487MIIBCAKCAQEAp2I2fWEUZ3sCNfitSRC/MdAhJE/bS+NO0O2tWdIdlvmIFE6B5qhC
-
488sGW9ojrQT8DTxBvGAcbjr/jagmlE3BV4oSnxyhP37G2mDvMOJ29J3NvFD/ZFAW0d
-
489BvZJ1RNvMu29NmVCyt6/jgzcqrqnami9uD93aK+zaVrlPsPEYM8xB19HXwqsEYCL
-
490ux2B7sqXm9Ts74HPg/EV+pcVon9phxNWxxgHlOvFc2QjZ3hXH++kzmJ4vs7N/XDB
-
491xbEQ+TUZ5jbJGSeBqNFKFeuOUQGJ46Io0jBSYd4rSmKUXkvElQwR+n7KF3jy1uAt
-
492/8hzd8tHn9TyW7Q2/CPkOA6dCXzltpOSowIBAg==
-
493-----END DH PARAMETERS-----
-
494)dh"};
-
495 return dh;
-
496 }
-
497
-
498private:
-
499 struct lambda
-
500 {
-
501 int id;
-
502 TrustedPublisherServer& self;
-
503 socket_type sock;
-
504 boost::asio::executor_work_guard<boost::asio::executor> work;
-
505 bool ssl;
-
506
-
507 lambda(
-
508 int id_,
-
509 TrustedPublisherServer& self_,
-
510 socket_type&& sock_,
-
511 bool ssl_)
-
512 : id(id_)
-
513 , self(self_)
-
514 , sock(std::move(sock_))
-
515 , work(sock_.get_executor())
-
516 , ssl(ssl_)
-
517 {
-
518 }
-
519
-
520 void
-
521 operator()()
-
522 {
-
523 self.do_peer(id, std::move(sock), ssl);
-
524 }
-
525 };
-
526
-
527 void
-
528 on_accept(error_code ec)
-
529 {
-
530 if (ec || !acceptor_.is_open())
-
531 return;
-
532
-
533 static int id_ = 0;
-
534 std::thread{lambda{++id_, *this, std::move(sock_), useSSL_}}.detach();
-
535 acceptor_.async_accept(
-
536 sock_,
-
537 [wp = std::weak_ptr<TrustedPublisherServer>{shared_from_this()}](
-
538 error_code ec) {
-
539 if (auto p = wp.lock())
-
540 {
-
541 p->on_accept(ec);
-
542 }
-
543 });
-
544 }
-
545
-
546 void
-
547 do_peer(int id, socket_type&& s, bool ssl)
-
548 {
-
549 using namespace boost::beast;
-
550 using namespace boost::asio;
-
551 socket_type sock(std::move(s));
-
552 flat_buffer sb;
-
553 error_code ec;
-
554 std::optional<ssl_stream<ip::tcp::socket&>> ssl_stream;
-
555
-
556 if (ssl)
-
557 {
-
558 // Construct the stream around the socket
-
559 ssl_stream.emplace(sock, sslCtx_);
-
560 // Perform the SSL handshake
-
561 ssl_stream->handshake(ssl::stream_base::server, ec);
-
562 if (ec)
-
563 return;
-
564 }
-
565
-
566 for (;;)
-
567 {
-
568 resp_type res;
-
569 req_type req;
-
570 try
-
571 {
-
572 if (ssl)
-
573 http::read(*ssl_stream, sb, req, ec);
-
574 else
-
575 http::read(sock, sb, req, ec);
-
576
-
577 if (ec)
-
578 break;
-
579
-
580 std::string_view const path = req.target();
-
581 res.insert("Server", "TrustedPublisherServer");
-
582 res.version(req.version());
-
583 res.keep_alive(req.keep_alive());
-
584 bool prepare = true;
-
585
-
586 if (boost::starts_with(path, "/validators2"))
-
587 {
-
588 res.result(http::status::ok);
-
589 res.insert("Content-Type", "application/json");
-
590 if (path == "/validators2/bad")
-
591 res.body() = "{ 'bad': \"2']";
-
592 else if (path == "/validators2/missing")
-
593 res.body() = "{\"version\": 2}";
-
594 else
-
595 {
-
596 int refresh = 5;
-
597 constexpr char const* refreshPrefix =
-
598 "/validators2/refresh/";
-
599 if (boost::starts_with(path, refreshPrefix))
-
600 refresh = boost::lexical_cast<unsigned int>(
-
601 path.substr(strlen(refreshPrefix)));
-
602 res.body() = getList2_(refresh);
-
603 }
-
604 }
-
605 else if (boost::starts_with(path, "/validators"))
-
606 {
-
607 res.result(http::status::ok);
-
608 res.insert("Content-Type", "application/json");
-
609 if (path == "/validators/bad")
-
610 res.body() = "{ 'bad': \"1']";
-
611 else if (path == "/validators/missing")
-
612 res.body() = "{\"version\": 1}";
-
613 else
-
614 {
-
615 int refresh = 5;
-
616 constexpr char const* refreshPrefix =
-
617 "/validators/refresh/";
-
618 if (boost::starts_with(path, refreshPrefix))
-
619 refresh = boost::lexical_cast<unsigned int>(
-
620 path.substr(strlen(refreshPrefix)));
-
621 res.body() = getList_(refresh);
-
622 }
-
623 }
-
624 else if (boost::starts_with(path, "/textfile"))
-
625 {
-
626 prepare = false;
-
627 res.result(http::status::ok);
-
628 res.insert("Content-Type", "text/example");
-
629 // if huge was requested, lie about content length
-
630 std::uint64_t cl =
-
631 boost::starts_with(path, "/textfile/huge")
-
632 ? std::numeric_limits<uint64_t>::max()
-
633 : 1024;
-
634 res.content_length(cl);
-
635 if (req.method() == http::verb::get)
-
636 {
-
637 std::stringstream body;
-
638 for (auto i = 0; i < 1024; ++i)
-
639 body << static_cast<char>(rand_int<short>(32, 126)),
-
640 res.body() = body.str();
-
641 }
-
642 }
-
643 else if (boost::starts_with(path, "/sleep/"))
-
644 {
-
645 auto const sleep_sec =
-
646 boost::lexical_cast<unsigned int>(path.substr(7));
-
647 std::this_thread::sleep_for(
-
648 std::chrono::seconds(sleep_sec));
-
649 }
-
650 else if (boost::starts_with(path, "/redirect"))
-
651 {
-
652 if (boost::ends_with(path, "/301"))
-
653 res.result(http::status::moved_permanently);
-
654 else if (boost::ends_with(path, "/302"))
-
655 res.result(http::status::found);
-
656 else if (boost::ends_with(path, "/307"))
-
657 res.result(http::status::temporary_redirect);
-
658 else if (boost::ends_with(path, "/308"))
-
659 res.result(http::status::permanent_redirect);
-
660
-
661 std::stringstream location;
-
662 if (boost::starts_with(path, "/redirect_to/"))
-
663 {
-
664 location << path.substr(13);
-
665 }
-
666 else if (!boost::starts_with(path, "/redirect_nolo"))
-
667 {
-
668 location
-
669 << (ssl ? "https://" : "http://")
-
670 << local_endpoint()
-
671 << (boost::starts_with(path, "/redirect_forever/")
-
672 ? path
-
673 : "/validators");
-
674 }
-
675 if (!location.str().empty())
-
676 res.insert("Location", location.str());
-
677 }
-
678 else
-
679 {
-
680 // unknown request
-
681 res.result(boost::beast::http::status::not_found);
-
682 res.insert("Content-Type", "text/html");
-
683 res.body() = "The file '" + std::string(path) +
-
684 "' was not "
-
685 "found";
-
686 }
-
687
-
688 if (prepare)
-
689 res.prepare_payload();
-
690 }
-
691 catch (std::exception const& e)
-
692 {
-
693 res = {};
-
694 res.result(boost::beast::http::status::internal_server_error);
-
695 res.version(req.version());
-
696 res.insert("Server", "TrustedPublisherServer");
-
697 res.insert("Content-Type", "text/html");
-
698 res.body() =
-
699 std::string{"An internal error occurred"} + e.what();
-
700 res.prepare_payload();
-
701 }
-
702
-
703 if (ssl)
-
704 write(*ssl_stream, res, ec);
-
705 else
-
706 write(sock, res, ec);
-
707
-
708 if (ec || req.need_eof())
-
709 break;
-
710 }
-
711
-
712 // Perform the SSL shutdown
-
713 if (ssl)
-
714 ssl_stream->shutdown(ec);
-
715 }
-
716};
-
717
-
718inline std::shared_ptr<TrustedPublisherServer>
-
719make_TrustedPublisherServer(
-
720 boost::asio::io_context& ioc,
-
721 std::vector<TrustedPublisherServer::Validator> const& validators,
-
722 NetClock::time_point validUntil,
-
723 std::vector<std::pair<NetClock::time_point, NetClock::time_point>> const&
-
724 futures,
-
725 bool useSSL = false,
-
726 int version = 1,
-
727 bool immediateStart = true,
-
728 int sequence = 1)
-
729{
-
730 auto const r = std::make_shared<TrustedPublisherServer>(
-
731 ioc, validators, validUntil, futures, useSSL, version, sequence);
-
732 if (immediateStart)
-
733 r->start();
-
734 return r;
-
735}
-
736
-
737} // namespace test
-
738} // namespace ripple
-
739#endif
+
267 << "\"" << ",\"refresh_interval\": " << interval
+
268 << ",\"version\":" << (version + 1) << '}';
+
269 return l.str();
+
270 };
+
271
+
272 if (useSSL_)
+
273 {
+
274 // This holds the self-signed certificate used by the server
+
275 load_server_certificate();
+
276 }
+
277 }
+
278
+
279 void
+
280 start()
+
281 {
+
282 error_code ec;
+
283 acceptor_.open(ep_.protocol());
+
284 acceptor_.set_option(
+
285 boost::asio::ip::tcp::acceptor::reuse_address(true), ec);
+
286 acceptor_.bind(ep_);
+
287 acceptor_.listen(boost::asio::socket_base::max_connections);
+
288 acceptor_.async_accept(
+
289 sock_,
+
290 [wp = std::weak_ptr<TrustedPublisherServer>{shared_from_this()}](
+
291 error_code ec) {
+
292 if (auto p = wp.lock())
+
293 {
+
294 p->on_accept(ec);
+
295 }
+
296 });
+
297 }
+
298
+
299 void
+
300 stop()
+
301 {
+
302 error_code ec;
+
303 acceptor_.close(ec);
+
304 // TODO consider making this join
+
305 // any running do_peer threads
+
306 }
+
307
+
308 ~TrustedPublisherServer()
+
309 {
+
310 stop();
+
311 }
+
312
+
313 endpoint_type
+
314 local_endpoint() const
+
315 {
+
316 return acceptor_.local_endpoint();
+
317 }
+
318
+
319 PublicKey const&
+
320 publisherPublic() const
+
321 {
+
322 return publisherPublic_;
+
323 }
+
324
+
325 /* CA/self-signed certs :
+
326 *
+
327 * The following three methods return certs/keys used by
+
328 * server and/or client to do the SSL handshake. These strings
+
329 * were generated using the script below. The server key and cert
+
330 * are used to configure the server (see load_server_certificate
+
331 * above). The ca.crt should be used to configure the client
+
332 * when ssl verification is enabled.
+
333 *
+
334 * note:
+
335 * cert() ==> server.crt
+
336 * key() ==> server.key
+
337 * ca_cert() ==> ca.crt
+
338 * dh() ==> dh.pem
+
339 ```
+
340 #!/usr/bin/env bash
+
341
+
342 mkdir -p /tmp/__certs__
+
343 pushd /tmp/__certs__
+
344 rm *.crt *.key *.pem
+
345
+
346 # generate CA
+
347 openssl genrsa -out ca.key 2048
+
348 openssl req -new -x509 -nodes -days 10000 -key ca.key -out ca.crt \
+
349 -subj "/C=US/ST=CA/L=Los
+
350 Angeles/O=rippled-unit-tests/CN=example.com" # generate private cert
+
351 openssl genrsa -out server.key 2048
+
352 # Generate certificate signing request
+
353 # since our unit tests can run in either ipv4 or ipv6 mode,
+
354 # we need to use extensions (subjectAltName) so that we can
+
355 # associate both ipv4 and ipv6 localhost addresses with this cert
+
356 cat >"extras.cnf" <<EOF
+
357 [req]
+
358 req_extensions = v3_req
+
359 distinguished_name = req_distinguished_name
+
360
+
361 [req_distinguished_name]
+
362
+
363 [v3_req]
+
364 subjectAltName = @alt_names
+
365
+
366 [alt_names]
+
367 DNS.1 = localhost
+
368 IP.1 = ::1
+
369 EOF
+
370 openssl req -new -key server.key -out server.csr \
+
371 -config extras.cnf \
+
372 -subj "/C=US/ST=California/L=San
+
373 Francisco/O=rippled-unit-tests/CN=127.0.0.1" \
+
374
+
375 # Create public certificate by signing with our CA
+
376 openssl x509 -req -days 10000 -in server.csr -CA ca.crt -CAkey ca.key
+
377 -out server.crt \ -extfile extras.cnf -set_serial 01 -extensions v3_req
+
378
+
379 # generate DH params for server
+
380 openssl dhparam -out dh.pem 2048
+
381 # verify certs
+
382 openssl verify -CAfile ca.crt server.crt
+
383 openssl x509 -in server.crt -text -noout
+
384 popd
+
385 ```
+
386 */
+
387 static std::string const&
+
388 cert()
+
389 {
+
390 static std::string const cert{R"cert(
+
391-----BEGIN CERTIFICATE-----
+
392MIIDczCCAlugAwIBAgIBATANBgkqhkiG9w0BAQsFADBjMQswCQYDVQQGEwJVUzEL
+
393MAkGA1UECAwCQ0ExFDASBgNVBAcMC0xvcyBBbmdlbGVzMRswGQYDVQQKDBJyaXBw
+
394bGVkLXVuaXQtdGVzdHMxFDASBgNVBAMMC2V4YW1wbGUuY29tMB4XDTIyMDIwNTIz
+
395NDk0M1oXDTQ5MDYyMzIzNDk0M1owazELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNh
+
396bGlmb3JuaWExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xGzAZBgNVBAoMEnJpcHBs
+
397ZWQtdW5pdC10ZXN0czESMBAGA1UEAwwJMTI3LjAuMC4xMIIBIjANBgkqhkiG9w0B
+
398AQEFAAOCAQ8AMIIBCgKCAQEAueZ1hgRxwPgfeVx2AdngUYx7zYcaxcGYXyqi7izJ
+
399qTuBUcVcTRC/9Ip67RAEhfcgGudRS/a4Sv1ljwiRknSCcD/ZjzOFDLgbqYGSZNEs
+
400+T/qkwmc/L+Pbzf85HM7RjeGOd6NDQy9+oOBbUtqpTxcSGa4ln+YBFUSeoS1Aa9f
+
401n9vrxnWX9LgTu5dSWzH5TqFIti+Zs/v0PFjEivBIAOHPslmnzg/wCr99I6z9CAR3
+
402zVDe7+sxR//ivpeVE7FWjgkGixnUpZAqn69zNkJjMLNXETgOYskZdMIgbVOMr+0q
+
403S1Uj77mhwxKfpnB6TqUVvWLBvmBDzPjf0m0NcCf9UAjqPwIDAQABoyowKDAmBgNV
+
404HREEHzAdgglsb2NhbGhvc3SHEAAAAAAAAAAAAAAAAAAAAAEwDQYJKoZIhvcNAQEL
+
405BQADggEBAJkUFNS0CeEAKvo0ttzooXnCDH3esj2fwmLJQYLUGsAF8DFrFHTqZEcx
+
406hFRdr0ftEb/VKpV9dVF6xtSoMU56kHOnhbHEWADyqdKUkCDjrGBet5QdWmEwNV2L
+
407nYrwGQBAybMt/+1XMUV8HeLFJNHnyxfQYcW0fUsrmNGk8W0kzWuuq88qbhfXZAIx
+
408KiXrzYpLlM0RlpWXRfYQ6mTdSrRrLnEo5MklizVgNB8HYX78lxa06zP08oReQcfT
+
409GSGO8NEEq8BTVmp69zD1JyfvQcXzsi7WtkAX+/EOFZ7LesnZ6VsyjZ74wECCaQuD
+
410X1yu/XxHqchM+DOzzVw6wRKaM7Zsk80=
+
411-----END CERTIFICATE-----
+
412)cert"};
+
413 return cert;
+
414 }
+
415
+
416 static std::string const&
+
417 key()
+
418 {
+
419 static std::string const key{R"pkey(
+
420-----BEGIN RSA PRIVATE KEY-----
+
421MIIEpAIBAAKCAQEAueZ1hgRxwPgfeVx2AdngUYx7zYcaxcGYXyqi7izJqTuBUcVc
+
422TRC/9Ip67RAEhfcgGudRS/a4Sv1ljwiRknSCcD/ZjzOFDLgbqYGSZNEs+T/qkwmc
+
423/L+Pbzf85HM7RjeGOd6NDQy9+oOBbUtqpTxcSGa4ln+YBFUSeoS1Aa9fn9vrxnWX
+
4249LgTu5dSWzH5TqFIti+Zs/v0PFjEivBIAOHPslmnzg/wCr99I6z9CAR3zVDe7+sx
+
425R//ivpeVE7FWjgkGixnUpZAqn69zNkJjMLNXETgOYskZdMIgbVOMr+0qS1Uj77mh
+
426wxKfpnB6TqUVvWLBvmBDzPjf0m0NcCf9UAjqPwIDAQABAoIBAEC9MDpOu+quvg8+
+
427kt4MKSFdIhQuM7WguNaTe5AkSspDrcJzT7SK275mp259QIYCzMxxuA8TSZTb8A1C
+
428t6dgKbi7k6FaGMCYMRHzzK6NZfMbPi6cj245q9LYlZpdQswuM/FdPpPH1zUxrNYK
+
429CIaooZ6ZHzlSD/eaRMgkBQEkONHrZZtEinLIvKedwssPCaXkIISmt7MFQTDOlxkf
+
430K0Mt1mnRREPYbYSfPEEfIyy/KDIiB5AzgGt+uPOn8Oeb1pSqy69jpYcfhSj+bo4S
+
431UV6qTuTfBd4qkkNI6d/Z7DcDJFFlfloG/vVgGk/beWNnL2e39vzxiebB3w+MQn4F
+
432Wyx5mCECgYEA22z1/ihqt9LIAWtP42oSS3S/RxlFzpp5d7QfNqFnEoVgeRhQzleP
+
433pRJIzVXpMYBxexZYqZA/q8xBSggz+2gmRoYnW20VIzl14DsSH378ye3FRwJB0tLy
+
434dWU8DC7ZB5XQCTvI9UY3voJNToknODw7RCNO1h3V3T1y6JRLdcLskk8CgYEA2OLy
+
435aE5bvsUaLBSv7W9NFhSuZ0p9Y0pFmRgHI7g8i/AgRZ0BgiE8u8OZSHmPJPMaNs/h
+
436YIEIrlsgDci1PzwrUYseRp/aiVE1kyev09/ihqRXTPpLQu6h/d63KRe/06W3t5X3
+
437Dmfj49hH5zGPBI/0y1ECV/n0fwnRhxSv7fNr3RECgYBEuFpOUAAkNApZj29ErNqv
+
4388Q9ayAp5yx1RpQLFjEUIoub05e2gwgGF1DUiwc43p59iyjvYVwnp1x13fxwwl4yt
+
439N6Sp2H7vOja1lCp33MB0yVeohodw7InsxFjLA/0KiBvQWH32exhIPOzTNNcooIx7
+
440KYeuPUfWc0FCn/cGGZcXtwKBgQC1hp1k99CKBuY05suoanOWe5DNGud/ZvaBgD7Z
+
441gqYKadxY52QPyknOzZNJuZQ5VM8n+S2lW9osNFDLuKUaW/3Vrh6U9c4vCC1TEPB0
+
4424PnzvzDiWMsNJjWnCfU7C4meVyFBIt84y3NNjAQCWNRe+S3lzdOsVqRwf4NDD+l/
+
443uzEYQQKBgQCJczIlwobm1Y6O41hbGZhZL/CGMNS6Z0INi2yasV0WDqYlh7XayHMD
+
444cK55dMILcbHqeIBq/wR6sIhw6IJcaDBfFfrJiKKDilfij2lHxR2FQrEngtTCCRV+
+
445ZzARzaWhQPvbDqEtLJDWuXZNXfL8/PTIs5NmuKuQ8F4+gQJpkQgwaw==
+
446-----END RSA PRIVATE KEY-----
+
447)pkey"};
+
448 return key;
+
449 }
+
450
+
451 static std::string const&
+
452 ca_cert()
+
453 {
+
454 static std::string const cert{R"cert(
+
455-----BEGIN CERTIFICATE-----
+
456MIIDpzCCAo+gAwIBAgIUWc45WqaaNuaSLoFYTMC/Mjfqw/gwDQYJKoZIhvcNAQEL
+
457BQAwYzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRQwEgYDVQQHDAtMb3MgQW5n
+
458ZWxlczEbMBkGA1UECgwScmlwcGxlZC11bml0LXRlc3RzMRQwEgYDVQQDDAtleGFt
+
459cGxlLmNvbTAeFw0yMjAyMDUyMzQ5MDFaFw00OTA2MjMyMzQ5MDFaMGMxCzAJBgNV
+
460BAYTAlVTMQswCQYDVQQIDAJDQTEUMBIGA1UEBwwLTG9zIEFuZ2VsZXMxGzAZBgNV
+
461BAoMEnJpcHBsZWQtdW5pdC10ZXN0czEUMBIGA1UEAwwLZXhhbXBsZS5jb20wggEi
+
462MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0f2JBW2XNW2wT5/ajX2qxmUY+
+
463aNJGfpV6gZ5CmwdQpbHrPPvJoskxwsCyr3GifzT/GtCpmb1fiu59uUAPxQEYCxiq
+
464V+HchX4g4Vl27xKJ0P+usxuEED9v7TCteKum9u9eMZ8UDF0fspXcnWGs9fXlyoTj
+
465uTRP1SBQllk44DPc/KzlrtH+QNXmr9XQnP8XvwWCgJXMx87voxEGiFFOVhkSSAOv
+
466v+OUGgEuq0NPgwv2LHBlYHSdkoU9F5Z/TmkCAFMShbyoUjldIz2gcWXjN2tespGo
+
467D6qYvasvPIpmcholBBkc0z8QDt+RNq+Wzrults7epJXy/u+txGK9cHCNlLCpAgMB
+
468AAGjUzBRMB0GA1UdDgQWBBS1oydh+YyqDNOFKYOvOtVMWKqV4zAfBgNVHSMEGDAW
+
469gBS1oydh+YyqDNOFKYOvOtVMWKqV4zAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3
+
470DQEBCwUAA4IBAQCDPyGKQwQ8Lz0yEgvIl/Uo9BtwAzlvjrLM/39qhStLQqDGSs2Q
+
471xFIbtjzjuLf5vR3q6OJ62CCvzqXgHkJ+hzVN/tAvyliGTdjJrK+xv1M5a+XipO2f
+
472c9lb4gRbFL/DyoeoWgb1Rkv3gFf0FlCYH+ZUcYb9ZYCRlGtFgOcxJI2g+T7jSLFp
+
4738+hSzQ6W5Sp9L6b5iJyCww1vjBvBqzNyZMNeB4gXGtd6z9vMDSvKboTdGD7wcFB+
+
474mRMyNekaRw+Npy4Hjou5sx272cXHHmPCSF5TjwdaibSaGjx1k0Q50mOf7S9KG5b5
+
4757X1e3FekJlaD02EBEhtkXURIxogOQALdFncj
+
476-----END CERTIFICATE-----
+
477)cert"};
+
478 return cert;
+
479 }
+
480
+
481 static std::string const&
+
482 dh()
+
483 {
+
484 static std::string const dh{R"dh(
+
485-----BEGIN DH PARAMETERS-----
+
486MIIBCAKCAQEAp2I2fWEUZ3sCNfitSRC/MdAhJE/bS+NO0O2tWdIdlvmIFE6B5qhC
+
487sGW9ojrQT8DTxBvGAcbjr/jagmlE3BV4oSnxyhP37G2mDvMOJ29J3NvFD/ZFAW0d
+
488BvZJ1RNvMu29NmVCyt6/jgzcqrqnami9uD93aK+zaVrlPsPEYM8xB19HXwqsEYCL
+
489ux2B7sqXm9Ts74HPg/EV+pcVon9phxNWxxgHlOvFc2QjZ3hXH++kzmJ4vs7N/XDB
+
490xbEQ+TUZ5jbJGSeBqNFKFeuOUQGJ46Io0jBSYd4rSmKUXkvElQwR+n7KF3jy1uAt
+
491/8hzd8tHn9TyW7Q2/CPkOA6dCXzltpOSowIBAg==
+
492-----END DH PARAMETERS-----
+
493)dh"};
+
494 return dh;
+
495 }
+
496
+
497private:
+
498 struct lambda
+
499 {
+
500 int id;
+
501 TrustedPublisherServer& self;
+
502 socket_type sock;
+
503 boost::asio::executor_work_guard<boost::asio::executor> work;
+
504 bool ssl;
+
505
+
506 lambda(
+
507 int id_,
+
508 TrustedPublisherServer& self_,
+
509 socket_type&& sock_,
+
510 bool ssl_)
+
511 : id(id_)
+
512 , self(self_)
+
513 , sock(std::move(sock_))
+
514 , work(sock_.get_executor())
+
515 , ssl(ssl_)
+
516 {
+
517 }
+
518
+
519 void
+
520 operator()()
+
521 {
+
522 self.do_peer(id, std::move(sock), ssl);
+
523 }
+
524 };
+
525
+
526 void
+
527 on_accept(error_code ec)
+
528 {
+
529 if (ec || !acceptor_.is_open())
+
530 return;
+
531
+
532 static int id_ = 0;
+
533 std::thread{lambda{++id_, *this, std::move(sock_), useSSL_}}.detach();
+
534 acceptor_.async_accept(
+
535 sock_,
+
536 [wp = std::weak_ptr<TrustedPublisherServer>{shared_from_this()}](
+
537 error_code ec) {
+
538 if (auto p = wp.lock())
+
539 {
+
540 p->on_accept(ec);
+
541 }
+
542 });
+
543 }
+
544
+
545 void
+
546 do_peer(int id, socket_type&& s, bool ssl)
+
547 {
+
548 using namespace boost::beast;
+
549 using namespace boost::asio;
+
550 socket_type sock(std::move(s));
+
551 flat_buffer sb;
+
552 error_code ec;
+
553 std::optional<ssl_stream<ip::tcp::socket&>> ssl_stream;
+
554
+
555 if (ssl)
+
556 {
+
557 // Construct the stream around the socket
+
558 ssl_stream.emplace(sock, sslCtx_);
+
559 // Perform the SSL handshake
+
560 ssl_stream->handshake(ssl::stream_base::server, ec);
+
561 if (ec)
+
562 return;
+
563 }
+
564
+
565 for (;;)
+
566 {
+
567 resp_type res;
+
568 req_type req;
+
569 try
+
570 {
+
571 if (ssl)
+
572 http::read(*ssl_stream, sb, req, ec);
+
573 else
+
574 http::read(sock, sb, req, ec);
+
575
+
576 if (ec)
+
577 break;
+
578
+
579 std::string_view const path = req.target();
+
580 res.insert("Server", "TrustedPublisherServer");
+
581 res.version(req.version());
+
582 res.keep_alive(req.keep_alive());
+
583 bool prepare = true;
+
584
+
585 if (boost::starts_with(path, "/validators2"))
+
586 {
+
587 res.result(http::status::ok);
+
588 res.insert("Content-Type", "application/json");
+
589 if (path == "/validators2/bad")
+
590 res.body() = "{ 'bad': \"2']";
+
591 else if (path == "/validators2/missing")
+
592 res.body() = "{\"version\": 2}";
+
593 else
+
594 {
+
595 int refresh = 5;
+
596 constexpr char const* refreshPrefix =
+
597 "/validators2/refresh/";
+
598 if (boost::starts_with(path, refreshPrefix))
+
599 refresh = boost::lexical_cast<unsigned int>(
+
600 path.substr(strlen(refreshPrefix)));
+
601 res.body() = getList2_(refresh);
+
602 }
+
603 }
+
604 else if (boost::starts_with(path, "/validators"))
+
605 {
+
606 res.result(http::status::ok);
+
607 res.insert("Content-Type", "application/json");
+
608 if (path == "/validators/bad")
+
609 res.body() = "{ 'bad': \"1']";
+
610 else if (path == "/validators/missing")
+
611 res.body() = "{\"version\": 1}";
+
612 else
+
613 {
+
614 int refresh = 5;
+
615 constexpr char const* refreshPrefix =
+
616 "/validators/refresh/";
+
617 if (boost::starts_with(path, refreshPrefix))
+
618 refresh = boost::lexical_cast<unsigned int>(
+
619 path.substr(strlen(refreshPrefix)));
+
620 res.body() = getList_(refresh);
+
621 }
+
622 }
+
623 else if (boost::starts_with(path, "/textfile"))
+
624 {
+
625 prepare = false;
+
626 res.result(http::status::ok);
+
627 res.insert("Content-Type", "text/example");
+
628 // if huge was requested, lie about content length
+
629 std::uint64_t cl =
+
630 boost::starts_with(path, "/textfile/huge")
+
631 ? std::numeric_limits<uint64_t>::max()
+
632 : 1024;
+
633 res.content_length(cl);
+
634 if (req.method() == http::verb::get)
+
635 {
+
636 std::stringstream body;
+
637 for (auto i = 0; i < 1024; ++i)
+
638 body << static_cast<char>(rand_int<short>(32, 126)),
+
639 res.body() = body.str();
+
640 }
+
641 }
+
642 else if (boost::starts_with(path, "/sleep/"))
+
643 {
+
644 auto const sleep_sec =
+
645 boost::lexical_cast<unsigned int>(path.substr(7));
+
646 std::this_thread::sleep_for(
+
647 std::chrono::seconds(sleep_sec));
+
648 }
+
649 else if (boost::starts_with(path, "/redirect"))
+
650 {
+
651 if (boost::ends_with(path, "/301"))
+
652 res.result(http::status::moved_permanently);
+
653 else if (boost::ends_with(path, "/302"))
+
654 res.result(http::status::found);
+
655 else if (boost::ends_with(path, "/307"))
+
656 res.result(http::status::temporary_redirect);
+
657 else if (boost::ends_with(path, "/308"))
+
658 res.result(http::status::permanent_redirect);
+
659
+
660 std::stringstream location;
+
661 if (boost::starts_with(path, "/redirect_to/"))
+
662 {
+
663 location << path.substr(13);
+
664 }
+
665 else if (!boost::starts_with(path, "/redirect_nolo"))
+
666 {
+
667 location
+
668 << (ssl ? "https://" : "http://")
+
669 << local_endpoint()
+
670 << (boost::starts_with(path, "/redirect_forever/")
+
671 ? path
+
672 : "/validators");
+
673 }
+
674 if (!location.str().empty())
+
675 res.insert("Location", location.str());
+
676 }
+
677 else
+
678 {
+
679 // unknown request
+
680 res.result(boost::beast::http::status::not_found);
+
681 res.insert("Content-Type", "text/html");
+
682 res.body() = "The file '" + std::string(path) +
+
683 "' was not "
+
684 "found";
+
685 }
+
686
+
687 if (prepare)
+
688 res.prepare_payload();
+
689 }
+
690 catch (std::exception const& e)
+
691 {
+
692 res = {};
+
693 res.result(boost::beast::http::status::internal_server_error);
+
694 res.version(req.version());
+
695 res.insert("Server", "TrustedPublisherServer");
+
696 res.insert("Content-Type", "text/html");
+
697 res.body() =
+
698 std::string{"An internal error occurred"} + e.what();
+
699 res.prepare_payload();
+
700 }
+
701
+
702 if (ssl)
+
703 write(*ssl_stream, res, ec);
+
704 else
+
705 write(sock, res, ec);
+
706
+
707 if (ec || req.need_eof())
+
708 break;
+
709 }
+
710
+
711 // Perform the SSL shutdown
+
712 if (ssl)
+
713 ssl_stream->shutdown(ec);
+
714 }
+
715};
+
716
+
717inline std::shared_ptr<TrustedPublisherServer>
+
718make_TrustedPublisherServer(
+
719 boost::asio::io_context& ioc,
+
720 std::vector<TrustedPublisherServer::Validator> const& validators,
+
721 NetClock::time_point validUntil,
+
722 std::vector<std::pair<NetClock::time_point, NetClock::time_point>> const&
+
723 futures,
+
724 bool useSSL = false,
+
725 int version = 1,
+
726 bool immediateStart = true,
+
727 int sequence = 1)
+
728{
+
729 auto const r = std::make_shared<TrustedPublisherServer>(
+
730 ioc, validators, validUntil, futures, useSSL, version, sequence);
+
731 if (immediateStart)
+
732 r->start();
+
733 return r;
+
734}
+
735
+
736} // namespace test
+
737} // namespace ripple
+
738#endif
@@ -825,37 +824,37 @@ $(function() {
ripple::Serializer::size
std::size_t size() const noexcept
Definition: Serializer.h:72
ripple::Serializer::data
void const * data() const noexcept
Definition: Serializer.h:78
- - -
ripple::test::TrustedPublisherServer::req_type
boost::beast::http::request< boost::beast::http::string_body > req_type
Definition: TrustedPublisherServer.h:55
- - - -
ripple::test::TrustedPublisherServer::do_peer
void do_peer(int id, socket_type &&s, bool ssl)
Definition: TrustedPublisherServer.h:465
- -
ripple::test::TrustedPublisherServer::TrustedPublisherServer
TrustedPublisherServer(boost::asio::io_context &ioc, std::vector< Validator > const &validators, NetClock::time_point validUntil, std::vector< std::pair< NetClock::time_point, NetClock::time_point > > const &futures, bool useSSL=false, int version=1, bool immediateStart=true, int sequence=1)
Definition: TrustedPublisherServer.h:173
- -
ripple::test::TrustedPublisherServer::socket_type
boost::asio::ip::tcp::socket socket_type
Definition: TrustedPublisherServer.h:52
- -
ripple::test::TrustedPublisherServer::resp_type
boost::beast::http::response< boost::beast::http::string_body > resp_type
Definition: TrustedPublisherServer.h:57
- - -
ripple::test::TrustedPublisherServer::getList2_
std::function< std::string(int)> getList2_
Definition: TrustedPublisherServer.h:68
- - - - - -
ripple::test::TrustedPublisherServer::acceptor_
boost::asio::ip::tcp::acceptor acceptor_
Definition: TrustedPublisherServer.h:62
- - -
ripple::test::TrustedPublisherServer::getList_
std::function< std::string(int)> getList_
Definition: TrustedPublisherServer.h:65
- - - -
ripple::test::TrustedPublisherServer::endpoint_type
boost::asio::ip::tcp::endpoint endpoint_type
Definition: TrustedPublisherServer.h:50
- -
ripple::test::TrustedPublisherServer::makeManifestString
static std::string makeManifestString(PublicKey const &pk, SecretKey const &sk, PublicKey const &spk, SecretKey const &ssk, int seq)
Definition: TrustedPublisherServer.h:123
+ + +
ripple::test::TrustedPublisherServer::req_type
boost::beast::http::request< boost::beast::http::string_body > req_type
Definition: TrustedPublisherServer.h:56
+ + + +
ripple::test::TrustedPublisherServer::do_peer
void do_peer(int id, socket_type &&s, bool ssl)
Definition: TrustedPublisherServer.h:464
+ +
ripple::test::TrustedPublisherServer::TrustedPublisherServer
TrustedPublisherServer(boost::asio::io_context &ioc, std::vector< Validator > const &validators, NetClock::time_point validUntil, std::vector< std::pair< NetClock::time_point, NetClock::time_point > > const &futures, bool useSSL=false, int version=1, bool immediateStart=true, int sequence=1)
Definition: TrustedPublisherServer.h:174
+ +
ripple::test::TrustedPublisherServer::socket_type
boost::asio::ip::tcp::socket socket_type
Definition: TrustedPublisherServer.h:53
+ +
ripple::test::TrustedPublisherServer::resp_type
boost::beast::http::response< boost::beast::http::string_body > resp_type
Definition: TrustedPublisherServer.h:58
+ + +
ripple::test::TrustedPublisherServer::getList2_
std::function< std::string(int)> getList2_
Definition: TrustedPublisherServer.h:69
+ + + + + +
ripple::test::TrustedPublisherServer::acceptor_
boost::asio::ip::tcp::acceptor acceptor_
Definition: TrustedPublisherServer.h:63
+ + +
ripple::test::TrustedPublisherServer::getList_
std::function< std::string(int)> getList_
Definition: TrustedPublisherServer.h:66
+ + + +
ripple::test::TrustedPublisherServer::endpoint_type
boost::asio::ip::tcp::endpoint endpoint_type
Definition: TrustedPublisherServer.h:51
+ +
ripple::test::TrustedPublisherServer::makeManifestString
static std::string makeManifestString(PublicKey const &pk, SecretKey const &sk, PublicKey const &spk, SecretKey const &ssk, int seq)
Definition: TrustedPublisherServer.h:124
ripple::test::jtx::sig
Set the regular signature on a JTx.
Definition: sig.h:35
@@ -874,7 +873,7 @@ $(function() {
ripple::NodeStore::write
void write(nudb::detail::ostream &os, std::size_t t)
Definition: varint.h:134
ripple::test::jtx::sign
void sign(Json::Value &jv, Account const &account)
Sign automatically.
Definition: utility.cpp:47
-
ripple::test::make_TrustedPublisherServer
std::shared_ptr< TrustedPublisherServer > make_TrustedPublisherServer(boost::asio::io_context &ioc, std::vector< TrustedPublisherServer::Validator > const &validators, NetClock::time_point validUntil, std::vector< std::pair< NetClock::time_point, NetClock::time_point > > const &futures, bool useSSL=false, int version=1, bool immediateStart=true, int sequence=1)
Definition: TrustedPublisherServer.h:719
+
ripple::test::make_TrustedPublisherServer
std::shared_ptr< TrustedPublisherServer > make_TrustedPublisherServer(boost::asio::io_context &ioc, std::vector< TrustedPublisherServer::Validator > const &validators, NetClock::time_point validUntil, std::vector< std::pair< NetClock::time_point, NetClock::time_point > > const &futures, bool useSSL=false, int version=1, bool immediateStart=true, int sequence=1)
Definition: TrustedPublisherServer.h:718
ripple::test::getEnvLocalhostAddr
char const * getEnvLocalhostAddr()
Definition: envconfig.h:36
ripple
Use hash_* containers for keys that do not need a cryptographically secure hashing algorithm.
Definition: algorithm.h:25
ripple::sfGeneric
SField const sfGeneric
@@ -901,21 +900,21 @@ $(function() {
std::this_thread::sleep_for
T sleep_for(T... args)
std::stringstream::str
T str(T... args)
std::strlen
T strlen(T... args)
- - - - - - - - - - -
ripple::test::TrustedPublisherServer::lambda::work
boost::asio::executor_work_guard< boost::asio::executor > work
Definition: TrustedPublisherServer.h:422
- - -
ripple::test::TrustedPublisherServer::lambda::lambda
lambda(int id_, TrustedPublisherServer &self_, socket_type &&sock_, bool ssl_)
Definition: TrustedPublisherServer.h:425
- + + + + + + + + + + +
ripple::test::TrustedPublisherServer::lambda::work
boost::asio::executor_work_guard< boost::asio::executor > work
Definition: TrustedPublisherServer.h:421
+ + +
ripple::test::TrustedPublisherServer::lambda::lambda
lambda(int id_, TrustedPublisherServer &self_, socket_type &&sock_, bool ssl_)
Definition: TrustedPublisherServer.h:424
+
ripple::test::jtx::seq
Set the sequence number on a JTx.
Definition: seq.h:34
diff --git a/ValidatorList_8cpp_source.html b/ValidatorList_8cpp_source.html index e61a6098bb..0d92ed3095 100644 --- a/ValidatorList_8cpp_source.html +++ b/ValidatorList_8cpp_source.html @@ -2395,7 +2395,7 @@ $(function() {
ripple::to_string
std::string to_string(base_uint< Bits, Tag > const &a)
Definition: base_uint.h:630
ripple::maximiumMessageSize
constexpr std::size_t maximiumMessageSize
Definition: Message.h:34
ripple::HashPrefix::manifest
@ manifest
Manifest.
-
ripple::writeFileContents
void writeFileContents(boost::system::error_code &ec, boost::filesystem::path const &destPath, std::string const &contents)
Definition: FileUtilities.cpp:80
+
ripple::writeFileContents
void writeFileContents(boost::system::error_code &ec, boost::filesystem::path const &destPath, std::string const &contents)
Definition: FileUtilities.cpp:81
ripple::sha512Half
sha512_half_hasher::result_type sha512Half(Args const &... args)
Returns the SHA512-Half of a series of objects.
Definition: digest.h:224
ripple::buildValidatorListMessage
std::size_t buildValidatorListMessage(std::vector< ValidatorList::MessageWithHash > &messages, std::uint32_t rawVersion, std::string const &rawManifest, ValidatorBlobInfo const &currentBlob, std::size_t maxSize)
Definition: ValidatorList.cpp:588
std::next
T next(T... args)
diff --git a/ValidatorRPC__test_8cpp_source.html b/ValidatorRPC__test_8cpp_source.html index 8e27b29c87..4e1ef2d611 100644 --- a/ValidatorRPC__test_8cpp_source.html +++ b/ValidatorRPC__test_8cpp_source.html @@ -681,7 +681,7 @@ $(function() {
beast::unit_test::suite
A testsuite class.
Definition: suite.h:55
ripple::PublicKey
A public key.
Definition: PublicKey.h:61
- +
ripple::test::ValidatorRPC_test
Definition: ValidatorRPC_test.cpp:38
ripple::test::ValidatorRPC_test::testStaticUNL
void testStaticUNL()
Definition: ValidatorRPC_test.cpp:89
ripple::test::ValidatorRPC_test::testPrivileges
void testPrivileges()
Definition: ValidatorRPC_test.cpp:43
@@ -700,7 +700,7 @@ $(function() {
ripple::test::jtx::oracle::asUInt
std::uint32_t asUInt(AnyValue const &v)
Definition: Oracle.cpp:353
ripple::test::jtx::no_admin
std::unique_ptr< Config > no_admin(std::unique_ptr< Config >)
adjust config so no admin ports are enabled
Definition: envconfig.cpp:76
ripple::test::jtx::envconfig
std::unique_ptr< Config > envconfig()
creates and initializes a default configuration for jtx::Env
Definition: envconfig.h:54
-
ripple::test::make_TrustedPublisherServer
std::shared_ptr< TrustedPublisherServer > make_TrustedPublisherServer(boost::asio::io_context &ioc, std::vector< TrustedPublisherServer::Validator > const &validators, NetClock::time_point validUntil, std::vector< std::pair< NetClock::time_point, NetClock::time_point > > const &futures, bool useSSL=false, int version=1, bool immediateStart=true, int sequence=1)
Definition: TrustedPublisherServer.h:719
+
ripple::test::make_TrustedPublisherServer
std::shared_ptr< TrustedPublisherServer > make_TrustedPublisherServer(boost::asio::io_context &ioc, std::vector< TrustedPublisherServer::Validator > const &validators, NetClock::time_point validUntil, std::vector< std::pair< NetClock::time_point, NetClock::time_point > > const &futures, bool useSSL=false, int version=1, bool immediateStart=true, int sequence=1)
Definition: TrustedPublisherServer.h:718
ripple::test::getEnvLocalhostAddr
char const * getEnvLocalhostAddr()
Definition: envconfig.h:36
ripple
Use hash_* containers for keys that do not need a cryptographically secure hashing algorithm.
Definition: algorithm.h:25
ripple::toBase58
std::string toBase58(AccountID const &v)
Convert AccountID to base58 checked string.
Definition: AccountID.cpp:114
@@ -715,7 +715,7 @@ $(function() {
std::set::size
T size(T... args)
std::stringstream::str
T str(T... args)
- + diff --git a/ValidatorSite__test_8cpp_source.html b/ValidatorSite__test_8cpp_source.html index 3ad23c525b..e17442eb43 100644 --- a/ValidatorSite__test_8cpp_source.html +++ b/ValidatorSite__test_8cpp_source.html @@ -808,16 +808,16 @@ $(function() {
ripple::test::StreamSink::messages
std::stringstream const & messages() const
Definition: SuiteJournal.h:155
- +
ripple::test::ValidatorSite_test
Definition: ValidatorSite_test.cpp:60
ripple::test::ValidatorSite_test::testFetchList
void testFetchList(detail::DirGuard const &good, std::vector< FetchListConfig > const &paths)
Definition: ValidatorSite_test.cpp:145
ripple::test::ValidatorSite_test::testFileURLs
void testFileURLs()
Definition: ValidatorSite_test.cpp:363
ripple::test::ValidatorSite_test::run
void run() override
Runs the suite.
Definition: ValidatorSite_test.cpp:401
ripple::test::ValidatorSite_test::testFileList
void testFileList(std::vector< std::pair< std::string, std::string > > const &paths)
Definition: ValidatorSite_test.cpp:300
ripple::test::ValidatorSite_test::testConfigLoad
void testConfigLoad()
Definition: ValidatorSite_test.cpp:65
-
ripple::test::detail::DirGuard
Create a directory and remove it when it's done.
Definition: FileDirGuard.h:37
-
ripple::test::detail::DirGuard::subdir
path const & subdir() const
Definition: FileDirGuard.h:100
-
ripple::test::detail::FileDirGuard
Write a file in a directory and remove when done.
Definition: FileDirGuard.h:110
+
ripple::test::detail::DirGuard
Create a directory and remove it when it's done.
Definition: FileDirGuard.h:39
+
ripple::test::detail::DirGuard::subdir
path const & subdir() const
Definition: FileDirGuard.h:102
+
ripple::test::detail::FileDirGuard
Write a file in a directory and remove when done.
Definition: FileDirGuard.h:112
ripple::test::jtx::Env
A transaction testing environment.
Definition: Env.h:121
ripple::test::jtx::Env::app
Application & app()
Definition: Env.h:261
ripple::test::jtx::Env::journal
beast::Journal const journal
Definition: Env.h:162
@@ -831,7 +831,7 @@ $(function() {
ripple::test::detail::default_effective_overlap
auto constexpr default_effective_overlap
Definition: ValidatorSite_test.cpp:56
ripple::test::detail::realValidatorContents
constexpr char const * realValidatorContents()
Definition: ValidatorSite_test.cpp:43
ripple::test::jtx::envconfig
std::unique_ptr< Config > envconfig()
creates and initializes a default configuration for jtx::Env
Definition: envconfig.h:54
-
ripple::test::make_TrustedPublisherServer
std::shared_ptr< TrustedPublisherServer > make_TrustedPublisherServer(boost::asio::io_context &ioc, std::vector< TrustedPublisherServer::Validator > const &validators, NetClock::time_point validUntil, std::vector< std::pair< NetClock::time_point, NetClock::time_point > > const &futures, bool useSSL=false, int version=1, bool immediateStart=true, int sequence=1)
Definition: TrustedPublisherServer.h:719
+
ripple::test::make_TrustedPublisherServer
std::shared_ptr< TrustedPublisherServer > make_TrustedPublisherServer(boost::asio::io_context &ioc, std::vector< TrustedPublisherServer::Validator > const &validators, NetClock::time_point validUntil, std::vector< std::pair< NetClock::time_point, NetClock::time_point > > const &futures, bool useSSL=false, int version=1, bool immediateStart=true, int sequence=1)
Definition: TrustedPublisherServer.h:718
ripple
Use hash_* containers for keys that do not need a cryptographically secure hashing algorithm.
Definition: algorithm.h:25
ripple::strHex
std::string strHex(FwdIt begin, FwdIt end)
Definition: strHex.h:30
ripple::to_string
std::string to_string(base_uint< Bits, Tag > const &a)
Definition: base_uint.h:630
@@ -842,7 +842,7 @@ $(function() {
std::string::reserve
T reserve(T... args)
std::stringstream::str
T str(T... args)
- +
ripple::test::ValidatorSite_test::FetchListConfig
Definition: ValidatorSite_test.cpp:132
ripple::test::ValidatorSite_test::FetchListConfig::expectedRefreshMin
int expectedRefreshMin
Definition: ValidatorSite_test.cpp:142
ripple::test::ValidatorSite_test::FetchListConfig::effectiveOverlap
std::chrono::seconds effectiveOverlap
Definition: ValidatorSite_test.cpp:140
diff --git a/WorkFile_8h_source.html b/WorkFile_8h_source.html index 525397af01..89039fe953 100644 --- a/WorkFile_8h_source.html +++ b/WorkFile_8h_source.html @@ -200,7 +200,7 @@ $(function() {
ripple
Use hash_* containers for keys that do not need a cryptographically secure hashing algorithm.
Definition: algorithm.h:25
ripple::megabytes
constexpr auto megabytes(T value) noexcept
Definition: ByteUtilities.h:34
ripple::make_error_code
std::error_code make_error_code(ripple::TokenCodecErrc e)
Definition: token_errors.h:97
-
ripple::getFileContents
std::string getFileContents(boost::system::error_code &ec, boost::filesystem::path const &sourcePath, std::optional< std::size_t > maxSize=std::nullopt)
Definition: FileUtilities.cpp:39
+
ripple::getFileContents
std::string getFileContents(boost::system::error_code &ec, boost::filesystem::path const &sourcePath, std::optional< std::size_t > maxSize=std::nullopt)
Definition: FileUtilities.cpp:40
std
STL namespace.
diff --git a/classripple_1_1Logs.html b/classripple_1_1Logs.html index 98e91f0b12..075cace0d9 100644 --- a/classripple_1_1Logs.html +++ b/classripple_1_1Logs.html @@ -202,7 +202,7 @@ Private Attributes

Detailed Description

Manages partitions for logging.

-

Definition at line 50 of file Log.h.

+

Definition at line 51 of file Log.h.

Member Enumeration Documentation

◆ anonymous enum

@@ -227,7 +227,7 @@ Private Attributes EnumeratormaximumMessageCharacters  -

Definition at line 240 of file Log.h.

+

Definition at line 241 of file Log.h.

@@ -553,7 +553,7 @@ Private Attributes -

Definition at line 216 of file Log.h.

+

Definition at line 217 of file Log.h.

@@ -780,7 +780,7 @@ Private Attributes
-

Definition at line 160 of file Log.h.

+

Definition at line 161 of file Log.h.

@@ -804,7 +804,7 @@ Private Attributes
-

Definition at line 165 of file Log.h.

+

Definition at line 166 of file Log.h.

@@ -828,7 +828,7 @@ Private Attributes
-

Definition at line 166 of file Log.h.

+

Definition at line 167 of file Log.h.

@@ -852,7 +852,7 @@ Private Attributes
-

Definition at line 167 of file Log.h.

+

Definition at line 168 of file Log.h.

@@ -876,7 +876,7 @@ Private Attributes
-

Definition at line 168 of file Log.h.

+

Definition at line 169 of file Log.h.

diff --git a/classripple_1_1Logs_1_1File.html b/classripple_1_1Logs_1_1File.html index 064118b237..a99e6db181 100644 --- a/classripple_1_1Logs_1_1File.html +++ b/classripple_1_1Logs_1_1File.html @@ -142,7 +142,7 @@ Private Attributes

Manages a system file containing logged output.

The system file remains open during program execution. Interfaces are provided for interoperating with standard log management tools like logrotate(8): http://linuxcommand.org/man_pages/logrotate8.html

Note
None of the listed interfaces are thread-safe.
-

Definition at line 85 of file Log.h.

+

Definition at line 86 of file Log.h.

Constructor & Destructor Documentation

◆ File()

@@ -355,7 +355,7 @@ Private Attributes

Write to the log file using std::string.

-

Definition at line 143 of file Log.h.

+

Definition at line 144 of file Log.h.

@@ -375,7 +375,7 @@ Private Attributes
-

Definition at line 149 of file Log.h.

+

Definition at line 150 of file Log.h.

@@ -400,7 +400,7 @@ Private Attributes
-

Definition at line 156 of file Log.h.

+

Definition at line 157 of file Log.h.

@@ -424,7 +424,7 @@ Private Attributes
-

Definition at line 157 of file Log.h.

+

Definition at line 158 of file Log.h.

diff --git a/classripple_1_1Logs_1_1Sink.html b/classripple_1_1Logs_1_1Sink.html index 289c227c03..3c2f0397d1 100644 --- a/classripple_1_1Logs_1_1Sink.html +++ b/classripple_1_1Logs_1_1Sink.html @@ -155,7 +155,7 @@ Private Attributes

Detailed Description

-

Definition at line 53 of file Log.h.

+

Definition at line 54 of file Log.h.

Constructor & Destructor Documentation

◆ Sink() [1/2]

@@ -518,7 +518,7 @@ Private Attributes
-

Definition at line 56 of file Log.h.

+

Definition at line 57 of file Log.h.

@@ -542,7 +542,7 @@ Private Attributes
-

Definition at line 57 of file Log.h.

+

Definition at line 58 of file Log.h.

diff --git a/classripple_1_1ValidatorList.html b/classripple_1_1ValidatorList.html index 3e7ecf3202..59953e95db 100644 --- a/classripple_1_1ValidatorList.html +++ b/classripple_1_1ValidatorList.html @@ -350,7 +350,7 @@ Friends  

Detailed Description

-

+

Trusted Validators List

Rippled accepts ledger proposals and validations from trusted validator nodes. A ledger is considered fully-validated once the number of received trusted validations for a ledger meets or exceeds a quorum value.

This class manages the set of validation public keys the local rippled node trusts. The list of trusted keys is populated using the keys listed in the configuration file as well as lists signed by trusted publishers. The trusted publisher public keys are specified in the config.

diff --git a/classripple_1_1ValidatorSite.html b/classripple_1_1ValidatorSite.html index ef41325601..5515cc1135 100644 --- a/classripple_1_1ValidatorSite.html +++ b/classripple_1_1ValidatorSite.html @@ -224,7 +224,7 @@ Friends

 

Detailed Description

-

+

Validator Sites

This class manages the set of configured remote sites used to fetch the latest published recommended validator lists.

Lists are fetched at a regular interval. Fetched lists are expected to be in JSON format and contain the following fields:

diff --git a/classripple_1_1detail_1_1RippledCfgGuard.html b/classripple_1_1detail_1_1RippledCfgGuard.html index 215fa3ad84..83294729b9 100644 --- a/classripple_1_1detail_1_1RippledCfgGuard.html +++ b/classripple_1_1detail_1_1RippledCfgGuard.html @@ -232,7 +232,7 @@ Private Attributes

-

Definition at line 39 of file FileDirGuard.h.

+

Definition at line 41 of file FileDirGuard.h.

@@ -410,7 +410,7 @@ Private Attributes
-

Definition at line 166 of file FileDirGuard.h.

+

Definition at line 168 of file FileDirGuard.h.

@@ -437,7 +437,7 @@ Private Attributes
-

Definition at line 172 of file FileDirGuard.h.

+

Definition at line 174 of file FileDirGuard.h.

@@ -465,7 +465,7 @@ Private Attributes
-

Definition at line 49 of file FileDirGuard.h.

+

Definition at line 51 of file FileDirGuard.h.

@@ -492,7 +492,7 @@ Private Attributes
-

Definition at line 100 of file FileDirGuard.h.

+

Definition at line 102 of file FileDirGuard.h.

@@ -589,7 +589,7 @@ Private Attributes
-

Definition at line 112 of file FileDirGuard.h.

+

Definition at line 114 of file FileDirGuard.h.

@@ -613,7 +613,7 @@ Private Attributes
-

Definition at line 113 of file FileDirGuard.h.

+

Definition at line 115 of file FileDirGuard.h.

@@ -637,7 +637,7 @@ Private Attributes
-

Definition at line 42 of file FileDirGuard.h.

+

Definition at line 44 of file FileDirGuard.h.

@@ -661,7 +661,7 @@ Private Attributes
-

Definition at line 43 of file FileDirGuard.h.

+

Definition at line 45 of file FileDirGuard.h.

@@ -685,7 +685,7 @@ Private Attributes
-

Definition at line 46 of file FileDirGuard.h.

+

Definition at line 48 of file FileDirGuard.h.

diff --git a/classripple_1_1detail_1_1ValidatorsTxtGuard.html b/classripple_1_1detail_1_1ValidatorsTxtGuard.html index 3be0e83ccb..efe78880b2 100644 --- a/classripple_1_1detail_1_1ValidatorsTxtGuard.html +++ b/classripple_1_1detail_1_1ValidatorsTxtGuard.html @@ -198,7 +198,7 @@ Private Attributes
-

Definition at line 39 of file FileDirGuard.h.

+

Definition at line 41 of file FileDirGuard.h.

@@ -326,7 +326,7 @@ Private Attributes
-

Definition at line 166 of file FileDirGuard.h.

+

Definition at line 168 of file FileDirGuard.h.

@@ -353,7 +353,7 @@ Private Attributes
-

Definition at line 172 of file FileDirGuard.h.

+

Definition at line 174 of file FileDirGuard.h.

@@ -381,7 +381,7 @@ Private Attributes
-

Definition at line 49 of file FileDirGuard.h.

+

Definition at line 51 of file FileDirGuard.h.

@@ -408,7 +408,7 @@ Private Attributes
-

Definition at line 100 of file FileDirGuard.h.

+

Definition at line 102 of file FileDirGuard.h.

@@ -433,7 +433,7 @@ Private Attributes
-

Definition at line 112 of file FileDirGuard.h.

+

Definition at line 114 of file FileDirGuard.h.

@@ -457,7 +457,7 @@ Private Attributes
-

Definition at line 113 of file FileDirGuard.h.

+

Definition at line 115 of file FileDirGuard.h.

@@ -481,7 +481,7 @@ Private Attributes
-

Definition at line 42 of file FileDirGuard.h.

+

Definition at line 44 of file FileDirGuard.h.

@@ -505,7 +505,7 @@ Private Attributes
-

Definition at line 43 of file FileDirGuard.h.

+

Definition at line 45 of file FileDirGuard.h.

@@ -529,7 +529,7 @@ Private Attributes
-

Definition at line 46 of file FileDirGuard.h.

+

Definition at line 48 of file FileDirGuard.h.

diff --git a/classripple_1_1test_1_1CaptureLogs.html b/classripple_1_1test_1_1CaptureLogs.html index 5bb9ea6456..40e9c0ab9a 100644 --- a/classripple_1_1test_1_1CaptureLogs.html +++ b/classripple_1_1test_1_1CaptureLogs.html @@ -231,7 +231,7 @@ Private Attributes EnumeratormaximumMessageCharacters  -

Definition at line 240 of file Log.h.

+

Definition at line 241 of file Log.h.

@@ -635,7 +635,7 @@ Private Attributes -

Definition at line 216 of file Log.h.

+

Definition at line 217 of file Log.h.

@@ -894,7 +894,7 @@ Private Attributes
-

Definition at line 160 of file Log.h.

+

Definition at line 161 of file Log.h.

@@ -918,7 +918,7 @@ Private Attributes
-

Definition at line 165 of file Log.h.

+

Definition at line 166 of file Log.h.

@@ -942,7 +942,7 @@ Private Attributes
-

Definition at line 166 of file Log.h.

+

Definition at line 167 of file Log.h.

@@ -966,7 +966,7 @@ Private Attributes
-

Definition at line 167 of file Log.h.

+

Definition at line 168 of file Log.h.

@@ -990,7 +990,7 @@ Private Attributes
-

Definition at line 168 of file Log.h.

+

Definition at line 169 of file Log.h.

diff --git a/classripple_1_1test_1_1CheckMessageLogs.html b/classripple_1_1test_1_1CheckMessageLogs.html index 73a0243c7c..76b313179b 100644 --- a/classripple_1_1test_1_1CheckMessageLogs.html +++ b/classripple_1_1test_1_1CheckMessageLogs.html @@ -222,7 +222,7 @@ Private Attributes EnumeratormaximumMessageCharacters  -

Definition at line 240 of file Log.h.

+

Definition at line 241 of file Log.h.

@@ -610,7 +610,7 @@ Private Attributes -

Definition at line 216 of file Log.h.

+

Definition at line 217 of file Log.h.

@@ -845,7 +845,7 @@ Private Attributes
-

Definition at line 160 of file Log.h.

+

Definition at line 161 of file Log.h.

@@ -869,7 +869,7 @@ Private Attributes
-

Definition at line 165 of file Log.h.

+

Definition at line 166 of file Log.h.

@@ -893,7 +893,7 @@ Private Attributes
-

Definition at line 166 of file Log.h.

+

Definition at line 167 of file Log.h.

@@ -917,7 +917,7 @@ Private Attributes
-

Definition at line 167 of file Log.h.

+

Definition at line 168 of file Log.h.

@@ -941,7 +941,7 @@ Private Attributes
-

Definition at line 168 of file Log.h.

+

Definition at line 169 of file Log.h.

diff --git a/classripple_1_1test_1_1TrustedPublisherServer.html b/classripple_1_1test_1_1TrustedPublisherServer.html index fa7c465e3d..f9d660a6ed 100644 --- a/classripple_1_1test_1_1TrustedPublisherServer.html +++ b/classripple_1_1test_1_1TrustedPublisherServer.html @@ -200,7 +200,7 @@ Private Attributes

Detailed Description

-

Definition at line 47 of file TrustedPublisherServer.h.

+

Definition at line 48 of file TrustedPublisherServer.h.

Member Typedef Documentation

◆ endpoint_type

@@ -222,7 +222,7 @@ Private Attributes
-

Definition at line 50 of file TrustedPublisherServer.h.

+

Definition at line 51 of file TrustedPublisherServer.h.

@@ -246,7 +246,7 @@ Private Attributes
-

Definition at line 51 of file TrustedPublisherServer.h.

+

Definition at line 52 of file TrustedPublisherServer.h.

@@ -270,7 +270,7 @@ Private Attributes
-

Definition at line 52 of file TrustedPublisherServer.h.

+

Definition at line 53 of file TrustedPublisherServer.h.

@@ -294,7 +294,7 @@ Private Attributes
-

Definition at line 54 of file TrustedPublisherServer.h.

+

Definition at line 55 of file TrustedPublisherServer.h.

@@ -318,7 +318,7 @@ Private Attributes
-

Definition at line 56 of file TrustedPublisherServer.h.

+

Definition at line 57 of file TrustedPublisherServer.h.

@@ -342,7 +342,7 @@ Private Attributes
-

Definition at line 58 of file TrustedPublisherServer.h.

+

Definition at line 59 of file TrustedPublisherServer.h.

@@ -409,7 +409,7 @@ Private Attributes
-

Definition at line 173 of file TrustedPublisherServer.h.

+

Definition at line 174 of file TrustedPublisherServer.h.

@@ -428,7 +428,7 @@ Private Attributes
-

Definition at line 309 of file TrustedPublisherServer.h.

+

Definition at line 308 of file TrustedPublisherServer.h.

@@ -456,7 +456,7 @@ Private Attributes
-

Definition at line 80 of file TrustedPublisherServer.h.

+

Definition at line 81 of file TrustedPublisherServer.h.

@@ -512,7 +512,7 @@ Private Attributes
-

Definition at line 123 of file TrustedPublisherServer.h.

+

Definition at line 124 of file TrustedPublisherServer.h.

@@ -539,7 +539,7 @@ Private Attributes
-

Definition at line 151 of file TrustedPublisherServer.h.

+

Definition at line 152 of file TrustedPublisherServer.h.

@@ -558,7 +558,7 @@ Private Attributes
-

Definition at line 281 of file TrustedPublisherServer.h.

+

Definition at line 280 of file TrustedPublisherServer.h.

@@ -577,7 +577,7 @@ Private Attributes
-

Definition at line 301 of file TrustedPublisherServer.h.

+

Definition at line 300 of file TrustedPublisherServer.h.

@@ -596,7 +596,7 @@ Private Attributes
-

Definition at line 315 of file TrustedPublisherServer.h.

+

Definition at line 314 of file TrustedPublisherServer.h.

@@ -615,7 +615,7 @@ Private Attributes
-

Definition at line 321 of file TrustedPublisherServer.h.

+

Definition at line 320 of file TrustedPublisherServer.h.

@@ -642,7 +642,7 @@ Private Attributes
-

Definition at line 389 of file TrustedPublisherServer.h.

+

Definition at line 388 of file TrustedPublisherServer.h.

@@ -669,7 +669,7 @@ Private Attributes
-

Definition at line 396 of file TrustedPublisherServer.h.

+

Definition at line 395 of file TrustedPublisherServer.h.

@@ -696,7 +696,7 @@ Private Attributes
-

Definition at line 403 of file TrustedPublisherServer.h.

+

Definition at line 402 of file TrustedPublisherServer.h.

@@ -723,7 +723,7 @@ Private Attributes
-

Definition at line 410 of file TrustedPublisherServer.h.

+

Definition at line 409 of file TrustedPublisherServer.h.

@@ -751,7 +751,7 @@ Private Attributes
-

Definition at line 446 of file TrustedPublisherServer.h.

+

Definition at line 445 of file TrustedPublisherServer.h.

@@ -795,7 +795,7 @@ Private Attributes
-

Definition at line 465 of file TrustedPublisherServer.h.

+

Definition at line 464 of file TrustedPublisherServer.h.

@@ -820,7 +820,7 @@ Private Attributes
-

Definition at line 60 of file TrustedPublisherServer.h.

+

Definition at line 61 of file TrustedPublisherServer.h.

@@ -844,7 +844,7 @@ Private Attributes
-

Definition at line 61 of file TrustedPublisherServer.h.

+

Definition at line 62 of file TrustedPublisherServer.h.

@@ -868,7 +868,7 @@ Private Attributes
-

Definition at line 62 of file TrustedPublisherServer.h.

+

Definition at line 63 of file TrustedPublisherServer.h.

@@ -892,7 +892,7 @@ Private Attributes
-

Definition at line 65 of file TrustedPublisherServer.h.

+

Definition at line 66 of file TrustedPublisherServer.h.

@@ -916,7 +916,7 @@ Private Attributes
-

Definition at line 68 of file TrustedPublisherServer.h.

+

Definition at line 69 of file TrustedPublisherServer.h.

@@ -940,7 +940,7 @@ Private Attributes
-

Definition at line 71 of file TrustedPublisherServer.h.

+

Definition at line 72 of file TrustedPublisherServer.h.

@@ -964,7 +964,7 @@ Private Attributes
-

Definition at line 72 of file TrustedPublisherServer.h.

+

Definition at line 73 of file TrustedPublisherServer.h.

@@ -988,7 +988,7 @@ Private Attributes
-

Definition at line 74 of file TrustedPublisherServer.h.

+

Definition at line 75 of file TrustedPublisherServer.h.

@@ -1012,7 +1012,7 @@ Private Attributes
-

Definition at line 75 of file TrustedPublisherServer.h.

+

Definition at line 76 of file TrustedPublisherServer.h.

diff --git a/classripple_1_1test_1_1detail_1_1DirGuard.html b/classripple_1_1test_1_1detail_1_1DirGuard.html index 7dae143003..c23a9c6eec 100644 --- a/classripple_1_1test_1_1detail_1_1DirGuard.html +++ b/classripple_1_1test_1_1detail_1_1DirGuard.html @@ -159,7 +159,7 @@ Private Attributes

Detailed Description

Create a directory and remove it when it's done.

-

Definition at line 36 of file FileDirGuard.h.

+

Definition at line 38 of file FileDirGuard.h.

Member Typedef Documentation

◆ path

@@ -181,7 +181,7 @@ Private Attributes
-

Definition at line 39 of file FileDirGuard.h.

+

Definition at line 41 of file FileDirGuard.h.

@@ -218,7 +218,7 @@ Private Attributes
-

Definition at line 59 of file FileDirGuard.h.

+

Definition at line 61 of file FileDirGuard.h.

@@ -237,7 +237,7 @@ Private Attributes
-

Definition at line 83 of file FileDirGuard.h.

+

Definition at line 85 of file FileDirGuard.h.

@@ -266,7 +266,7 @@ Private Attributes
-

Definition at line 49 of file FileDirGuard.h.

+

Definition at line 51 of file FileDirGuard.h.

@@ -285,7 +285,7 @@ Private Attributes
-

Definition at line 100 of file FileDirGuard.h.

+

Definition at line 102 of file FileDirGuard.h.

@@ -310,7 +310,7 @@ Private Attributes
-

Definition at line 42 of file FileDirGuard.h.

+

Definition at line 44 of file FileDirGuard.h.

@@ -334,7 +334,7 @@ Private Attributes
-

Definition at line 43 of file FileDirGuard.h.

+

Definition at line 45 of file FileDirGuard.h.

@@ -358,7 +358,7 @@ Private Attributes
-

Definition at line 46 of file FileDirGuard.h.

+

Definition at line 48 of file FileDirGuard.h.

diff --git a/classripple_1_1test_1_1detail_1_1FileDirGuard.html b/classripple_1_1test_1_1detail_1_1FileDirGuard.html index 892733c5a4..fbc0347495 100644 --- a/classripple_1_1test_1_1detail_1_1FileDirGuard.html +++ b/classripple_1_1test_1_1detail_1_1FileDirGuard.html @@ -174,7 +174,7 @@ Private Attributes

Detailed Description

Write a file in a directory and remove when done.

-

Definition at line 109 of file FileDirGuard.h.

+

Definition at line 111 of file FileDirGuard.h.

Member Typedef Documentation

◆ path

@@ -196,7 +196,7 @@ Private Attributes
-

Definition at line 39 of file FileDirGuard.h.

+

Definition at line 41 of file FileDirGuard.h.

@@ -251,7 +251,7 @@ Private Attributes
-

Definition at line 116 of file FileDirGuard.h.

+

Definition at line 118 of file FileDirGuard.h.

@@ -270,7 +270,7 @@ Private Attributes
-

Definition at line 142 of file FileDirGuard.h.

+

Definition at line 144 of file FileDirGuard.h.

@@ -290,7 +290,7 @@ Private Attributes
-

Definition at line 166 of file FileDirGuard.h.

+

Definition at line 168 of file FileDirGuard.h.

@@ -309,7 +309,7 @@ Private Attributes
-

Definition at line 172 of file FileDirGuard.h.

+

Definition at line 174 of file FileDirGuard.h.

@@ -337,7 +337,7 @@ Private Attributes
-

Definition at line 49 of file FileDirGuard.h.

+

Definition at line 51 of file FileDirGuard.h.

@@ -364,7 +364,7 @@ Private Attributes
-

Definition at line 100 of file FileDirGuard.h.

+

Definition at line 102 of file FileDirGuard.h.

@@ -389,7 +389,7 @@ Private Attributes
-

Definition at line 112 of file FileDirGuard.h.

+

Definition at line 114 of file FileDirGuard.h.

@@ -413,7 +413,7 @@ Private Attributes
-

Definition at line 113 of file FileDirGuard.h.

+

Definition at line 115 of file FileDirGuard.h.

@@ -437,7 +437,7 @@ Private Attributes
-

Definition at line 42 of file FileDirGuard.h.

+

Definition at line 44 of file FileDirGuard.h.

@@ -461,7 +461,7 @@ Private Attributes
-

Definition at line 43 of file FileDirGuard.h.

+

Definition at line 45 of file FileDirGuard.h.

@@ -485,7 +485,7 @@ Private Attributes
-

Definition at line 46 of file FileDirGuard.h.

+

Definition at line 48 of file FileDirGuard.h.

diff --git a/classripple_1_1test_1_1jtx_1_1SuiteLogs.html b/classripple_1_1test_1_1jtx_1_1SuiteLogs.html index 273019bc1e..426f003453 100644 --- a/classripple_1_1test_1_1jtx_1_1SuiteLogs.html +++ b/classripple_1_1test_1_1jtx_1_1SuiteLogs.html @@ -223,7 +223,7 @@ Private Attributes EnumeratormaximumMessageCharacters  -

Definition at line 240 of file Log.h.

+

Definition at line 241 of file Log.h.

@@ -625,7 +625,7 @@ Private Attributes -

Definition at line 216 of file Log.h.

+

Definition at line 217 of file Log.h.

@@ -836,7 +836,7 @@ Private Attributes
-

Definition at line 160 of file Log.h.

+

Definition at line 161 of file Log.h.

@@ -860,7 +860,7 @@ Private Attributes
-

Definition at line 165 of file Log.h.

+

Definition at line 166 of file Log.h.

@@ -884,7 +884,7 @@ Private Attributes
-

Definition at line 166 of file Log.h.

+

Definition at line 167 of file Log.h.

@@ -908,7 +908,7 @@ Private Attributes
-

Definition at line 167 of file Log.h.

+

Definition at line 168 of file Log.h.

@@ -932,7 +932,7 @@ Private Attributes
-

Definition at line 168 of file Log.h.

+

Definition at line 169 of file Log.h.

diff --git a/compression__test_8cpp_source.html b/compression__test_8cpp_source.html index 15265af785..d6c4fc0851 100644 --- a/compression__test_8cpp_source.html +++ b/compression__test_8cpp_source.html @@ -631,7 +631,7 @@ $(function() {
ripple::Config::VP_REDUCE_RELAY_BASE_SQUELCH_ENABLE
bool VP_REDUCE_RELAY_BASE_SQUELCH_ENABLE
Definition: Config.h:248
ripple::Config::loadFromString
void loadFromString(std::string const &fileContents)
Load the config from the contents of the string.
Definition: Config.cpp:478
ripple::Config::COMPRESSION
bool COMPRESSION
Definition: Config.h:220
-
ripple::Logs
Manages partitions for logging.
Definition: Log.h:51
+
ripple::Logs
Manages partitions for logging.
Definition: Log.h:52
ripple::Message::getBuffer
std::vector< uint8_t > const & getBuffer(Compressed tryCompressed)
Retrieve the packed message data.
Definition: Message.cpp:210
ripple::SHAMapNodeID
Identifies a node inside a SHAMap.
Definition: SHAMapNodeID.h:34
diff --git a/index.html b/index.html index 556d2e901c..4dc093184b 100644 --- a/index.html +++ b/index.html @@ -73,23 +73,23 @@ $(function() {

codecov

-

+

The XRP Ledger

The XRP Ledger is a decentralized cryptographic ledger powered by a network of peer-to-peer nodes. The XRP Ledger uses a novel Byzantine Fault Tolerant consensus algorithm to settle and record transactions in a secure distributed database without a central operator.

-

+

XRP

XRP is a public, counterparty-free asset native to the XRP Ledger, and is designed to bridge the many different currencies in use worldwide. XRP is traded on the open-market and is available for anyone to access. The XRP Ledger was created in 2012 with a finite supply of 100 billion units of XRP.

-

+

rippled

The server software that powers the XRP Ledger is called rippled and is available in this repository under the permissive ISC open-source license. The rippled server software is written primarily in C++ and runs on a variety of platforms. The rippled server software can run in several modes depending on its configuration.

If you are interested in running an API Server (including a Full History Server), take a look at Clio. (rippled Reporting Mode has been replaced by Clio.)

-

+

Build from Source

-

+

Key Features of the XRP Ledger

  • Censorship-Resistant Transaction Processing: No single party decides which transactions succeed or fail, and no one can "roll back" a transaction after it completes. As long as those who choose to participate in the network keep it healthy, they can settle transactions in seconds.
    • @@ -100,7 +100,7 @@ Key Features of the XRP Ledger
  • Modern Features for Smart Contracts: Features like Escrow, Checks, and Payment Channels support cutting-edge financial applications including the Interledger Protocol. This toolbox of advanced features comes with safety features like a process for amending the network and separate checks against invariant constraints.
  • On-Ledger Decentralized Exchange: In addition to all the features that make XRP useful on its own, the XRP Ledger also has a fully-functional accounting system for tracking and trading obligations denominated in any way users want, and an exchange built into the protocol. The XRP Ledger can settle long, cross-currency payment paths and exchanges of multiple currencies in atomic transactions, bridging gaps of trust with XRP.
-

+

Source Code

Here are some good places to start learning the source code:

    @@ -108,7 +108,7 @@ Source Code
  • Read the levelization document to get an idea of the internal dependency graph.
  • In the big picture, the main function constructs an ApplicationImp object, which implements the Application virtual interface. Almost every component in the application takes an Application& parameter in its constructor, typically named app and stored as a member variable app_. This allows most components to depend on any other component.
-

+

Repository Contents

@@ -125,14 +125,14 @@ Repository Contents
./src Source code.

Some of the directories under src are external repositories included using git-subtree. See those directories' README files for more details.

-

+

Additional Documentation

-

+

See Also

  • Clio API Server for the XRP Ledger
    • diff --git a/md____w_rippled_rippled_BUILD.html b/md____w_rippled_rippled_BUILD.html index 4713afbd49..8da6a06807 100644 --- a/md____w_rippled_rippled_BUILD.html +++ b/md____w_rippled_rippled_BUILD.html @@ -268,8 +268,7 @@ Conan

    After any updates or changes to dependencies, you may need to do the following:

    1. Remove your build directory.
      2. -
    2. Remove the Conan cache:
      rm -rf ~/.conan/data
      -
      3. +
    3. Remove the Conan cache: conan remove "*" -c
    4. Re-run conan install.

    @@ -284,27 +283,7 @@ Conan

  • For conan install, pass --settings build_type=Debug
  • For cmake, pass -DCMAKE_BUILD_TYPE=Debug
    • -

    -no std::result_of

    -

    If your compiler version is recent enough to have removed std::result_of as part of C++20, e.g. Apple Clang 15.0, then you might need to add a preprocessor definition to your build.

    -
    conan profile update 'options.boost:extra_b2_flags="define=BOOST_ASIO_HAS_STD_INVOKE_RESULT"' default
    -
    conan profile update 'env.CFLAGS="-DBOOST_ASIO_HAS_STD_INVOKE_RESULT"' default
    -
    conan profile update 'env.CXXFLAGS="-DBOOST_ASIO_HAS_STD_INVOKE_RESULT"' default
    -
    conan profile update 'conf.tools.build:cflags+=["-DBOOST_ASIO_HAS_STD_INVOKE_RESULT"]' default
    -
    conan profile update 'conf.tools.build:cxxflags+=["-DBOOST_ASIO_HAS_STD_INVOKE_RESULT"]' default
    -

    -call to 'async_teardown' is ambiguous

    -

    If you are compiling with an early version of Clang 16, then you might hit a regression when compiling C++20 that manifests as an error in a Boost header. You can workaround it by adding this preprocessor definition:

    -
    conan profile update 'env.CXXFLAGS="-DBOOST_ASIO_DISABLE_CONCEPTS"' default
    -
    conan profile update 'conf.tools.build:cxxflags+=["-DBOOST_ASIO_DISABLE_CONCEPTS"]' default
    -

    -recompile with -fPIC

    -

    If you get a linker error suggesting that you recompile Boost with position-independent code, such as:

    -
    /usr/bin/ld.gold: error: /home/username/.conan/data/boost/1.77.0/_/_/package/.../lib/libboost_container.a(alloc_lib.o):
    -
    requires unsupported dynamic reloc 11; recompile with -fPIC
    -

    Conan most likely downloaded a bad binary distribution of the dependency. This seems to be a bug in Conan just for Boost 1.77.0 compiled with GCC for Linux. The solution is to build the dependency locally by passing --build boost when calling conan install.

    -
    conan install --build boost ...
    -

    +

    Add a Dependency

    If you want to experiment with a new package, follow these steps:

      diff --git a/md____w_rippled_rippled_Builds_levelization_README.html b/md____w_rippled_rippled_Builds_levelization_README.html index 38a2302251..b5c619d769 100644 --- a/md____w_rippled_rippled_Builds_levelization_README.html +++ b/md____w_rippled_rippled_Builds_levelization_README.html @@ -114,7 +114,7 @@ $(function() { 16 test/rpc test/app

      (Note that test levelization is much less important and much less strictly enforced than ripple levelization, other than the requirement that test code should never be included in ripple code.)

      -

      +

      Validation

      The levelization.sh script takes no parameters, reads no environment variables, and can be run from any directory, as long as it is in the expected location in the rippled repo. It can be run at any time from within a checked out repo, and will do an analysis of all the #includes in the rippled source. The only caveat is that it runs much slower under Windows than in Linux. It hasn't yet been tested under MacOS. It generates many files of [results](results):

        diff --git a/md____w_rippled_rippled_CONTRIBUTING.html b/md____w_rippled_rippled_CONTRIBUTING.html index 103052f3b5..9a2ee5fd3e 100644 --- a/md____w_rippled_rippled_CONTRIBUTING.html +++ b/md____w_rippled_rippled_CONTRIBUTING.html @@ -73,10 +73,10 @@ $(function() {

The XRP Ledger has many and diverse stakeholders, and everyone deserves a chance to contribute meaningful changes to the code that runs the XRPL.

-

+

Contributing

We assume you are familiar with the general practice of making contributions on GitHub. This file includes only special instructions specific to this project.

-

+

Before you start

The following branches exist in the main project repository:

    @@ -101,11 +101,11 @@ Before you start

Regardless of where the branch is created, please open a draft pull request as soon as possible after pushing the branch to Github, to increase visibility, and ease feedback during the development process.

-

+

Major contributions

If your contribution is a major feature or breaking change, then you must first write an XRP Ledger Standard (XLS) describing it. Go to XRPL-Standards, choose the next available standard number, and open a discussion with an appropriate title to propose your draft standard.

When you submit a pull request, please link the corresponding XLS in the description. An XLS still in draft status is considered a work-in-progress and open for discussion. Please allow time for questions, suggestions, and changes to the XLS draft. It is the responsibility of the XLS author to update the draft to match the final implementation when its corresponding pull request is merged, unless the author delegates that responsibility to others.

-

+

Before making a pull request

(Or marking a draft pull request as ready.)

Changes that alter transaction processing must be guarded by an Amendment. All other changes that maintain the existing behavior do not need an Amendment.

@@ -124,7 +124,7 @@ Before making a pull request
  • Every commit should be signed.
  • Every commit should be well-formed (builds successfully, unit tests passing), as this helps to resolve merge conflicts, and makes it easier to use git bisect to find bugs.
    • -

    +

    Good commit messages

    Refer to "How to Write a Git Commit Message" for general rules on writing a good commit message.

    tl;dr

    @@ -154,7 +154,7 @@ Good commit messages
  • chore: - Other tasks that don't affect the binary, but don't fit any of the other cases. e.g. formatting, git settings, updating Github Actions jobs.

    • Whenever possible, when updating commits after the PR is open, please add the PR number to the end of the subject line. e.g. test: Add unit tests for Feature X (#1234).

    -

    +

    Pull requests

    In general, pull requests use develop as the base branch. The exceptions are

    • Fixes and improvements to a release candidate use release as the base.
      • @@ -164,7 +164,7 @@ Pull requests

      Github pull requests are created as "Ready" by default, or you can mark a "Draft" pull request as "Ready". Once a pull request is marked as "Ready", any changes must be added as new commits. Do not force-push to a branch in a pull request under review. (This includes rebasing your branch onto the updated base branch. Use a merge operation, instead or hit the "Update branch" button at the bottom of the Github PR page.) This preserves the ability for reviewers to filter changes since their last review.

      A pull request must obtain approvals from at least two reviewers before it can be considered for merge by a Maintainer. Maintainers retain discretion to require more approvals if they feel the credibility of the existing approvals is insufficient.

      Pull requests must be merged by squash-and-merge to preserve a linear history for the develop branch.

      -

      +

      "Ready to merge"

      A pull request should only have the "Ready to merge" label added when it meets a few criteria:

        @@ -180,10 +180,10 @@ Pull requests
      1. Finally, and most importantly, the author of the PR must positively indicate that the PR is ready to merge. That can be accomplished by adding the "Ready to merge" label if their role allows, or by leaving a comment to the effect that the PR is ready to merge.

      Once the "Ready to merge" label is added, a maintainer may merge the PR at any time, so don't use it lightly.

      -

      +

      Style guide

      This is a non-exhaustive list of recommended style guidelines. These are not always strictly enforced and serve as a way to keep the codebase coherent rather than a set of thou shalt not commandments.

      -

      +

      Formatting

      All code must conform to clang-format version 18, according to the settings in .clang-format, unless the result would be unreasonably difficult to read or maintain. To demarcate lines that should be left as-is, surround them with comments like this:

      // clang-format off
      @@ -201,7 +201,7 @@ Formatting

      You can install a pre-commit hook to automatically run clang-format before every commit:

      pip3 install pre-commit
      pre-commit install
      -

      +

      Contracts and instrumentation

      We are using Antithesis for continuous fuzzing, and keep a copy of Antithesis C++ SDK in external/antithesis-sdk. One of the aims of fuzzing is to identify bugs by finding external conditions which cause contracts violations inside rippled. The contracts are expressed as XRPL_ASSERT or UNREACHABLE (defined in include/xrpl/beast/utility/instrumentation.h), which are effectively (outside of Antithesis) wrappers for assert(...) with added name. The purpose of name is to provide contracts with stable identity which does not rely on line numbers.

      When rippled is built with the Antithesis instrumentation enabled (using voidstar CMake option) and ran on the Antithesis platform, the contracts become test properties; otherwise they are just like a regular assert. To learn more about Antithesis, see How Antithesis Works and C++ SDK

      @@ -225,7 +225,7 @@ Contracts and instrumentation
    • Do not use std::unreachable
    • Do not put contracts where they can be violated by an external condition (e.g. timing, data payload before mandatory validation etc.) as this creates bogus bug reports (and causes crashes of Debug builds)
    -

    +

    Unit Tests

    To execute all unit tests:

    (Note: Using multiple cores on a Mac M1 can cause spurious test failures. The
    @@ -343,7 +343,7 @@ Unit Tests
    It also assumes you have a default gpg signing key set up in git. e.g.

    $ git config user.signingkey 968479A1AFF927E37D1A566BB5690EEEBB952194

    -

    +

    (This is github's key. Use your own.)

    ### When and how to merge pull requests
    @@ -446,25 +446,25 @@ Unit Tests
    The workflow may look something like:

    git fetch –multiple upstreams user1 user2 user3 [...] git checkout -B release-next –no-track upstream/develop

    -

    +

    Only do an ff-only merge if prbranch1 is either already

    -

    +

    squashed, or needs to be merged with separate commits,

    -

    +

    and has no merge commits.

    -

    +

    Use -S on the ff-only merge if prbranch1 isn't signed.

    git merge [-S] –ff-only user1/prbranch1

    git merge –squash user2/prbranch2 git commit -S # Use the commit message provided on the PR

    git merge –squash user3/prbranch3 git commit -S # Use the commit message provided on the PR

    [...]

    -

    +

    Make sure the commits look right

    git log –show-signature "upstream/develop..HEAD"

    git push –set-upstream origin

    -

    +

    Continue to "Making the release" to update the version number, so

    -

    +

    everything can be done in one PR.

    You can also use the [squash-branches] script.
    @@ -485,14 +485,14 @@ everything can be done in one PR.

    git diff

    git add ${build}

    git commit -S -m "Set version to ${v}"

    -

    +

    You could use your "origin" repo, but some CI tests work better on upstream.

    git push upstream-push git fetch upstreams git branch –set-upstream-to=upstream/release-next

    You can also use the [update-version] script.
    2. Create a Pull Request for `release-next` with **`develop`** as
    the base branch.
    1. Use the title "[TRIVIAL] Set version to X.X.X-bX".
    2. Instead of the default description template, use the following:
    -

    +

    High Level Overview of Change

    This PR only changes the version number. It will be merged as soon as Github CI actions successfully complete.

    3. Wait for CI to successfully complete, and get someone to approve
    the PR. (It is safe to ignore known CI issues.)
    @@ -518,28 +518,28 @@ High Level Overview of Change
    abandon 2.4.0-b1, the next attempt will be 2.4.0-b2.
    8. Once everything is ready to go, push to `release`.

    git fetch upstreams

    -

    +

    Just to be safe, do a dry run first:

    git push –dry-run upstream-push release-next:release

    -

    +

    If everything looks right, push the branch

    git push upstream-push release-next:release

    -

    +

    Check that all of the branches are updated

    git fetch upstreams git log -1 –oneline

    -

    +

    The output should look like:

    -

    +

    0123456789 (HEAD -> upstream/release-next, upstream/release,

    -

    +

    upstream/develop) Set version to 2.4.0-b1

    -

    +

    Note that upstream/develop may not be on this commit, but

    -

    +

    upstream/release must be.

    -

    +

    Other branches, including some from upstream-push, may also be

    -

    +

    present.

    9. Tag the release, too.

    git tag <version number> git push upstream-push <version number>

    10. Delete the `release-next` branch on the repo. Use the Github UI or:
    @@ -583,9 +583,9 @@ present.
    E.g. For release A.B.C-rcD, use `mergeABCrcD`.

    git fetch upstreams

    git checkout –no-track -b mergeABCrcD upstream/develop

    2. Merge `release` into your branch.
    -

    +

    I like the "--edit --log --verbose" parameters, but they are

    -

    +

    not required.

    git merge upstream/release

    3. `BuildInfo.cpp` will have a conflict with the version number.
    Resolve it with the version from `develop` - the higher version.
    @@ -601,11 +601,11 @@ not required.
    `develop` back into your branch. Instead rebase preserving merges,
    or do the merge again. (See also the `rerere` git config setting.)

    git rebase –rebase-merges upstream/develop

    -

    +

    OR

    git reset –hard upstream/develop git merge upstream/release

    7. When the PR is ready, push it to `develop`.

    git fetch upstreams

    -

    +

    Make sure the commits look right

    git log –show-signature "upstream/develop^..HEAD"

    git push upstream-push mergeABCrcD:develop

    @@ -647,28 +647,28 @@ Make sure the commits look right
    more RCs as necessary](#release-candidates-after-the-first)
    8. Once everything is ready to go, push to `release` and `master`.

    git fetch upstreams

    -

    +

    Just to be safe, do dry runs first:

    git push –dry-run upstream-push master-next:release git push –dry-run upstream-push master-next:master

    -

    +

    If everything looks right, push the branch

    git push upstream-push master-next:release git push upstream-push master-next:master

    -

    +

    Check that all of the branches are updated

    git fetch upstreams git log -1 –oneline

    -

    +

    The output should look like:

    -

    +

    0123456789 (HEAD -> upstream/master-next, upstream/master,

    -

    +

    upstream/release) Set version to A.B.0

    -

    +

    Note that both upstream/release and upstream/master must be on this

    -

    +

    commit.

    -

    +

    Other branches, including some from upstream-push, may also be

    -

    +

    present.

    9. Tag the release, too.

    git tag <version number> git push upstream-push <version number>

    10. Delete the `master-next` branch on the repo. Use the Github UI or:
    @@ -715,28 +715,28 @@ present.
    version setting commit remains last
    8. Once everything is ready to go, push to `master` **only**.

    git fetch upstreams

    -

    +

    Just to be safe, do a dry run first:

    git push –dry-run upstream-push master-next:master

    -

    +

    If everything looks right, push the branch

    git push upstream-push master-next:master

    -

    +

    Check that all of the branches are updated

    git fetch upstreams git log -1 –oneline

    -

    +

    The output should look like:

    -

    +

    0123456789 (HEAD -> upstream/master-next, upstream/master) Set version

    -

    +

    to 2.4.1

    -

    +

    Note that upstream/master must be on this commit. upstream/release and

    -

    +

    upstream/develop should not.

    -

    +

    Other branches, including some from upstream-push, may also be

    -

    +

    present.

    9. Tag the release, too.

    git tag <version number> git push upstream-push <version number>

    9. Delete the `master-next` branch on the repo.
    @@ -753,9 +753,9 @@ present.
    E.g. For release 2.2.3, use `merge223`.

    git fetch upstreams

    git checkout –no-track -b merge223 upstream/develop

    2. Merge master into your branch.
    -

    +

    I like the "--edit --log --verbose" parameters, but they are

    -

    +

    not required.

    git merge upstream/master

    3. `BuildInfo.cpp` will have a conflict with the version number.
    Resolve it with the version from `develop` - the higher version.
    @@ -771,11 +771,11 @@ not required.
    `develop` back into your branch. Instead rebase preserving merges,
    or do the merge again. (See also the `rerere` git config setting.)

    git rebase –rebase-merges upstream/develop

    -

    +

    OR

    git reset –hard upstream/develop git merge upstream/master

    7. When the PR is ready, push it to `develop`.

    git fetch upstreams

    -

    +

    Make sure the commits look right

    git log –show-signature "upstream/develop..HEAD"

    git push upstream-push HEAD:develop

    Development on `develop` can proceed as normal. It is recommended to
    @@ -799,10 +799,10 @@ Make sure the commits look right
    1. Create two branches in the main (`upstream`) repo.

    git fetch upstreams

    -

    +

    Create a base branch off the tag

    git checkout –no-track -b master-2.1.2 2.1.1 git push upstream-push

    -

    +

    Create a working branch

    git checkout –no-track -b master212-next master-2.1.2 git push upstream-push

    git fetch upstreams ``

      diff --git a/md____w_rippled_rippled_SECURITY.html b/md____w_rippled_rippled_SECURITY.html index 6ec5d496cf..8a7d546652 100644 --- a/md____w_rippled_rippled_SECURITY.html +++ b/md____w_rippled_rippled_SECURITY.html @@ -73,15 +73,15 @@ $(function() {

      For more details on operating an XRP Ledger server securely, please visit https://xrpl.org/manage-the-rippled-server.html.

      -

      +

      Security Policy

      -

      +

      Supported Versions

      Software constantly evolves. In order to focus resources, we only generally only accept vulnerability reports that affect recent and current versions of the software. We always accept reports for issues present in the master, release or develop branches, and with proposed, open pull requests.

      -

      +

      Identifying and Reporting Vulnerabilities

      We take security seriously and we do our best to ensure that all our releases are bug free. But we aren't perfect and sometimes things will slip through.

      -

      +

      Responsible Investigation

      We urge you to examine our code carefully and responsibly, and to disclose any issues that you identify in a responsible fashion.

      Responsible investigation includes, but isn't limited to, the following:

      @@ -90,7 +90,7 @@ Responsible Investigation
    1. Not targeting physical security measures, or attempting to use social engineering, spam, distributed denial of service (DDOS) attacks, etc.
    2. Investigating bugs in a way that makes a reasonable, good faith effort not to be disruptive or harmful to the XRP Ledger and the broader ecosystem.
      3. -

      +

      Responsible Disclosure

      If you discover a vulnerability or potential threat, or if you think you have, please reach out by dropping an email using the contact information below.

      Your report should include the following:

      @@ -103,7 +103,7 @@ Responsible Disclosure

      In your email, please describe the issue or potential threat. If possible, include a "repro" (code that can reproduce the issue) or describe the best way to reproduce and replicate the issue. Please make your report as detailed and comprehensive as possible.

      For more information on responsible disclosure, please read this Wikipedia article.

      -

      +

      Report Handling Process

      Please report the bug directly to us and limit further disclosure. If you want to prove that you knew the bug as of a given time, consider using a cryptographic precommitment: hash the content of your report and publish the hash on a medium of your choice (e.g. on Twitter or as a memo in a transaction) as "proof" that you had written the text at a given point in time.

      Once we receive a report, we:

      @@ -117,7 +117,7 @@ Report Handling Process

    We will triage and respond to your disclosure within 24 hours. Beyond that, we will work to analyze the issue in more detail, formulate, develop and test a fix.

    While we commit to responding with 24 hours of your initial report with our triage assessment, we cannot guarantee a response time for the remaining steps. We will communicate with you throughout this process, letting you know where we are and keeping you updated on the timeframe.

    -

    +

    Bug Bounty Program

    Ripple is generously sponsoring a bug bounty program for vulnerabilities in rippled (and other related projects, like xrpl.js, xrpl-py, xrpl4j).

    This program allows us to recognize and reward individuals or groups that identify and report bugs. In summary, in order to qualify for a bounty, the bug must be:

    @@ -130,7 +130,7 @@ Bug Bounty Program
  • Unused. If you use the exploit to attack the XRP Ledger, you do not qualify for a bounty. If you report a vulnerability used in an ongoing or past attack and there is specific, concrete evidence that suggests you are the attacker we reserve the right not to pay a bounty.

    • The amount paid varies dramatically. Vulnerabilities that are harmless on their own, but could form part of a critical exploit will usually receive a bounty. Full-blown exploits can receive much higher bounties. Please don’t hold back partial vulnerabilities while trying to construct a full-blown exploit. We will pay a bounty to anyone who reports a complete chain of vulnerabilities even if they have reported each component of the exploit separately and those vulnerabilities have been fixed in the meantime. However, to qualify for a the full bounty, you must to have been the first to report each of the partial exploits.

    -

    +

    Contacting Us

    To report a qualifying bug, please send a detailed report to:

    diff --git a/md____w_rippled_rippled_docs_0001_negative_unl_README.html b/md____w_rippled_rippled_docs_0001_negative_unl_README.html index 6b89dedfa1..6cdccc249a 100644 --- a/md____w_rippled_rippled_docs_0001_negative_unl_README.html +++ b/md____w_rippled_rippled_docs_0001_negative_unl_README.html @@ -72,13 +72,13 @@ $(function() {
    Negative UNL Engineering Spec
    -

    +

    The Problem Statement

    The moment-to-moment health of the XRP Ledger network depends on the health and connectivity of a small number of computers (nodes). The most important nodes are validators, specifically ones listed on the unique node list (UNL). Ripple publishes a recommended UNL that most network nodes use to determine which peers in the network are trusted. Although most validators use the same list, they are not required to. The XRP Ledger network progresses to the next ledger when enough validators reach agreement (above the minimum quorum of 80%) about what transactions to include in the next ledger.

    As an example, if there are 10 validators on the UNL, at least 8 validators have to agree with the latest ledger for it to become validated. But what if enough of those validators are offline to drop the network below the 80% quorum? The XRP Ledger network favors safety/correctness over advancing the ledger. Which means if enough validators are offline, the network will not be able to validate ledgers.

    Unfortunately validators can go offline at any time for many different reasons. Power outages, network connectivity issues, and hardware failures are just a few scenarios where a validator would appear "offline". Given that most of these events are temporary, it would make sense to temporarily remove that validator from the UNL. But the UNL is updated infrequently and not every node uses the same UNL. So instead of removing the unreliable validator from the Ripple recommended UNL, we can create a second negative UNL which is stored directly on the ledger (so the entire network has the same view). This will help the network see which validators are currently unreliable, and adjust their quorum calculation accordingly.

    Improving the liveness of the network is the main motivation for the negative UNL.

    -

    +

    Targeted Faults

    In order to determine which validators are unreliable, we need clearly define what kind of faults to measure and analyze. We want to deal with the faults we frequently observe in the production network. Hence we will only monitor for validators that do not reliably respond to network messages or send out validations disagreeing with the locally generated validations. We will not target other byzantine faults.

    To track whether or not a validator is responding to the network, we could monitor them with a “heartbeat” protocol. Instead of creating a new heartbeat protocol, we can leverage some existing protocol messages to mimic the heartbeat. We picked validation messages because validators should send one and only one validation message per ledger. In addition, we only count the validation messages that agree with the local node's validations.

    @@ -120,9 +120,9 @@ Targeted Faults

    -

    +

    External Interactions

    -

    +

    Message Format Changes

    This proposal will:

    1. add a new pseudo-transaction type
      2. @@ -131,10 +131,10 @@ Message Format Changes
    2. add the negative UNL to the ledger data structure.

    Any tools or systems that rely on the format of this data will have to be updated.

    -

    +

    Amendment

    This feature will need an amendment to activate.

    -

    +

    Design

    This section discusses the following topics about the Negative UNL design:

      @@ -146,16 +146,16 @@ Design
    • Filter validation messages
    • High level sequence diagram of code changes
    -

    +

    Negative UNL Protocol Overview

    Every ledger stores a list of zero or more unreliable validators. Updates to the list must be approved by the validators using the consensus mechanism that validators use to agree on the set of transactions. The list is used only when checking if a ledger is fully validated. If a validator V is in the list, nodes with V in their UNL adjust the quorum and V’s validation message is not counted when verifying if a ledger is fully validated. V’s flow of messages and network interactions, however, will remain the same.

    We define the effective UNL** = original UNL - negative UNL*, and the ***effective quorum as the quorum of the effective UNL. And we set effective quorum = Ceiling(80% * effective UNL).

    -

    +

    Validator Reliability Measurement

    A node only measures the reliability of validators on its own UNL, and only proposes based on local observations. There are many metrics that a node can measure about its validators, but we have chosen ledger validation messages. This is because every validator shall send one and only one signed validation message per ledger. This keeps the measurement simple and removes timing/clock-sync issues. A node will measure the percentage of agreeing validation messages (PAV) received from each validator on the node's UNL. Note that the node will only count the validation messages that agree with its own validations.

    We define the PAV as the **P**ercentage of **A**greed **V**alidation messages received for the last N ledgers, where N = 256 by default.

    When the PAV drops below the low-water mark, the validator is considered unreliable, and is a candidate to be disabled by being added to the negative UNL. A validator must have a PAV higher than the high-water mark to be re-enabled. The validator is re-enabled by removing it from the negative UNL. In the implementation, we plan to set the low-water mark as 50% and the high-water mark as 80%.

    -

    +

    Format Changes

    The negative UNL component in a ledger contains three fields.

    • NegativeUNL: The current negative UNL, a list of unreliable validators.
      • @@ -169,7 +169,7 @@ Format Changes
    • Validator: The validator to be disabled or re-enabled.

    There would be at most one disable UNLModify and one re-enable UNLModify transaction per flag ledger. The full machinery is described further on.

    -

    +

    Negative UNL Maintenance

    The negative UNL can only be modified on the flag ledgers. If a validator's reliability status changes, it takes two flag ledgers to modify the negative UNL. Let's see an example of the algorithm:

      @@ -229,13 +229,13 @@ Else clear `ToDisable`.

      The negative UNL is stored on each ledger because we don't know when a validator may reconnect to the network. If the negative UNL was stored only on every flag ledger, then a new validator would have to wait until it acquires the latest flag ledger to know the negative UNL. So any new ledgers created that are not flag ledgers copy the negative UNL from the parent ledger.

      Note that when we have a validator to disable and a validator to re-enable at the same flag ledger, we create two separate UNLModify pseudo-transactions. We want either one or the other or both to make it into the ledger on their own merits.

      Readers may have noticed that we defined several rules of creating the UNLModify pseudo-transactions but did not describe how to enforce the rules. The rules are actually enforced by the existing consensus algorithm. Unless enough validators propose the same pseudo-transaction it will not be included in the transaction set of the ledger.

      -

      +

      Quorum Size Calculation

      The effective quorum is 80% of the effective UNL. Note that because at most 25% of the original UNL can be on the negative UNL, the quorum should not be lower than the absolute minimum quorum (i.e. 60%) of the original UNL. However, considering that different nodes may have different UNLs, to be safe we compute quorum = Ceiling(max(60% * original UNL, 80% * effective UNL)).

      -

      +

      Filter Validation Messages

      If a validator V is in the negative UNL, it still participates in consensus sessions in the same way, i.e. V still follows the protocol and publishes proposal and validation messages. The messages from V are still stored the same way by everyone, used to calculate the new PAV for V, and could be used in future consensus sessions if needed. However V's ledger validation message is not counted when checking if the ledger is fully validated.

      -

      +

      High Level Sequence Diagram of Code Changes

      The diagram below is the sequence of one round of consensus. Classes and components with non-trivial changes are colored green.

        @@ -250,19 +250,19 @@ High Level Sequence Diagram of Code Changes

      Sequence diagram

      -

      +

      Roads Not Taken

      -

      +

      Use a Mechanism Like Fee Voting to Process UNLModify Pseudo-Transactions

      The previous version of the negative UNL specification used the same mechanism as the fee voting for creating the negative UNL, and used the negative UNL as soon as the ledger was fully validated. However the timing of fully validation can differ among nodes, so different negative UNLs could be used, resulting in different effective UNLs and different quorums for the same ledger. As a result, the network's safety is impacted.

      This updated version does not impact safety though operates a bit more slowly. The negative UNL modifications in the UNLModify pseudo-transaction approved by the consensus will take effect at the next flag ledger. The extra time of the 256 ledgers should be enough for nodes to be in sync of the negative UNL modifications.

      -

      +

      Use an Expiration Approach to Re-enable Validators

      After a validator disabled by the negative UNL becomes reliable, other validators explicitly vote for re-enabling it. An alternative approach to re-enable a validator is the expiration approach, which was considered in the previous version of the specification. In the expiration approach, every entry in the negative UNL has a fixed expiration time. One flag ledger interval was chosen as the expiration interval. Once expired, the other validators must continue voting to keep the unreliable validator on the negative UNL. The advantage of this approach is its simplicity. But it has a requirement. The negative UNL protocol must be able to vote multiple unreliable validators to be disabled at the same flag ledger. In this version of the specification, however, only one unreliable validator can be disabled at a flag ledger. So the expiration approach cannot be simply applied.

      -

      +

      Validator Reliability Measurement and Flag Ledger Frequency

      If the ledger time is about 4.5 seconds and the low-water mark is 50%, then in the worst case, it takes 48 minutes *((0.5 * 256 + 256 + 256) * 4.5 / 60 = 48)* to put an offline validator on the negative UNL. We considered lowering the flag ledger frequency so that the negative UNL can be more responsive. We also considered decoupling the reliability measurement and flag ledger frequency to be more flexible. In practice, however, their benefits are not clear.

      -

      +

      New Attack Vectors

      A group of malicious validators may try to frame a reliable validator and put it on the negative UNL. But they cannot succeed. Because:

        @@ -275,7 +275,7 @@ New Attack Vectors
      1. A validator can be added to a negative UNL only through a UNLModify transaction.

      Assuming the group of malicious validators is less than the quorum, they cannot frame a reliable validator.

      -

      +

      Summary

      The bullet points below briefly summarize the current proposal:

        @@ -291,19 +291,19 @@ Summary
      • The quorum is the larger of 80% of the effective UNL and 60% of the original UNL.
      • If a validator is on the negative UNL, its validation messages are ignored when the local node verifies if a ledger is fully validated.
      -

      +

      FAQ

      -

      +

      Question: What are UNLs?

      Quote from the Technical FAQ: "They are the lists of transaction validators a given participant believes will not conspire to defraud them."

      -

      +

      Question: How does the negative UNL proposal affect network liveness?

      The network can make forward progress when more than a quorum of the trusted validators agree with the progress. The lower the quorum size is, the easier for the network to progress. If the quorum is too low, however, the network is not safe because nodes may have different results. So the quorum size used in the consensus protocol is a balance between the safety and the liveness of the network. The negative UNL reduces the size of the effective UNL, resulting in a lower quorum size while keeping the network safe.

      Question: How does a validator get into the negative UNL? How is a validator removed from the negative UNL?

      A validator’s reliability is measured by other validators. If a validator becomes unreliable, at a flag ledger, other validators propose UNLModify pseudo-transactions which vote the validator to add to the negative UNL during the consensus session. If agreed, the validator is added to the negative UNL at the next flag ledger. The mechanism of removing a validator from the negative UNL is the same.

      -

      +

      Question: Given a negative UNL, what happens if the UNL changes?

      Answer: Let’s consider the cases:

        @@ -324,7 +324,7 @@ Question: Given a negative UNL, what happens if the UNL changes?

        Case 3 and 4 are not affected by the negative UNL protocol.

      -

      +

      Question: Can we simply lower the quorum to 60% without the negative UNL?

      Answer: No, because the negative UNL approach is safer.

      First let’s compare the two approaches intuitively, (1) the negative UNL approach, and (2) lower quorum: simply lowering the quorum from 80% to 60% without the negative UNL. The negative UNL approach uses consensus to come up with a list of unreliable validators, which are then removed from the effective UNL temporarily. With this approach, the list of unreliable validators is agreed to by a quorum of validators and will be used by every node in the network to adjust its UNL. The quorum is always 80% of the effective UNL. The lower quorum approach is a tradeoff between safety and liveness and against our principle of preferring safety over liveness. Note that different validators don't have to agree on which validation sources they are ignoring.

      @@ -368,9 +368,9 @@ Question: Can we simply lower the quorum to 60% without the negative UNL?

      In general by measuring the agreement of validations, we also measured the "sanity". If two validators have too many disagreements, one of them could be insane. When enough validators think a validator is insane, that validator is put on the negative UNL.

      Question: Why would there be at most one disable UNLModify and one re-enable UNLModify transaction per flag ledger?

      Answer: It is a design choice so that the effective UNL does not change too quickly. A typical targeted scenario is several validators go offline slowly during a long weekend. The current design can handle this kind of cases well without changing the effective UNL too quickly.

      -

      +

      Appendix

      -

      +

      Confidence Test

      We will use two test networks, a single machine test network with multiple IP addresses and the QE test network with multiple machines. The single machine network will be used to test all the test cases and to debug. The QE network will be used after that. We want to see the test cases still pass with real network delay. A test case specifies:

        @@ -398,7 +398,7 @@ Confidence Test
        1. A sequence of events (or the lack of events) such as a killed validator is added to the negative UNL.
        -

        +

        Roads Not Taken: Test with Extended CSF

        We considered testing with the current unit test framework, specifically the Consensus Simulation Framework (CSF). However, the CSF currently can only test the generic consensus algorithm as in the paper: Analysis of the XRP Ledger Consensus Protocol.

    diff --git a/md____w_rippled_rippled_docs_0010_ledger_replay_README.html b/md____w_rippled_rippled_docs_0010_ledger_replay_README.html index b3e8d2e1bd..260f4a9af8 100644 --- a/md____w_rippled_rippled_docs_0010_ledger_replay_README.html +++ b/md____w_rippled_rippled_docs_0010_ledger_replay_README.html @@ -107,10 +107,10 @@ $(function() {
  • onTimer()

    • Each of these entry points does something unique to that entry point. They either (a) transition LedgerReplayTask to a terminal failed resolved state (cancel() and onTimer()) or (b) try to make progress toward the successful resolved state. init() and updateSkipList(...) call trigger() while deltaReady(...) calls tryAdvance(). There's a similarity between this pattern and the way coroutines are implemented, where every yield saves the spot in the code where it left off and every resume jumps back to that spot.

    -

    +

    Sequence Diagram

    Sequence diagram

    -

    +

    Class Diagram

    Class diagram

    diff --git a/md____w_rippled_rippled_docs_CheatSheet.html b/md____w_rippled_rippled_docs_CheatSheet.html index 2d2d6444d2..df33daa1c8 100644 --- a/md____w_rippled_rippled_docs_CheatSheet.html +++ b/md____w_rippled_rippled_docs_CheatSheet.html @@ -72,7 +72,7 @@ $(function() {
    Code Style Cheat Sheet
    -

    +

    Form

    • One class per header file.
      • @@ -86,7 +86,7 @@ Form

  • Order class declarations as types, public, protected, private, then data.
  • Prefer 'private' over 'protected'
    • -

    +

    Function

    • Minimize external dependencies
        diff --git a/md____w_rippled_rippled_docs_CodingStyle.html b/md____w_rippled_rippled_docs_CodingStyle.html index 176b3b5a57..404cc6cf36 100644 --- a/md____w_rippled_rippled_docs_CodingStyle.html +++ b/md____w_rippled_rippled_docs_CodingStyle.html @@ -73,7 +73,7 @@ $(function() {

    Coding standards used here gradually evolve and propagate through code reviews. Some aspects are enforced more strictly than others.

    -

    +

    Rules

    These rules only apply to our own code. We can't enforce any sort of style on the external repositories and libraries we include. The best guideline is to maintain the standards that are used in those libraries.

      @@ -82,7 +82,7 @@ Rules
    • Modern C++ principles. No naked new or delete.
    • Line lengths limited to 80 characters. Exceptions limited to data and tables.
    -

    +

    Guidelines

    If you want to do something contrary to these guidelines, understand why you're doing it. Think, use common sense, and consider that this your changes will probably need to be maintained long after you've moved on to other projects.

      @@ -98,7 +98,7 @@ Guidelines
    • Don't over-inline by defining large functions within the class declaration, not even for template classes.
    -

    +

    Formatting

    The goal of source code formatting should always be to make things as easy to read as possible. White space is used to guide the eye so that details are not overlooked. Blank lines are used to separate code into "paragraphs."

      diff --git a/md____w_rippled_rippled_docs_HeapProfiling.html b/md____w_rippled_rippled_docs_HeapProfiling.html index fb94d09f80..912206fd23 100644 --- a/md____w_rippled_rippled_docs_HeapProfiling.html +++ b/md____w_rippled_rippled_docs_HeapProfiling.html @@ -75,12 +75,12 @@ $(function() {

      The jemalloc library provides a good API for doing heap analysis, including a mechanism to dump a description of the heap from within the running application via a function call. Details on how to perform this activity in general, as well as how to acquire the software, are available on the jemalloc site: https://github.com/jemalloc/jemalloc/wiki/Use-Case:-Heap-Profiling

      jemalloc is acquired separately from rippled, and is not affiliated with Ripple Labs. If you compile and install jemalloc from the source release with default options, it will install the library and header under /usr/local/lib and /usr/local/include, respectively. Heap profiling has been tested with rippled on a Linux platform. It should work on platforms on which both rippled and jemalloc are available.

      To link rippled with jemalloc, the argument profile-jemalloc=<jemalloc_dir> is provided after the optional target. The <jemalloc_dir> argument should be the same as that of the --prefix parameter passed to the jemalloc configure script when building.

      -

      +

      Examples:

      Build rippled with jemalloc library under /usr/local/lib and header under /usr/local/include: 

      $ scons profile-jemalloc=/usr/local

      Build rippled using clang with the jemalloc library under /opt/local/lib and header under /opt/local/include: 

      $ scons clang profile-jemalloc=/opt/local
      -

      +

      Using the jemalloc library from within the code

      The profile-jemalloc parameter enables a macro definition called PROFILE_JEMALLOC. Include the jemalloc header file as well as the api call(s) that you wish to make within preprocessor conditional groups, such as:

      In global scope: 

      #ifdef PROFILE_JEMALLOC
diff --git a/md____w_rippled_rippled_docs_README.html b/md____w_rippled_rippled_docs_README.html
index dba1f0f14f..dc00662742 100644
--- a/md____w_rippled_rippled_docs_README.html
+++ b/md____w_rippled_rippled_docs_README.html
@@ -72,7 +72,7 @@ $(function() {
   
      Building documentation
      -

      +

      Dependencies

      Install these dependencies:

        @@ -95,7 +95,7 @@ Dependencies

    -

    +

    Docker

    Instead of installing the above dependencies locally, you can use the official build environment Docker image, which has all of them installed already.

      @@ -105,7 +105,7 @@ Docker
    1. Run the image from the project folder:
      sudo docker run -v $PWD:/opt/rippled --rm rippleci/rippled-ci-builder:2944b78d22db
    -

    +

    Build

    There is a docs target in the CMake configuration.

    mkdir build
    diff --git a/md____w_rippled_rippled_docs_build_conan.html b/md____w_rippled_rippled_docs_build_conan.html index 26cd26015a..1a2213e995 100644 --- a/md____w_rippled_rippled_docs_build_conan.html +++ b/md____w_rippled_rippled_docs_build_conan.html @@ -73,7 +73,7 @@ $(function() {

    To better understand how to use Conan, we should first understand why we use Conan, and to understand that, we need to understand how we use CMake.

    -

    +

    CMake

    Technically, you don't need CMake to build this project. You could manually compile every translation unit into an object file, using the right compiler options, and then manually link all those objects together, using the right linker options. However, that is very tedious and error-prone, which is why we lean on tools like CMake.

    We have written CMake configuration files (CMakeLists.txt and friends) for this project so that CMake can be used to correctly compile and link all of the translation units in it. Or rather, CMake will generate files for a separate build system (e.g. Make, Ninja, Visual Studio, Xcode, etc.) that compile and link all of the translation units. Even then, CMake has parameters, some of which are platform-specific. In CMake's parlance, parameters are specially-named variables like CMAKE_BUILD_TYPE or CMAKE_MSVC_RUNTIME_LIBRARY. Parameters include:

    @@ -87,7 +87,7 @@ CMake

    For some of these parameters, like the build system and compiler, CMake goes through a complicated search process to choose default values. For others, like the dependencies, we had written in the CMake configuration files of this project our own complicated process to choose defaults. For most developers, things "just worked"... until they didn't, and then you were left trying to debug one of these complicated processes, instead of choosing and manually passing the parameter values yourself.

    You can pass every parameter to CMake on the command line, but writing out these parameters every time we want to configure CMake is a pain. Most humans prefer to put them into a configuration file, once, that CMake can read every time it is configured. For CMake, that file is a toolchain file.

    -

    +

    Conan

    These next few paragraphs on Conan are going to read much like the ones above for CMake.

    Technically, you don't need Conan to build this project. You could manually download, configure, build, and install all of the dependencies yourself, and then pass all of the parameters necessary for CMake to link to those dependencies. To guarantee ABI compatibility, you must be sure to use the same set of compiler and linker options for all dependencies and this project. However, that is very tedious and error-prone, which is why we lean on tools like Conan.

    diff --git a/md____w_rippled_rippled_docs_build_depend.html b/md____w_rippled_rippled_docs_build_depend.html index 0d8fc8a4f4..2d946943d4 100644 --- a/md____w_rippled_rippled_docs_build_depend.html +++ b/md____w_rippled_rippled_docs_build_depend.html @@ -73,7 +73,7 @@ $(function() {

    We recommend two different methods to depend on libxrpl in your own CMake project. Both methods add a CMake library target named xrpl::libxrpl.

    -

    +

    Conan requirement

    The first method adds libxrpl as a Conan requirement. With this method, there is no need for a Git submodule. It is good for when you just need a dependency on libxrpl as-is.

    # This conanfile.txt is just an example.
    @@ -103,7 +103,7 @@ Conan requirement
    -DCMAKE_BUILD_TYPE=Release \
    ..
    cmake --build . --parallel
    -

    +

    CMake subdirectory

    The second method adds the rippled project as a CMake subdirectory. This method works well when you keep the rippled project as a Git submodule. It's good for when you want to make changes to libxrpl as part of your own project. Be careful, though. Your project will inherit all of the same CMake options, so watch out for name collisions. We still recommend using Conan to download, build, and connect dependencies.

    # Add the project as a Git submodule.
    diff --git a/md____w_rippled_rippled_docs_build_environment.html b/md____w_rippled_rippled_docs_build_environment.html index 190832eb4d..464234994e 100644 --- a/md____w_rippled_rippled_docs_build_environment.html +++ b/md____w_rippled_rippled_docs_build_environment.html @@ -73,7 +73,7 @@ $(function() {

    Our build instructions assume you have a C++ development environment complete with Git, Python, Conan, CMake, and a C++ compiler. This document exists to help readers set one up on any of the Big Three platforms: Linux, macOS, or Windows.

    -

    +

    Linux

    Package ecosystems vary across Linux distributions, so there is no one set of instructions that will work for every Linux user. These instructions are written for Ubuntu 22.04. They are largely copied from the script used to configure our Docker container for continuous integration. That script handles many more responsibilities. These instructions are just the bare minimum to build one configuration of rippled. You can check that codebase for other Linux distributions and versions. If you cannot find yours there, then we hope that these instructions can at least guide you in the right direction.

    apt update
    @@ -91,7 +91,7 @@ Linux
    pipx install 'conan<2'
    pipx ensurepath
    -

    +

    macOS

    Open a Terminal and enter the below command to bring up a dialog to install the command line developer tools. Once it is finished, this command should return a version greater than the minimum required (see BUILD.md).

    clang --version
    diff --git a/md____w_rippled_rippled_docs_build_install.html b/md____w_rippled_rippled_docs_build_install.html index 9d053fd4a9..22f6313196 100644 --- a/md____w_rippled_rippled_docs_build_install.html +++ b/md____w_rippled_rippled_docs_build_install.html @@ -73,12 +73,12 @@ $(function() {

    This document contains instructions for installing rippled. The APT package manager is common on Debian-based Linux distributions like Ubuntu, while the YUM package manager is common on Red Hat-based Linux distributions like CentOS. Installing from source is an option for all platforms, and the only supported option for installing custom builds.

    -

    +

    From source

    From a source build, you can install rippled and libxrpl using CMake's --install mode:

    cmake --install . --prefix /opt/local

    The default prefix is typically /usr/local on Linux and macOS and C:/Program Files/rippled on Windows.

    -

    +

    With the APT package manager

    1. Update repositories: 
       sudo apt update -y
@@ -124,7 +124,7 @@ sub   rsa3072 2019-02-14 [E] [expires: 2026-02-17]
 
      This allows you to serve incoming API requests on port 80 or 443. (If you want to do so, you must also update the config file's port settings.) 
      sudo setcap 'cap_net_bind_service=+ep' /opt/ripple/bin/rippled
    -

    +

    With the YUM package manager

    1. Install the Ripple RPM repository:

      diff --git a/md____w_rippled_rippled_docs_consensus.html b/md____w_rippled_rippled_docs_consensus.html index 68587f991a..16f4d0cdd0 100644 --- a/md____w_rippled_rippled_docs_consensus.html +++ b/md____w_rippled_rippled_docs_consensus.html @@ -74,7 +74,7 @@ $(function() {

      This section is a work in progress!!

      Consensus is the task of reaching agreement within a distributed system in the presence of faulty or even malicious participants. This document outlines the XRP Ledger Consensus Algorithm as implemented in rippled, but focuses on its utility as a generic consensus algorithm independent of the detailed mechanics of the Ripple Consensus Ledger. Most notably, the algorithm does not require fully synchronous communication between all nodes in the network, or even a fixed network topology, but instead achieves consensus via collectively trusted subnetworks.

      -

      +

      Distributed Agreement

      A challenge for distributed systems is reaching agreement on changes in shared state. For the Ripple network, the shared state is the current ledger–account information, account balances, order books and other financial data. We will refer to shared distributed state as a /ledger/ throughout the remainder of this document.

      @@ -94,9 +94,9 @@ Ledger Chain
      Block Chain

      The remainder of this section describes the Consensus and Validation algorithms in more detail and is meant as a companion guide to understanding the generic implementation in rippled. The document does not discuss correctness, fault-tolerance or liveness properties of the algorithms or the full details of how they integrate within rippled to support the Ripple Consensus Ledger.

      -

      +

      Consensus Overview

      -

      +

      Definitions

      • The ledger is the shared distributed state. Each ledger has a unique ID to distinguish it from all other ledgers. During consensus, the previous, prior or last-closed ledger is the most recent ledger seen by consensus and is the basis upon which it will build the next ledger.
        • @@ -109,7 +109,7 @@ Definitions
      • A dispute is a transaction that is either not part of a node's position or not in a peer's position. During consensus, the node will add or remove disputed transactions from its position based on that transaction's support amongst its peers.

      Note that most types have an ID as a lightweight identifier of instances of that type. Consensus often operates on the IDs directly since the underlying type is potentially expensive to share over the network. For example, proposal's only contain the ID of the position of a peer. Since many peers likely have the same position, this reduces the need to send the full transaction set multiple times. Instead, a node can request the transaction set from the network if necessary.

      -

      +

      Overview

      @@ -132,7 +132,7 @@ Effective Close Time Effective Close Time

    The effective close time is part of the node's position and is shared with peers in its proposals. Just like the position on the consensus transaction set, a node will update its close time position in response to its peers' effective close time positions. Peers can agree to disagree on the close time, in which case the effective close time is taken as 1 second past the prior close.

    The close time resolution is itself dynamic, decreasing (coarser) resolution in subsequent consensus rounds if nodes are unable to reach consensus on an effective close time and increasing (finer) resolution if nodes consistently reach close time consensus.

    -

    +

    Modes

    Internally, a node operates under one of the following consensus modes. Either of the first two modes may be chosen when a consensus round starts.

      @@ -150,7 +150,7 @@ Modes Consensus Modes

    Once either wrong ledger or switch ledger are reached, the node cannot return to proposing or observing until the next consensus round. However, the node could change its view of the correct prior ledger, so going from switch ledger to wrong ledger and back again is possible.

    The distinction between the wrong and switched ledger modes arises because a ledger's unique identifier may be known by a node before the ledger itself. This reflects that fact that the data corresponding to a ledger may be large and take time to share over the network, whereas the smaller ID could be shared in a peer validation much more quickly. Distinguishing the two states allows the node to decide how best to generate the next ledger once it declares consensus.

    -

    +

    Phases

    As depicted in the overview diagram, consensus is best viewed as a progression through 3 phases. There are 4 public methods of the generic consensus algorithm that determine this progression

      @@ -160,12 +160,12 @@ Phases
    • gotTxSet is called when a transaction set is received from the network. This is typically in response to a prior request from the node to acquire the transaction set corresponding to a disagreeing peer's position.

    The following subsections describe each consensus phase in more detail and what actions are taken in response to these calls.

    -

    +

    Open

    The Open phase is a quiescent period to allow transactions to build up in the node's open ledger. The duration is a trade-off between latency and throughput. A shorter window reduces the latency to generating the next ledger, but also reduces transaction throughput due to fewer transactions accepted into the ledger.

    A call to startRound would forcibly begin the next consensus round, skipping completion of the current round. This is not expected during normal operation. Calls to peerProposal or gotTxSet simply store the proposal or transaction set for use in the coming Establish phase.

    A call to timerEntry first checks that the node is working on the correct prior ledger. If not, it will update the mode and request the correct ledger. Otherwise, the node checks whether to switch to the Establish phase and close the ledger.

    -

    +

    Ledger Close

    Under normal circumstances, the open ledger period ends when one of the following is true

      @@ -181,12 +181,12 @@ disputes
      Disputes
    -

    +

    Establish

    The establish phase is the active period of consensus in which the node exchanges proposals with peers in an attempt to reach agreement on the consensus transactions and effective close time.

    A call to startRound would forcibly begin the next consensus round, skipping completion of the current round. This is not expected during normal operation. Calls to peerProposal or gotTxSet that reflect new positions will generate disputed transactions for any new disagreements and will update the peer's vote for all disputed transactions.

    A call to timerEntry first checks that the node is working from the correct prior ledger. If not, the node will update the mode and request the correct ledger. Otherwise, the node updates the node's position and considers whether to switch to the Accepted phase and declare consensus reached. However, at least LEDGER_MIN_CONSENSUS time must have elapsed before doing either. This allows peers an opportunity to take an initial position and share it.

    -

    +

    Update Position

    In order to achieve consensus, the node is looking for a transaction set that is supported by a super-majority of peers. The node works towards this set by adding or removing disputed transactions from its position based on an increasing threshold for inclusion.

    @@ -197,7 +197,7 @@ Threshold

    Given the example disputes above and an initial threshold of 50%, our node would retain its position since transaction 1 was not in dispute and transactions 2 and 3 have 75% support. Since its position did not change, it would not need to send a new proposal to peers. Peer C would not change either. Peer A would add transaction 3 to its position and Peer B would remove transaction 4 from its position; both would then send an updated position.

    Conversely, if the diagram reflected a later call to =timerEntry= that occurs in the stuck region with a threshold of say 95%, our node would remove transactions 2 and 3 from its candidate set and send an updated position. Likewise, all the other peers would end up with only transaction 1 in their position.

    Lastly, if our node were not in the proposing mode, it would not include its own vote and just take the majority (>50%) position of its peers. In this example, our node would maintain its position of transactions 1, 2 and 3.

    -

    +

    Checking Consensus

    After updating its position, the node checks for supermajority agreement with its peers on its current position. This agreement is of the exact transaction set, not just the support of individual transactions. That is, if our position is a subset of a peer's position, that counts as a disagreement. Also recall that effective close time agreement allows a supermajority of participants agreeing to disagree.

    Consensus is declared when the following 3 clauses are true:

    @@ -208,16 +208,16 @@ Checking Consensus

    The middle condition ensures slower peers have a chance to share positions, but prevents waiting too long on peers that have disconnected. Additionally, a node can declare that consensus has moved on if minimumConsensusPercentage peers have sent validations and moved on to the next ledger. This outcome indicates the node has fallen behind its peers and needs to catch up.

    If a node is not proposing, it does not include its own position when calculating the percent of agreeing participants but otherwise follows the above logic.

    -

    +

    Accepting Consensus

    Once consensus is reached (or moved on), the node switches to the Accept phase and signals to the implementing code that the round is complete. That code is responsible for using the consensus transaction set to generate the next ledger and calling startRound to begin the next round. The implementation has total freedom on ordering transactions, deciding what to do if consensus moved on, determining whether to retry or abandon local transactions that did not make the consensus set and updating any internal state based on the consensus progress.

    -

    +

    Accept

    The Accept phase is the terminal phase of the consensus algorithm. Calls to timerEntry, peerProposal and gotTxSet will not change the internal consensus state while in the accept phase. The expectation is that the application specific code is working to generate the new ledger based on the consensus outcome. Once complete, that code should make a call to startRound to kick off the next consensus round. The startRound call includes the new prior ledger, prior ledger ID and whether the round should begin in the proposing or observing mode. After setting some initial state, the phase transitions to Open. The node will also check if the provided prior ledger and ID are correct, updating the mode and requesting the proper ledger from the network if necessary.

    -

    +

    Consensus Type Requirements

    The consensus type requirements are given below as minimal implementation stubs. Actual implementations would augment these stubs with members appropriate for managing the details of transactions and ledgers within the larger application framework.

    -

    +

    Transaction

    The transaction type Tx encapsulates a single transaction under consideration by consensus.

    struct Tx
    @@ -227,7 +227,7 @@ Transaction
    //... implementation specific
    };
    -

    +

    Transaction Set

    The transaction set type TxSet represents a set of Txs that are collectively under consideration by consensus. A TxSet can be compared against other TxSets (typically from peers) and can be modified to add or remove transactions via the mutable subtype.

    struct TxSet
    @@ -261,7 +261,7 @@ Transaction Set
    //... implementation specific
    };
    -

    +

    Ledger

    The Ledger type represents the state shared amongst the distributed participants. Notice that the details of how the next ledger is generated from the prior ledger and the consensus accepted transaction set is not part of the interface. Within the generic code, this type is primarily used to know that peers are working on the same tip of the ledger chain and to provide some basic timing data for consensus.

    struct Ledger
    @@ -292,7 +292,7 @@ Ledger
    //... implementation specific
    };
    Json::Value
    Represents a JSON value.
    Definition: json_value.h:149
    -

    +

    PeerProposal

    The PeerProposal type represents the signed position taken by a peer during consensus. The only type requirement is owning an instance of a generic ConsensusProposal.

    // Represents our proposed position or a peer's proposed position
    @@ -309,7 +309,7 @@ PeerProposal
    // ... implementation specific
    };
    -

    +

    Generic Consensus Interface

    The generic Consensus relies on Adaptor template class to implement a set of helper functions that plug the consensus algorithm into a specific application. The Adaptor class also defines the types above needed by the algorithm. Below are excerpts of the generic consensus implementation and of helper types that will interact with the concrete implementing class.

    // Represents a transction under dispute this round
    @@ -384,7 +384,7 @@ Generic Consensus Interface
    ripple::hash_map
    std::unordered_map< Key, Value, Hash, Pred, Allocator > hash_map
    Definition: UnorderedContainers.h:54
    ripple::set
    bool set(T &target, std::string const &name, Section const &section)
    Set a value from a configuration Section If the named value is not found or doesn't parse as a T,...
    Definition: BasicConfig.h:315
    ripple::ConsensusState
    ConsensusState
    Whether we have or don't have a consensus.
    Definition: ConsensusTypes.h:188
    -

    +

    Adapting Generic Consensus

    The stub below shows the set of callback/helper functions required in the implementing class.

    struct Adaptor
    @@ -452,7 +452,7 @@ Adapting Generic Consensus
  • The generic code does not specify how transactions are submitted by clients, propagated through the network or stored in the open ledger. Indeed, the open ledger is only conceptual from the perspective of the generic code—the initial position and transaction set are opaquely generated in a Consensus::Result instance returned from the onClose callback.
  • The calls to acquireLedger and acquireTxSet only have non-trivial return if the ledger or transaction set of interest is available. The implementing class is free to block while acquiring, or return the empty option while servicing the request asynchronously. Due to legacy reasons, the two calls are not symmetric. acquireTxSet requires the host application to call gotTxSet when an asynchronous acquire completes. Conversely, acquireLedger will be called again later by the consensus code if it still desires the ledger with the hope that the asynchronous acquisition is complete.
    • -

    +

    Validation

    Coming Soon!

    diff --git a/md____w_rippled_rippled_include_xrpl_basics_README.html b/md____w_rippled_rippled_include_xrpl_basics_README.html index 2ac4cb1114..d3c1623983 100644 --- a/md____w_rippled_rippled_include_xrpl_basics_README.html +++ b/md____w_rippled_rippled_include_xrpl_basics_README.html @@ -74,7 +74,7 @@ $(function() {

    Utility functions and classes.

    ripple/basic should contain no dependencies on other modules.

    -

    +

    Choosing a rippled container.

    • std::vector
        diff --git a/md____w_rippled_rippled_include_xrpl_proto_org_xrpl_rpc_v1_README.html b/md____w_rippled_rippled_include_xrpl_proto_org_xrpl_rpc_v1_README.html index 8da3b9a7c0..44df22bef9 100644 --- a/md____w_rippled_rippled_include_xrpl_proto_org_xrpl_rpc_v1_README.html +++ b/md____w_rippled_rippled_include_xrpl_proto_org_xrpl_rpc_v1_README.html @@ -73,26 +73,26 @@ $(function() {

    This folder contains the protocol buffer definitions used by the rippled gRPC API. The gRPC API attempts to mimic the JSON/Websocket API as much as possible. As of April 2020, the gRPC API supports a subset of the full rippled API: tx, account_tx, account_info, fee and submit.

    -

    +

    Making Changes

    -

    +

    Wire Format and Backwards Compatibility

    When making changes to the protocol buffer definitions in this folder, care must be taken to ensure the changes do not break the wire format, which would break backwards compatibility. At a high level, do not change any existing fields. This includes the field's name, type and field number. Do not remove any existing fields. It is always safe to add fields; just remember to give each of the new fields a unique field number. The field numbers don't have to be in any particular order and there can be gaps. More info about what changes break the wire format can be found here.

    -

    +

    Conventions

    For fields that are reused across different message types, we define the field as a unique message type in common.proto. The name of the message type is the same as the field name, with the exception that the field name itself is snake case, whereas the message type is in Pascal case. The message type has one field, called value. This pattern does not need to be strictly followed across the entire API, but should be followed for transactions and ledger objects, since there is a high rate of field reuse across different transactions and ledger objects. The motivation for this pattern is two-fold. First, we ensure the field has the same type everywhere that the field is used. Second, wrapping primitive types in their own message type prevents default initialization of those primitive types. For example, uint32 is initialized to 0 if not explicitly set; there is no way to tell if the client or server set the field to 0 (which may be a valid value for the field) or the field was default initialized.

    -

    +

    Name Collisions

    Each message type must have a unique name. To resolve collisions, add a suffix to one or more message types. For instance, ledger objects and transaction types often have the same name (DepositPreauth for example). To resolve this, the DepositPreauth ledger object is named DepositPreauthObject.

    -

    +

    To add a field or message type

    To add a field to a message, define the fields type, name and unique index. To add a new message type, give the message type a unique name. Then, add the appropriate C++ code in GRPCHelpers.cpp, or in the handler itself, to serialize/deserialize the new field or message type.

    -

    +

    To add a new gRPC method

    To add a new gRPC method, add the gRPC method in xrp_ledger.proto. The method name should begin with a verb. Define the request and response types in their own file. The name of the request type should be the method name suffixed with Request, and the response type name should be the method name suffixed with Response. For example, the GetAccountInfo method has request type GetAccountInfoRequest and response type GetAccountInfoResponse.

    After defining the protobuf messages for the new method, add an instantiation of the templated CallData class in GRPCServerImpl::setupListeners(). The template parameters should be the request type and the response type.

    Finally, define the handler itself in the appropriate file under the src/ripple/rpc/handlers folder. If the method already has a JSON/Websocket equivalent, write the gRPC handler in the same file, and abstract common logic into helper functions (see Tx.cpp or AccountTx.cpp for an example).

    -

    +

    Testing

    When modifying an existing gRPC method, be sure to test that modification in the corresponding, existing unit test. When creating a new gRPC method, implement a class that derives from GRPCTestClientBase, and use the newly created class to call the new method. See the class GrpcTxClient in the file Tx_test.cpp for an example. The gRPC tests are paired with their JSON counterpart, and the tests should mirror the JSON test as much as possible.

    Refer to the Protocol Buffers language guide for more detailed information about Protocol Buffers.

    diff --git a/md____w_rippled_rippled_include_xrpl_protocol_README.html b/md____w_rippled_rippled_include_xrpl_protocol_README.html index 58d1f0ec43..6a46fd94b1 100644 --- a/md____w_rippled_rippled_include_xrpl_protocol_README.html +++ b/md____w_rippled_rippled_include_xrpl_protocol_README.html @@ -73,11 +73,11 @@ $(function() {

    Classes and functions for handling data and values associated with the XRP Ledger protocol.

    -

    +

    Serialized Objects

    Objects transmitted over the network must be serialized into a canonical format. The prefix "ST" refers to classes that deal with the serialized format.

    The term "Tx" or "tx" is an abbreviation for "Transaction", a commonly occurring object type.

    -

    +

    Optional Fields

    Our serialized fields have some "type magic" to make optional fields easier to read:

      @@ -91,7 +91,7 @@ Optional Fields

    Typically, for things that are guaranteed to exist, you use x[sfFoo] and avoid having to deal with a container that may or may not hold a value. For things not guaranteed to exist, you use x[~sfFoo] because you want such a container. It avoids having to look something up twice, once just to see if it exists and a second time to get/set its value. (Real example)

    The source of this "type magic" is in SField.h.

    -

    +

    Related Resources

    • ripple-binary-codec SField enums
      • diff --git a/md____w_rippled_rippled_include_xrpl_resource_README.html b/md____w_rippled_rippled_include_xrpl_resource_README.html index 1ebac2d263..a41b86bf07 100644 --- a/md____w_rippled_rippled_include_xrpl_resource_README.html +++ b/md____w_rippled_rippled_include_xrpl_resource_README.html @@ -79,14 +79,14 @@ $(function() {
    • Provide an interface to share load information in a cluster.
    • Warn and/or disconnect endpoints for imposing load.
    -

    +

    Description

    To prevent monopolization of server resources or attacks on servers, resource consumption is monitored at each endpoint. When consumption exceeds certain thresholds, costs are imposed. Costs could include charging additional XRP for transactions, requiring a proof of work to be performed, or simply disconnecting the endpoint.

    Currently, consumption endpoints include websocket connections used to service clients, and peer connections used to create the peer to peer overlay network implementing the Ripple protocol.

    The current "balance" of a Consumer represents resource consumption debt or credit. Debt is accrued when bad loads are imposed. Credit is granted when good loads are imposed. When the balance crosses heuristic thresholds, costs are increased on the endpoint. The balance is represented as a unitless relative quantity. This balance is currently held by the Entry struct in the impl/Entry.h file.

    Costs associated with specific transactions are defined in the impl/Fees files.

    Although RPC connections consume resources, they are transient and cannot be rate limited. It is advised not to expose RPC interfaces to the general public.

    -

    +

    Consumer Types

    Consumers are placed into three classifications (as identified by the Resource::Kind enumeration):

      @@ -95,15 +95,15 @@ Consumer Types
    • Admin

    Each caller determines for itself the classification of the Consumer it is creating.

    -

    +

    Resource Loading

    It is expected that a client will impose a higher load on the server when it first connects: the client may need to catch up on transactions it has missed, or get trust lines, or transfer fees. The Manager must expect this initial peak load, but not allow that high load to continue because over the long term that would unduly stress the server.

    If a client places a sustained high load on the server, that client is initially given a warning message. If that high load continues the Manager may tell the heavily loaded server to drop the connection entirely and not allow re-connection for some amount of time.

    Each load is monitored by capturing peaks and then decaying those peak values over time: this is implemented by the DecayingSample class.

    -

    +

    Gossip

    Each server in a cluster creates a list of IP addresses of end points that are imposing a significant load. This list is called Gossip, which is passed to other nodes in that cluster. Gossip helps individual servers in the cluster identify IP addreses that might be unduly loading the entire cluster. Again the recourse of the individual servers is to drop connections to those IP addresses that occur commonly in the gossip.

    -

    +

    Access

    In rippled, the Application holds a unique instance of Resource::Manager, which may be retrieved by calling the method Application::getResourceManager().

    diff --git a/md_test_README.html b/md_test_README.html index 8d8e14ad0c..c2c35b91fc 100644 --- a/md_test_README.html +++ b/md_test_README.html @@ -72,7 +72,7 @@ $(function() {
    Unit Tests
    -

    +

    Running Tests

    Unit tests are bundled in the rippled executable and can be executed using the --unittest parameter. Without any arguments to this option, all non-manual unit tests will be executed. If you want to run one or more manual tests, you must specify it by suite or full-name (e.g. ripple.app.NoRippleCheckLimits or just NoRippleCheckLimits).

    More than one suite or group of suites can be specified as a comma separated list via the argument. For example, --unittest=beast,OversizeMeta will run all suites in the beast library (root identifier) as well as the test suite named OversizeMeta). All name matches are case sensitive.

    diff --git a/md_test_csf_README.html b/md_test_csf_README.html index be93c6fe54..ffbd568927 100644 --- a/md_test_csf_README.html +++ b/md_test_csf_README.html @@ -73,7 +73,7 @@ $(function() {

    The Consensus Simulation Framework is a set of software components for describing, running and analyzing simulations of the consensus algorithm in a controlled manner. It is also used to unit test the generic Ripple consensus algorithm implementation. The framework is in its early stages, so the design and supported features are subject to change.

    -

    +

    Overview

    The simulation framework focuses on simulating the core consensus and validation algorithms as a discrete event simulation. It is completely abstracted from the details of the XRP ledger and transactions. In the simulation, a ledger is simply a set of observed integers and transactions are single integers. The consensus process works to agree on the set of integers to include in the next ledger.

    @@ -89,7 +89,7 @@ CSF Overview
  • Collectors that aggregate, filter and analyze data from the simulation. Typically, this is used to monitor invariants or generate reports.

    • Once specified, the simulation runs using a single Scheduler that manages the global clock and sequencing of activity. During the course of simulation, Peers generate Ledgers and Validations as a result of consensus, eventually fully validating the consensus history of accepted transactions. Each Peer also issues various Events during the simulation, which are analyzed by the registered Collectors.

    -

    +

    Example Simulation

    Below is a basic simulation we can walk through to get an understanding of the framework. This simulation is for a set of 5 validators that aren't directly connected but rely on a single hub node for communication.

    @@ -125,7 +125,7 @@ Example Sim
    std::cout << (simDur.stop - simDur.start).count() << std::endl;
    assert(sim.synchronized());
    -

    +

    <tt>Sim</tt> and <tt>PeerGroup</tt>

    {c++}
    Sim sim;
    @@ -135,7 +135,7 @@ Example Sim
    center[0]->runAsValidator = false;

    The simulation code starts by creating a single instance of the Sim class. This class is used to manage the overall simulation and internally owns most other components, including the Peers, Scheduler, BasicNetwork and TrustGraph. The next two lines create two differ PeerGroups of size 5 and 1 . A PeerGroup is a convenient way for configuring a set of related peers together and internally has a vector of pointers to the Peers which are owned by the Sim. PeerGroups can be combined using +/- operators to configure more complex relationships of nodes as shown by PeerGroup network. Note that each call to createGroup adds that many new Peers to the simulation, but does not specify any trust or network relationships for the new Peers.

    Lastly, the single Peer in the size 1 center group is switched from running as a validator (the default) to running as a tracking peer. The Peer class has a variety of configurable parameters that control how it behaves during the simulation.

    -

    +

    <tt>trust</tt> and <tt>connect</tt>

    {c++}
    validators.trust(validators);
    @@ -146,7 +146,7 @@ Example Sim
    validators.connect(center, delay);

    Although the sim object has accessible instances of TrustGraph and BasicNetwork, it is more convenient to manage the graphs via the PeerGroups. The first two lines create a trust topology in which all Peers trust the 5 validating Peers. Or in the UNL perspective, all Peers are configured with the same UNL listing the 5 validating Peers. The two lines could've been rewritten as network.trust(validators).

    The next lines create the network communication topology. Each of the validating Peers connects to the central hub Peer with a fixed delay of 200ms. Note that the network connections are really undirected, but are represented internally in a directed graph using edge pairs of inbound and outbound connections.

    -

    +

    Collectors

    {c++}
    SimDurationCollector simDur;
    @@ -155,14 +155,14 @@ Collectors

    Note that the collector lifetime is independent of the simulation and is added to the simulation by reference. This is intentional, since collectors might be used across several simulations to collect more complex combinations of data. At the end of the simulation, we print out the total duration by subtracting simDur members.

    {c++}
    std::cout << (simDur.stop - simDur.start).count() << std::endl;
    -

    +

    Transaction submission

    {c++}
    // everyone submits their own ID as a TX and relay it to peers
    for (Peer * p : validators)
    p->submit(Tx(static_cast<std::uint32_t>(p->id)));

    In this basic example, we explicitly submit a single transaction to each validator. For larger simulations, clients can use a Submitter to send transactions in at fixed or random intervals to fixed or random Peers.

    -

    +

    Run

    The example has two calls to sim.run(1). This call runs the simulation until each Peer has closed one additional ledger. After closing the additional ledger, the Peer stops participating in consensus. The first call is used to ensure a more useful prior state of all Peers. After the transaction submission, the second call to run results in one additional ledger that accepts those transactions.

    Alternatively, you can specify a duration to run the simulation, e.g. sim.run(10s) which would have Peers continuously run consensus until the scheduler has elapsed 10 additional seconds. The sim.scheduler.in or sim.scheduler.at methods can schedule arbitrary code to execute at a later time in the simulation, for example removing a network connection or modifying the trust graph.

    diff --git a/md_xrpld_app_ledger_README.html b/md_xrpld_app_ledger_README.html index d5aeffe4ef..4345e3e325 100644 --- a/md_xrpld_app_ledger_README.html +++ b/md_xrpld_app_ledger_README.html @@ -72,9 +72,9 @@ $(function() {
    Ledger Process
    -

    +

    Introduction

    -

    +

    Life Cycle

    Every server always has an open ledger. All received new transactions are applied to the open ledger. The open ledger can't close until we reach a consensus on the previous ledger, and either: there is at least one transaction in the open ledger, or the ledger's close time has been reached.

    When the open ledger is closed the transactions in the open ledger become the initial proposal. Validators will send the proposal (non-validators will simply not send the proposal). The open ledger contains the set of transactions the server thinks should go into the next ledger.

    @@ -85,17 +85,17 @@ Life Cycle

  • Forms the basis of the initial proposal during consensus
  • Used to decide if we can reject the transaction without relaying it
    • -

    +

    Byzantine Failures

    Byzantine failures are resolved as follows. If there is a supermajority ledger, then a minority of validators will discover that the consensus round is proceeding on a different ledger than they thought. These validators will become desynced, and switch to a strategy of trying to acquire the consensus ledger.

    If there is no majority ledger, then starting on the next consensus round there will not be a consensus on the last closed ledger. Another avalanche process is started.

    -

    +

    Validators

    The only meaningful difference between a validator and a 'regular' server is that the validator sends its proposals and validations to the network.

    -

    +

    The Ledger Stream

    -

    +

    Ledger Priorities

    There are two ledgers that are the most important for a rippled server to have:

      @@ -113,7 +113,7 @@ Ledger Priorities

      But loading or network connectivity may sometimes interfere with that ledger stream. So suppose the server publishes validated ledger 600 and then receives validated ledger 603. Then the server wants to back fill its ledger history with ledgers 601 and 602.

      The server prioritizes keeping up with current ledgers. But if it is caught up on the current ledger, and there are no higher priority demands on the server, then it will attempt to back fill its historical ledgers. It fills in the historical ledger data first by attempting to retrieve it from the local database. If the local database does not have all of the necessary data then the server requests the remaining information from network peers.

      Suppose the server is missing multiple historical ledgers. Take the previous example where we have ledgers 603 and 600, but we're missing 601 and 602. In that case the server requests information for ledger 602 first, before back-filling ledger 601. We want to expand the contiguous range of most-recent ledgers that the server has locally. There's also a limit to how much historical ledger data is useful. So if we're on ledger 603, but we're missing ledger 4 we may not bother asking for ledger 4.

      -

      +

      Assembling a Ledger

      When data for a ledger arrives from a peer, it may take a while before the server can apply that data. So when ledger data arrives we schedule a job thread to apply that data. If more data arrives before the job starts we add that data to the job. We defer requesting more ledger data until all of the data we have for that ledger has been processed. Once all of that data is processed we can intelligently request only the additional data that we need to fill in the ledger. This reduces network traffic and minimizes the load on peers supplying the data.

      If we receive data for a ledger that is not currently under construction, we don't just throw the data away. In particular the AccountStateNodes may be useful, since they can be re-used across ledgers. This data is stashed in memory (not the database) where the acquire process can find it.

      @@ -127,13 +127,13 @@ Assembling a Ledger

      Inner-most nodes are supplied before outer nodes. This allows the requesting server to hook things up (and validate) in the order in which data arrives.

      If this process fails, then a server can also ask for ledger data by hash, rather than by asking for specific nodes in a ledger. Asking for information by hash is less efficient, but it allows a peer to return the information even if the information is not assembled into a tree. All the peer needs is the raw data.

      -

      +

      Which Peer To Ask

      Peers go though state transitions as the network goes through its state transitions. Peer's provide their state to their directly connected peers. By monitoring the state of each connected peer a server can tell which of its peers has the information that it needs.

      Therefore if a server suffers a byzantine failure the server can tell which of its peers did not suffer that same failure. So the server knows which peer(s) to ask for the missing information.

      Peers also report their contiguous range of ledgers. This is another way that a server can determine which peer to ask for a particular ledger or piece of a ledger.

      There are also indirect peer queries. If there have been timeouts while acquiring ledger data then a server may issue indirect queries. In that case the server receiving the indirect query passes the query along to any of its peers that may have the requested data. This is important if the network has a byzantine failure. It also helps protect the validation network. A validator may need to get a peer set from one of the other validators, and indirect queries improve the likelihood of success with that.

      -

      +

      Kinds of Fetch Packs

      A FetchPack is the way that peers send partial ledger data to other peers so the receiving peer can reconstruct a ledger.

      A 'normal' FetchPack is a bucket of nodes indexed by hash. The server building the FetchPack puts information into the FetchPack that the destination server is likely to need. Normally they contain all of the missing nodes needed to fill in a ledger.

      @@ -147,36 +147,36 @@ Kinds of Fetch Packs
    • The index and new data of modified nodes in the state tree.
    -

    +

    Definitions

    -

    +

    Open Ledger

    The open ledger is the ledger that the server applies all new incoming transactions to.

    -

    +

    Last Validated Ledger

    The most recent ledger that the server is certain will always remain part of the permanent, public history.

    -

    +

    Last Closed Ledger

    The most recent ledger that the server believes the network reached consensus on. Different servers can arrive at a different conclusion about the last closed ledger. This is a consequence of Byzantanine failure. The purpose of validations is to resolve the differences between servers and come to a common conclusion about which last closed ledger is authoritative.

    -

    +

    Consensus

    A distributed agreement protocol. Ripple uses the consensus process to solve the problem of double-spending.

    -

    +

    Validation

    A signed statement indicating that it built a particular ledger as a result of the consensus process.

    -

    +

    Proposal

    A signed statement of which transactions it believes should be included in the next consensus ledger.

    -

    +

    Ledger Header

    The "ledger header" is the chunk of data that hashes to the ledger's hash. It contains the sequence number, parent hash, hash of the previous ledger, hash of the root node of the state tree, and so on.

    -

    +

    Ledger Base

    The term "ledger base" refers to a particular type of query and response used in the ledger fetch process that includes the ledger header but may also contain other information such as the root node of the state tree.

    -

    +

    Ledger Structures

    -

    +

    Account Root

    Account: A 160-bit account ID.

    Balance: Balance in the account.

    @@ -187,7 +187,7 @@ Account Root

    PreviousTxnLgrSeq: Ledger number sequence number of the previous transaction on this account.

    Sequence: Must be a value of 1 for the account to process a valid transaction. The value initially matches the sequence number of the state tree of the account that signed the transaction. The process of executing the transaction increments the sequence number. This is how ripple prevents a transaction from executing more than once.

    index: 256-bit hash of this AccountRoot.

    -

    +

    Trust Line

    The trust line acts as an edge connecting two accounts: the accounts represented by the HighNode and the LowNode. Which account is "high" and "low" is determined by the values of the two 160-bit account IDs. The account with the smaller 160-bit ID is always the low account. This ordering makes the hash of a trust line between accounts A and B have the same value as a trust line between accounts B and A.

    Balance:

      @@ -212,14 +212,14 @@ Trust Line

      PreviousTxnID: 256-bit hash of the previous transaction on this account.

      PreviousTxnLgrSeq: Ledger number sequence number of the previous transaction on this account.

      index: 256-bit hash of this RippleState.

      -

      +

      Ledger Hashes

      Flags: ???

      Hashes: A list of the hashes of the previous 256 ledgers.

      LastLedgerSequence:

      LedgerEntryType: "LedgerHashes".

      index: 256-bit hash of this LedgerHashes.

      -

      +

      Owner Directory

      Lists all of the offers and trust lines that are associated with an account.

      Flags: ???

      @@ -228,7 +228,7 @@ Owner Directory

      Owner: 160-bit ID of the owner account.

      RootIndex:

      index: A hash of the owner account.

      -

      +

      Book Directory

      Lists one or more offers that have the same quality.

      If a pair of Currency and Issuer fields are all zeros, then that pair is dealing in XRP.

      @@ -245,31 +245,31 @@ Book Directory

      TakerPaysIssuer: Issuer of the PaysCurrency.

      index: A 256-bit hash computed using the TakerGetsCurrency, TakerGetsIssuer, TakerPaysCurrency, and TakerPaysIssuer in the top 192 bits. The lower 64-bits are occupied by the exchange rate.

      -

      +

      Ledger Publication

      -

      +

      Overview

      The Ripple server permits clients to subscribe to a continuous stream of fully-validated ledgers. The publication code maintains this stream.

      The server attempts to maintain this continuous stream unless it falls too far behind, in which case it jumps to the current fully-validated ledger and then attempts to resume a continuous stream.

      -

      +

      Implementation

      LedgerMaster::doAdvance is invoked when work may need to be done to publish ledgers to clients. This code loops until it cannot make further progress.

      LedgerMaster::findNewLedgersToPublish is called first. If the last fully-valid ledger's sequence number is greater than the last published ledger's sequence number, it attempts to publish those ledgers, retrieving them if needed.

      If there are no new ledgers to publish, doAdvance determines if it can backfill history. If the publication is not caught up, backfilling is not attempted to conserve resources.

      If history can be backfilled, the missing ledger with the highest sequence number is retrieved first. If a historical ledger is retrieved, and its predecessor is in the database, tryFill is invoked to update the list of resident ledgers.

      -

      +

      The Ledger Cleaner

      -

      +

      Overview

      The ledger cleaner checks and, if necessary, repairs the SQLite ledger and transaction databases. It can also check for pieces of a ledger that should be in the node back end but are missing. If it detects this case, it triggers a fetch of the ledger. The ledger cleaner only operates by manual request. It is never started automatically.

      -

      +

      Operations

      The ledger cleaner can operate on a single ledger or a range of ledgers. It always validates the ledger chain itself, ensuring that the SQLite database contains a consistent chain of ledgers from the last validated ledger as far back as the database goes.

      If requested, it can additionally repair the SQLite entries for transactions in each checked ledger. This was primarily intended to repair incorrect entries created by a bug (since fixed) that could cause transasctions from a ledger other than the fully-validated ledger to appear in the SQLite databases in addition to the transactions from the correct ledger.

      If requested, it can additionally check the ledger for missing entries in the account state and transaction trees.

      To prevent the ledger cleaner from saturating the available I/O bandwidth and excessively polluting caches with ancient information, the ledger cleaner paces itself and does not attempt to get its work done quickly.

      -

      +

      Commands

      The ledger cleaner can be controlled and monitored with the ledger_cleaner RPC command. With no parameters, this command reports on the status of the ledger cleaner. This includes the range of ledgers it has been asked to process, the checks it is doing, and the number of errors it has found.

      The ledger cleaner can be started, stopped, or have its behavior changed by the following RPC parameters:

      @@ -280,7 +280,7 @@ Commands

      fix_txns: A boolean indicating whether to replace the SQLite transaction entries unconditionally

      check_nodes: A boolean indicating whether to check the specified ledger(s) for missing nodes in the back end node store

      -

      +

      References

    diff --git a/md_xrpld_app_misc_FeeEscalation.html b/md_xrpld_app_misc_FeeEscalation.html index 3c731edb4f..24906006ba 100644 --- a/md_xrpld_app_misc_FeeEscalation.html +++ b/md_xrpld_app_misc_FeeEscalation.html @@ -77,7 +77,7 @@ $(function() {
  • Rapid Fee escalation
  • The Transaction Queue
    • -

    +

    Fee Escalation

    The guiding principal of fee escalation is that when things are going smoothly, fees stay low, but as soon as high levels of traffic appear on the network, fees will grow quickly to extreme levels. This should dissuade malicious users from abusing the system, while giving legitimate users the ability to pay a higher fee to get high-priority transactions into the open ledger, even during unfavorable conditions.

    How fees escalate:

    @@ -106,7 +106,7 @@ Fee Escalation
    • This example assumes a cold-start scenario, with a single, possibly malicious, user willing to pay arbitrary amounts to get transactions into the open ledger. It ignores the effects of the Transaction Queue. Any lower fee level transactions submitted by other users at the same time as this user's transactions will go into the transaction queue, and will have the first opportunity to be applied to the next open ledger. The next section describes how that works in more detail.
    -

    +

    Transaction Queue

    An integral part of making fee escalation work for users of the network is the transaction queue. The queue allows legitimate transactions to be considered by the network for future ledgers if the escalated open ledger fee gets too high. This allows users to submit low priority transactions with a low fee, and wait for high fees to drop. It also allows legitimate users to continue submitting transactions during high traffic periods, and give those transactions a much better chance to succeed.

      @@ -130,9 +130,9 @@ Transaction Queue
    1. none of the prior queued transactions affect the ability of subsequent transactions to claim a fee.

      2. Currently, there is an additional restriction that the queue cannot work with transactions using the sfPreviousTxnID or sfAccountTxnID fields. sfPreviousTxnID is deprecated and shouldn't be used anyway. Future development will make the queue aware of sfAccountTxnID mechanisms.

      -

      +

      Technical Details

      -

      +

      Fee Level

      "Fee level" is used to allow the cost of different types of transactions to be compared directly. For a reference transaction, the base fee level is 256. If a transaction is submitted with a higher Fee field, the fee level is scaled appropriately.

      Examples, assuming a reference transaction base fee of 10 drops:

      @@ -142,18 +142,18 @@ Fee Level
    2. A hypothetical future non-reference transaction with a base fee of 15 drops multi-signed with 5 signatures and Fee=90 will have a fee level of 90 drop fee * 256 fee level / ((1tx + 5sigs) * 15 drop base fee) = 256 fee level.

    This demonstrates that a simpler transaction paying less XRP can be more likely to get into the open ledger, or be sorted earlier in the queue than a more complex transaction paying more XRP.

    -

    +

    Load Fee

    Each rippled server maintains a minimum cost threshold based on its current load. If you submit a transaction with a fee that is lower than the current load-based transaction cost of the rippled server, the server neither applies nor relays the transaction to its peers. A transaction is very unlikely to survive the consensus process unless its transaction fee value meets the requirements of a majority of servers.

    -

    +

    Reference Transaction

    In this document, a "Reference Transaction" is any currently implemented single-signed transaction (eg. Payment, Account Set, Offer Create, etc) that requires a fee.

    In the future, there may be other transaction types that require more (or less) work for rippled to process. Those transactions may have a higher (or lower) base fee, requiring a correspondingly higher (or lower) fee to get into the same position as a reference transaction.

    -

    +

    Consensus Health

    For consensus to be considered healthy, the peers on the network should largely remain in sync with one another. It is particularly important for the validators to remain in sync, because that is required for participation in consensus. However, the network tolerates some validators being out of sync. Fundamentally, network health is a function of validators reaching consensus on sets of recently submitted transactions.

    Another factor to consider is the duration of the consensus process itself. This generally takes under 5 seconds on the main network under low volume. This is based on historical observations. However factors such as transaction volume can increase consensus duration. This is because rippled performs more work as transaction volume increases. Under sufficient load this tends to increase consensus duration. It's possible that relatively high consensus duration indicates a problem, but it is not appropriate to conclude so without investigation. The upper limit for consensus duration should be roughly 20 seconds. That is far above the normal. If the network takes this long to close ledgers, then it is almost certain that there is a problem with the network. This circumstance often coincides with new ledgers with zero transactions.

    -

    +

    Other Constants

    • Base fee transaction limit per ledger. The minimum value of 5 was chosen to ensure the limit never gets so small that the ledger becomes unusable. The "target" value of 50 was chosen so the limit never gets large enough to invite abuse, but keeps up if the network stays healthy and active. These exact values were chosen experimentally, and can easily change in the future.
      • @@ -165,7 +165,7 @@ Other Constants
    • Minimum last ledger sequence buffer. If a transaction has a LastLedgerSequence value, and cannot be processed into the open ledger, that LastLedgerSequence must be at least 2 more than the sequence number of the open ledger to be considered for the queue. The value was chosen to provide a balance between letting the user control the lifespan of the transaction, and giving a queued transaction a chance to get processed out of the queue before getting discarded, particularly since it may have dependent transactions also in the queue, which will never succeed if this one is discarded.
    • Replaced transaction fee increase. Any transaction in the queue can be replaced by another transaction with the same sequence number and at least a 25% higher fee level. The 25% increase is intended to cover the resource cost incurred by broadcasting the original transaction to the network. This value was chosen experimentally, and can easily change in the future.
    -

    +

    <tt>fee</tt> command

    The fee RPC and WebSocket command is still experimental, and may change without warning.

    fee takes no parameters, and returns information about the current local fee escalation and transaction queue state as both fee levels and drops. The drop values assume a single-singed reference transaction. It is up to the user to compute the necessary fees for other types of transactions. (E.g. multiply all drop values by 5 for a multi-signed transaction with 4 signatures.)

    @@ -191,7 +191,7 @@ Other Constants
    }
    }
    }
    -

    +

    <a href="https://xrpl.org/server_info.html" ><tt>server_info</tt></a> command

    The fields listed here are still experimental, and may change without warning.

    Up to two fields in server_info output are related to fee escalation.

    @@ -200,7 +200,7 @@ Other Constants
  • load_factor_fee_queue: If the queue is full, this is the factor on base transaction cost that a transaction must pay to get into the queue. If not full, the value is 1, so will not be returned.

    • In all cases, the transaction fee must be high enough to overcome both load_factor_fee_queue and load_factor to be considered. It does not need to overcome load_factor_fee_escalation, though if it does not, it is more likely to be queued than immediately processed into the open ledger.

    -

    +

    <a href="https://xrpl.org/server_state.html" ><tt>server_state</tt></a> command

    The fields listed here are still experimental, and may change without warning.

    Three fields in server_state output are related to fee escalation.

    diff --git a/md_xrpld_app_misc_README.html b/md_xrpld_app_misc_README.html index 9d905a9c22..a1f840621f 100644 --- a/md_xrpld_app_misc_README.html +++ b/md_xrpld_app_misc_README.html @@ -75,7 +75,7 @@ $(function() {

    The Ripple payment protocol enforces a fee schedule expressed in units of the native currency, XRP. Fees for transactions are paid directly from the account owner. There are also reserve requirements for each item that occupies storage in the ledger. The reserve fee schedule contains both a per-account reserve, and a per-owned-item reserve. The items an account may own include active offers, trust lines, and tickets.

    Validators may vote to increase fees if they feel that the network is charging too little. They may also vote to decrease fees if the fees are too costly relative to the value the network provides. One common case where a validator may want to change fees is when the value of the native currency XRP fluctuates relative to other currencies.

    The fee voting mechanism takes place every 256 ledgers ("voting ledgers"). In a voting ledger, each validator takes a position on what they think the fees should be. The consensus process converges on the majority position, and in subsequent ledgers a new fee schedule is enacted.

    -

    +

    Consensus

    The Ripple consensus algorithm allows distributed participants to arrive at the same answer for yes/no questions. The canonical case for consensus is whether or not a particular transaction is included in the ledger. Fees present a more difficult challenge, since the decision on the new fee is not a yes or no question.

    To convert validators' positions on fees into a yes or no question that can be converged in the consensus process, the following algorithm is used:

    @@ -86,11 +86,11 @@ Consensus
  • The consensus process is applied to these fee-setting transactions as normal. Each transaction is either included in the ledger or not. In most cases, one fee setting transaction will make it in while the others are rejected. In some rare cases more than one fee setting transaction will make it in. The last one to be applied will take effect. This is harmless since a majority of validators still agreed on it.
  • After the voting ledger has been validated, future pseudo transactions before the next voting ledger are rejected as fee setting transactions may only appear in voting ledgers.
    • -

    +

    Configuration

    A validating instance of rippled uses information in the configuration file to determine how it wants to vote on the fee schedule. It is the responsibility of the administrator to set these values.

    -

    +

    Amendment

    An Amendment is a new or proposed change to a ledger rule. Ledger rules affect transaction processing and consensus; peers must use the same set of rules for consensus to succeed, otherwise different instances of rippled will get different results. Amendments can be almost anything but they must be accepted by a network majority through a consensus process before they are utilized. An Amendment must receive at least an 80% approval rate from validating nodes for a period of two weeks before being accepted. The following example outlines the process of an Amendment from its conception to approval and usage.

      @@ -106,7 +106,7 @@ Amendment

      If an amendment holds majority status for two weeks, validators will introduce a pseudo-transaction to enable the amendment.

      All amendments are assumed to be critical and irreversible. Thus there is no mechanism to disable or revoke an amendment, nor is there a way for a server to operate while an amendment it does not understand is enabled.

      -

      +

      SHAMapStore: Online Delete

      Optional online deletion happens through the SHAMapStore. Records are deleted from disk based on ledger sequence number. These records reside in the key-value database as well as in the SQLite ledger and transaction databases. Without online deletion storage usage grows without bounds. It can only be pruned by stopping, manually deleting data, and restarting the server. Online deletion requires less operator intervention to manage the server.

      The main mechanism to delete data from the key-value database is to keep two databases open at all times. One database has all writes directed to it. The other database has recent archival data from just prior to that from the current writable database. Upon rotation, the archival database is deleted. The writable database becomes archival, and a brand new database becomes writable. To ensure that no necessary data for transaction processing is lost, a variety of steps occur, including copying the contents of an entire ledger's account state map, clearing caches, and copying the contents of (freshening) other caches.

      diff --git a/md_xrpld_app_rdb_README.html b/md_xrpld_app_rdb_README.html index 8878ed3f75..3c9ee6ec7f 100644 --- a/md_xrpld_app_rdb_README.html +++ b/md_xrpld_app_rdb_README.html @@ -77,15 +77,15 @@ $(function() {
    • All hard-coded SQL statements should be stored in the files under the xrpld/app/rdb directory. With the exception of test modules, no hard-coded SQL should be added to any other file in rippled.
    • The base class RelationalDatabase is inherited by derived classes that each provide an interface for operating on distinct relational database systems.
    -

    +

    Overview

    Firstly, the interface RelationalDatabase is inherited by the classes SQLiteDatabase and PostgresDatabase which are used to operate the software's main data store (for storing transactions, accounts, ledgers, etc.). Secondly, the files under the detail directory provide supplementary functions that are used by these derived classes to access the underlying databases. Lastly, the remaining files in the interface (located at the top level of the module) are used by varied parts of the software to access any secondary relational databases.

    -

    +

    Configuration

    The config section [relational_db] has a property named backend whose value designates which database implementation will be used for node databases. Presently the only valid value for this property is sqlite:

    [relational_db]
    backend=sqlite
    -

    +

    Source Files

    The Relational Database Interface consists of the following directory structure (as of November 2021):

    src/xrpld/app/rdb/
    @@ -107,7 +107,7 @@ Source Files
    ├── State.h
    ├── Vacuum.h
    └── Wallet.h
    -

    +

    File Contents

    @@ -129,10 +129,10 @@ File Contents
    Wallet.[h\|cpp] Defines/Implements methods for interacting with Wallet SQLite databases
    -

    +

    Classes

    The abstract class RelationalDatabase is the primary class of the Relational Database Interface and is defined in the eponymous header file. This class provides a static method init() which, when invoked, creates a concrete instance of a derived class whose type is specified by the system configuration. All other methods in the class are virtual. Presently there exist two classes that derive from RelationalDatabase, namely SQLiteDatabase and PostgresDatabase.

    -

    +

    Database Methods

    The Relational Database Interface provides three categories of methods for interacting with databases:

      diff --git a/md_xrpld_nodestore_README.html b/md_xrpld_nodestore_README.html index d58fd28682..a567923f98 100644 --- a/md_xrpld_nodestore_README.html +++ b/md_xrpld_nodestore_README.html @@ -76,9 +76,9 @@ $(function() {
    • NodeStore
    • Benchmarks
    -

    +

    NodeStore

    -

    +

    Introduction

    A NodeObject is a simple object that the Ledger uses to store entries. It is comprised of a type, a hash and a blob. It can be uniquely identified by the hash, which is a 256 bit hash of the blob. The blob is a variable length block of serialized data. The type identifies what the blob contains. The fields are as follows:

      @@ -117,7 +117,7 @@ Introduction

      The NodeStore provides an interface that stores, in a persistent database, a collection of NodeObjects that rippled uses as its primary representation of ledger entries. All ledger entries are stored as NodeObjects and as such, need to be persisted between launches. If a NodeObject is accessed and is not in memory, it will be retrieved from the database.

      -

      +

      Backend

      The NodeStore implementation provides the Backend abstract interface, which lets different key/value databases to be chosen at run-time. This allows experimentation with different engines. Improvements in the performance of the NodeStore are a constant area of research. The database can be specified in the configuration file [node_db] section as follows.

      One or more lines of key / value pairs

      @@ -148,15 +148,15 @@ Backend
    • 0 off
    • 1 on (default)
    -

    +

    Benchmarks

    The NodeStore.Timing test is used to execute a set of read/write workloads to compare current available nodestore backends. It can be executed with:

    $rippled --unittest=NodeStoreTiming

    It is also possible to use alternate DB config params by passing config strings as --unittest-arg.

    -

    +

    Addendum

    The discussion below refers to a RocksDBQuick backend that has since been removed from the code as it was not working and not maintained. That backend primarily used one of the several rocks Optimize* methods to setup the majority of the DB options/params, whereas the primary RocksDB backend exposes many of the available config options directly. The code for RocksDBQuick can be found in versions of this repo 1.2 and earlier if you need to refer back to it. The conclusions below date from about 2014 and may need revisiting based on newer versions of RocksDB (TBD).

    -

    +

    Discussion

    RocksDBQuickFactory is intended to provide a testbed for comparing potential rocksdb performance with the existing recommended configuration in rippled.cfg. Through various executions and profiling some conclusions are presented below.

      diff --git a/md_xrpld_overlay_README.html b/md_xrpld_overlay_README.html index 8518ced4f3..896a66d98e 100644 --- a/md_xrpld_overlay_README.html +++ b/md_xrpld_overlay_README.html @@ -72,19 +72,19 @@ $(function() {
      Overlay
      -

      +

      Introduction

      The XRP Ledger network consists of a collection of peers running **rippled** or other compatible software. Each peer maintains multiple outgoing connections and optional incoming connections to other peers. These connections are made over both the public Internet and private local area networks. This network defines a connected directed graph of nodes where vertices are instances of rippled and edges are persistent TCP/IP connections. Peers send and receive messages to other connected peers. This peer to peer network, layered on top of the public and private Internet, forms an overlay network. The contents of the messages and the behavior of peers in response to the messages, plus the information exchanged during the handshaking phase of connection establishment, defines the XRP Ledger peer protocol (or protocol in this context).

      -

      +

      Overview

      Each connection is represented by a Peer object. The Overlay manager establishes, receives, and maintains connections to peers. Protocol messages are exchanged between peers and serialized using Google Protocol Buffers.

      -

      +

      Structure

      Each connection between peers is identified by its connection type, which affects the behavior of message routing. At present, only a single connection type is supported: Peer.

      -

      +

      Handshake

      To establish a protocol connection, a peer makes an outgoing TLS encrypted connection to a remote peer, then sends an HTTP request with no message body.

      -

      +

      HTTP

      The HTTP request must:

        @@ -94,7 +94,7 @@ HTTP

    HTTP requests which do not conform to this requirements must generate an appropriate HTTP error and result in the connection being closed.

    Upon receipt of a well-formed HTTP upgrade request, and validation of the protocol specific parameters, a peer will either send back a HTTP 101 response and switch to the requested protocol, or a message indicating that the request failed (e.g. by sending HTTP 400 "Bad Request" or HTTP 503 "Service Unavailable").

    -

    +

    Example HTTP Upgrade Request

    GET / HTTP/1.1
    User-Agent: rippled-1.4.0-b1+DEBUG
    @@ -109,7 +109,7 @@ Example HTTP Upgrade Request
    Remote-IP: 192.0.2.79
    Closed-Ledger: llRZSKqvNieGpPqbFGnm358pmF1aW96SDIUQcnMh6HI=
    Previous-Ledger: q4aKbP7sd5wv+EXArwCmQiWZhq9AwBl2p/hCtpGJNsc=
    -

    +

    Example HTTP Upgrade Response (Success)

    HTTP/1.1 101 Switching Protocols
    Connection: Upgrade
    @@ -122,7 +122,7 @@ Example HTTP Upgrade Response (Success)
    Network-Time: 619234797
    Closed-Ledger: h7HL85W9ywkex+G7p42USVeV5kE04CWK+4DVI19Of8I=
    Previous-Ledger: EPvIpAD2iavGFyyZYi8REexAXyKGXsi1jMF7OIBY6/Y=
    -

    +

    Example HTTP Upgrade Response (Failure: no slots available)

    HTTP/1.1 503 Service Unavailable
    Server: rippled-0.27.0
    @@ -132,7 +132,7 @@ Example HTTP Upgrade Response (Failure: no slots available)
    {"peer-ips":["54.68.219.39:51235","54.187.191.179:51235",
    "107.150.55.21:6561","54.186.230.77:51235","54.187.110.243:51235",
    "85.127.34.221:51235","50.43.33.236:51235","54.187.138.75:51235"]}
    -

    +

    Standard Fields

    @@ -169,7 +169,7 @@ Standard Fields

    For responses, it should a consist of single element matching one of the elements provided in the corresponding request. If the server does not understand any of the available protocol versions, the upgrade request should fail with an appropriate HTTP error code (e.g. by sending an HTTP 400 "Bad Request" response).

    Protocol versions are string of the form XRPL/ followed by a dotted major and minor protocol version number, where the major number is greater than or equal to 2 and the minor is greater than or equal to 0.

    See RFC 2616 §14.42

    -

    +

    Custom Fields

    @@ -272,11 +272,11 @@ Custom Fields

    If present, identifies the hash of the parent ledger that the sending server considers to be closed.

    The value is presently encoded using Base64 encoding, but implementations should support both Base64 and HEX encoding for this value.

    -

    +

    Additional Headers

    An implementation or operator may specify additional, optional fields and values in both requests and responses.

    Implementations should not reject requests because of the presence of fields that they do not understand.

    -

    +

    Session Signature

    Even for SSL/TLS encrypted connections, it is possible for an attacker to mount relatively inexpensive MITM attacks that can be extremely hard to detect and may afford the attacker the ability to intelligently tamper with messages exchanged between the two endpoints.

    This risk can be mitigated if at least one side has a certificate from a certificate authority trusted by the other endpoint, but having a certificate is not always possible (or even desirable) in a decentralized and permissionless network.

    @@ -287,11 +287,11 @@ Session Signature

    Each side of the link will verify that the provided signature is from the claimed public key against the session's unique fingerprint. If this signature check fails then the link MUST be dropped.

    If an attacker, Eve, establishes two separate SSL sessions with Alice and Bob, the fingerprints of the two sessions will be different, and Eve will not be able to sign the fingerprint of her session with Bob with Alice's private key, or the fingerprint of her session with Alice with Bob's private key, and so both A and B will know that an active MITM attack is in progress and will close their connections.

    If Eve simply proxies the raw bytes, she will be unable to decrypt the data being transferred between A and B and will not be able to intelligently tamper with the message stream between Alice and Bob, although she may be still be able to inject delays or terminate the link.

    -

    +

    Ripple Clustering

    A cluster consists of more than one Ripple server under common administration that share load information, distribute cryptography operations, and provide greater response consistency.

    Cluster nodes are identified by their public node keys. Cluster nodes exchange information about endpoints that are imposing load upon them. Cluster nodes share information about their internal load status. Cluster nodes do not have to verify the cryptographic signatures on messages received from other cluster nodes.

    -

    +

    Configuration

    A server's public key can be determined from the output of the server_info command. The key is in the pubkey_node value, and is a text string beginning with the letter n. The key is maintained across runs in a database.

    Cluster members are configured in the rippled.cfg file under [cluster_nodes]. Each member should be configured on a line beginning with the node public key, followed optionally by a space and a friendly name.

    @@ -304,20 +304,20 @@ Configuration
  • Restart each hub, one by one
  • Restart the spoke
    • -

    +

    Transaction Behavior

    When a transaction is received from a cluster member, several normal checks are bypassed:

    Signature checking is bypassed because we trust that a cluster member would not relay a transaction with an incorrect signature. Validators may wish to disable this feature, preferring the additional load to get the additional security of having validators check each transaction.

    Local checks for transaction checking are also bypassed. For example, a server will not reject a transaction from a cluster peer because the fee does not meet its current relay fee. It is preferable to keep the cluster in agreement and permit confirmation from one cluster member to more reliably indicate the transaction's acceptance by the cluster.

    -

    +

    Server Load Information

    Cluster members exchange information on their server's load level. The load level is essentially the amount by which the normal fee levels are multiplied to get the server's fee for relaying transactions.

    A server's effective load level, and the one it uses to determine its relay fee, is the highest of its local load level, the network load level, and the cluster load level. The cluster load level is the median load level reported by a cluster member.

    -

    +

    Gossip

    Gossip is the mechanism by which cluster members share information about endpoints (typically IPv4 addresses) that are imposing unusually high load on them. The endpoint load manager takes into account gossip to reduce the amount of load the endpoint is permitted to impose on the local server before it is warned, disconnected, or banned.

    Suppose, for example, that an attacker controls a large number of IP addresses, and with these, he can send sufficient requests to overload a server. Without gossip, he could use these same addresses to overload all the servers in a cluster. With gossip, if he chooses to use the same IP address to impose load on more than one server, he will find that the amount of load he can impose before getting disconnected is much lower.

    -

    +

    Monitoring

    The peers command will report on the status of the cluster. The cluster object will contain one entry for each member of the cluster (either configured or introduced by another cluster member). The age field is the number of seconds since the server was last heard from. If the server is reporting an elevated cluster fee, that will be reported as well.

    In the peers object, cluster members will contain a cluster field set to true.

    diff --git a/md_xrpld_peerfinder_README.html b/md_xrpld_peerfinder_README.html index 54a8578b0c..03c17270b8 100644 --- a/md_xrpld_peerfinder_README.html +++ b/md_xrpld_peerfinder_README.html @@ -72,14 +72,14 @@ $(function() {
    PeerFinder
    -

    +

    Introduction

    The Ripple payment network consists of a collection of peers running the rippled software. Each peer maintains multiple outgoing connections and optional incoming connections to other peers. These connections are made over both the public Internet and private local area networks. This network defines a fully connected directed graph of nodes. Peers send and receive messages to other connected peers. This peer to peer network, layered on top of the public and private Internet, forms an overlay network.

    -

    +

    Bootstrapping

    When a peer comes online it needs a set of IP addresses to connect to in order to gain initial entry into the overlay in a process called bootstrapping. Once they have established an initial set of these outbound peer connections, they need to gain additional addresses to establish more outbound peer connections until the desired limit is reached. Furthermore, they need a mechanism to advertise their IP address to new or existing peers in the overlay so they may receive inbound connections up to some desired limit. And finally, they need a mechanism to provide inbound connection requests with an alternate set of IP addresses to try when they have already reached their desired maximum number of inbound connections.

    PeerFinder is a self contained module that provides these services, along with some additional overlay network management services such as fixed slots and cluster slots.

    -

    +

    Features

    PeerFinder has these responsibilities

      @@ -93,18 +93,18 @@ Features

  • Prevent duplicate connections and connections to self.
    • -

    +

    Concepts

    -

    +

    Manager

    The Manager is an application singleton which provides the primary interface to interaction with the PeerFinder.

    -

    +

    Autoconnect

    The Autoconnect feature of PeerFinder automatically establishes outgoing connections using addresses learned from various sources including the configuration file, the result of domain name lookups, and messages received from the overlay itself.

    -

    +

    Callback

    PeerFinder is an isolated code module with few external dependencies. To perform socket specific activities such as establishing outgoing connections or sending messages to connected peers, the Manager is constructed with an abstract interface called the Callback. An instance of this interface performs the actual required operations, making PeerFinder independent of the calling code.

    -

    +

    Config

    The Config structure defines the operational parameters of the PeerFinder. Some values come from the configuration file while others are calculated via tuned heuristics. The fields are as follows:

      @@ -126,14 +126,14 @@ Config

    Here's an example of how the network might be structured with a fractional value for outPeers:

    **(Need example here)**

    -

    +

    Livecache

    The Livecache holds relayed IP addresses that have been received recently in the form of Endpoint messages via the peer to peer overlay. A peer periodically broadcasts the Endpoint message to its neighbors when it has open inbound connection slots. Peers store these messages in the Livecache and periodically forward their neighbors a handful of random entries from their Livecache, with an incremented hop count for each forwarded entry.

    The algorithm for sending a neighbor a set of Endpoint messages chooses evenly from all available hop counts on each send. This ensures that each peer will see some entries with the farthest hops at each iteration. The result is to expand a peer's horizon with respect to which overlay endpoints are visible. This is designed to force the overlay to become highly connected and reduce the network diameter with each connection establishment.

    When a peer receives an Endpoint message that originates from a neighbor (identified by a hop count of zero) for the first time, it performs an incoming connection test on that neighbor by initiating an outgoing connection to the remote IP address as seen on the connection combined with the port advertised in the Endpoint message. If the test fails, then the peer considers its neighbor firewalled (intentionally or due to misconfiguration) and not forward neighbor endpoint in Endpoint messages. This prevents poor quality unconnectible addresses from landing in the caches. If the incoming connection test passes, then the peer fills in the Endpoint message with the remote address as seen on the connection before storing it in its cache and forwarding it to other peers. This relieves the neighbor from the responsibility of knowing its own IP address before it can start receiving incoming connections.

    Livecache entries expire quickly. Since a peer stops advertising itself when it no longer has available inbound slots, its address will shortly after stop being handed out by other peers. Livecache entries are very likely to result in both a successful connection establishment and the acquisition of an active outbound slot. Compare this with Bootcache addresses, which are very likely to be connectible but unlikely to have an open slot.

    Because entries in the Livecache are ephemeral, they are not persisted across launches in the database. The Livecache is continually updated and expired as Endpoint messages are received from the overlay over time.

    -

    +

    Bootcache

    The Bootcache stores IP addresses useful for gaining initial connections. Each address is associated with the following metadata:

      @@ -144,10 +144,10 @@ Bootcache

      When choosing addresses from the boot cache for the purpose of establishing outgoing connections, addresses are ranked in decreasing order of valence. The Bootcache is persistent. Entries are periodically inserted and updated in the corresponding SQLite database during program operation. When rippled is launched, the existing Bootcache database data is accessed and loaded to accelerate the bootstrap process.

      Desirable entries in the Bootcache are addresses for servers which are known to have high uptimes, and for which connection attempts usually succeed. However, these servers do not necessarily have available inbound connection slots. However, it is assured that these servers will have a well populated Livecache since they will have moved towards the core of the overlay over their high uptime. When a connected server is full it will return a handful of new addresses from its Livecache and gracefully close the connection. Addresses from the Livecache are highly likely to have inbound connection slots and be connectible.

      For security, all information that contributes to the ranking of Bootcache entries is observed locally. PeerFinder never trusts external sources of information.

      -

      +

      Slot

      Each TCP/IP socket that can participate in the peer to peer overlay occupies a slot. Slots have properties and state associated with them:

      -

      +

      State (Slot)

      The slot state represents the current stage of the connection as it passes through the business logic for establishing peer connections.

        @@ -167,7 +167,7 @@ State (Slot)

        The Closing state represents a connected socket in the process of being gracefully closed.

      -

      +

      Properties (Slot)

      Slot properties may be combined and are not mutually exclusive.

        @@ -184,19 +184,19 @@ Properties (Slot)

        A superpeer slot is a connection to a peer which can accept incoming connections, meets certain resource availaibility requirements (such as bandwidth, CPU, and storage capacity), and operates full duplex in the overlay. Connections which are not superpeers are by definition leaves. A leaf slot is a connection to a peer which does not route overlay messages to other peers, and operates in a partial half duplex fashion in the overlay.

      -

      +

      Fixed Slots

      Fixed slots are identified by IP address and set up during the initialization of the Manager, usually from the configuration file. The Logic will always make outgoing connection attempts to each fixed slot which is not currently connected. If we receive an inbound connection from an endpoint whose address portion (without port) matches a fixed slot address, we consider the fixed slot to be connected.

      -

      +

      Cluster Slots

      Cluster slots are identified by the public key and set up during the initialization of the manager or discovered upon receipt of messages in the overlay from trusted connections.

      -

      +

      Algorithms

      -

      +

      Connection Strategy

      The Connection Strategy applies the configuration settings to establish desired outbound connections. It runs periodically and progresses through a series of stages, remaining in each stage until a condition is met

      -

      +

      Stage 1: Fixed Slots

      This stage is invoked when the number of active fixed connections is below the number of fixed connections specified in the configuration, and one of the following is true:

        @@ -205,7 +205,7 @@ Stage 1: Fixed Slots

      Each fixed address is associated with a retry timer. On a fixed connection failure, the timer is reset so that the address is not tried for some amount of time, which increases according to a scheduled sequence up to some maximum which is currently set to approximately one hour between retries. A fixed address is considered eligible if we are not currently connected or attempting the address, and its retry timer has expired.

      The PeerFinder makes its best effort to become fully connected to the fixed addresses specified in the configuration file before moving on to establish outgoing connections to foreign peers. This security feature helps rippled establish itself with a trusted set of peers first before accepting untrusted data from the network.

      -

      +

      Stage 2: Livecache

      The Livecache is invoked when Stage 1 is not active, autoconnect is enabled, and the number of active outbound connections is below the number desired. The stage remains active while:

        @@ -213,7 +213,7 @@ Stage 2: Livecache
      • Any outbound connection attempts are in progress

      PeerFinder makes its best effort to exhaust addresses in the Livecache before moving on to the Bootcache, because Livecache addresses are highly likely to be connectible (since they are known to have been online within the last minute), and highly likely to have an open slot for an incoming connection (because peers only advertise themselves in the Livecache when they have open slots).

      -

      +

      Stage 3: Bootcache

      The Bootcache is invoked when Stage 1 and Stage 2 are not active, autoconnect is enabled, and the number of active outbound connections is below the number desired. The stage remains active while:

        @@ -221,7 +221,7 @@ Stage 3: Bootcache

      Entries in the Bootcache are ranked, with highly connectible addresses preferred over others. Connection attempts to Bootcache addresses are very likely to succeed but unlikely to produce an active connection since the peers likely do not have open slots. Before the remote peer closes the connection it will send a handful of addresses from its Livecache to help the new peer coming online obtain connections.

      -

      +

      References

      Much of the work in PeerFinder was inspired by earlier work in Gnutella:

      Revised Gnutella Ping Pong Scheme
      diff --git a/md_xrpld_rpc_README.html b/md_xrpld_rpc_README.html index 765cd11a61..826a4b43f9 100644 --- a/md_xrpld_rpc_README.html +++ b/md_xrpld_rpc_README.html @@ -72,13 +72,13 @@ $(function() {

      How to use RPC coroutines.
    -

    +

    Introduction.

    By default, an RPC handler runs as an uninterrupted task on the JobQueue. This is fine for commands that are fast to compute but might not be acceptable for tasks that require multiple parts or are large, like a full ledger.

    For this purpose, the rippled RPC handler allows suspension with continuation

    • a request to suspend execution of the RPC response and to continue it after some function or job has been executed. A default continuation is supplied which simply reschedules the job on the JobQueue, or the programmer can supply their own.
    -

    +

    The classes.

    Suspension with continuation uses four std::functions in the ripple::RPC namespace: 

    using Callback = std::function <void ()>;
 using Continuation = std::function <void (Callback const&)>;
@@ -88,7 +88,7 @@ using Coroutine = std::function <void (Suspend const&)>;
 
    A Continuation is a function that is given a Callback and promises to call it later. A Continuation guarantees to call the Callback exactly once at some point in the future, but it does not have to be immediately or even in the current thread.
    
 
    A Suspend is a function belonging to a Coroutine. A Suspend runs a Continuation, passing it a Callback that continues execution of the Coroutine.
    
 
    And finally, a Coroutine is a std::function which is given a Suspend. This is what the RPC handler gives to the coroutine manager, expecting to get called back with a Suspend and to be able to start execution.
    
-
    
+
    
 The flow of control.
    
 
    Given these functions, the flow of RPC control when using coroutines is straight-forward.
    
 
      
diff --git a/md_xrpld_shamap_README.html b/md_xrpld_shamap_README.html
index a31b7ceabd..24d033ff6d 100644
--- a/md_xrpld_shamap_README.html
+++ b/md_xrpld_shamap_README.html
@@ -96,7 +96,7 @@ $(function() {
 
      Copies are made with the snapShot function as opposed to the SHAMap copy constructor. See the section on SHAMap creation for more details about snapShot.
      
 
      Sequence numbers are used to further customize the node ownership strategy. See the section on sequence numbers for details on sequence numbers.
      
 
      node diagram
      
-
      
+
      
 Mutability
      
 
      There are two different ways of building and using a SHAMap:
      
 
        
@@ -109,7 +109,7 @@ Mutability

    Most SHAMaps are immutable, in the sense that they don't modify or remove their contained nodes.

    An example where a mutable SHAMap is required is when we want to apply transactions to the last closed ledger. To do so we'd make a mutable snapshot of the state trie and then start applying transactions to it. Because the snapshot is mutable, changes to nodes in the snapshot will not affect nodes in other SHAMaps.

    An example using a immutable ledger would be when there's an open ledger and some piece of code wishes to query the state of the ledger. In this case we don't wish to change the state of the SHAMap, so we'd use an immutable snapshot.

    -

    +

    Sequence numbers

    Both SHAMaps and their nodes carry a sequence number. This is simply an unsigned number that indicates ownership or membership, or a non-membership.

    SHAMaps sequence numbers normally start out as 1. However when a snap-shot of a SHAMap is made, the copy's sequence number is 1 greater than the original.

    @@ -117,20 +117,20 @@ Sequence numbers

    When a SHAMap needs to have a private copy of a node, not shared by any other SHAMap, it first clones it and then sets the new copy to have a sequence number equal to the SHAMap sequence number. The unshareNode is a private utility which automates the task of first checking if the node is already sharable, and if so, cloning it and giving it the proper sequence number. An example case where a private copy is needed is when an inner node needs to have a child pointer altered. Any modification to a node will require a non-shared node.

    When a SHAMap decides that it is safe to share a node of its own, it sets the node's sequence number to 0 (a SHAMap never has a sequence number of 0). This is done for every node in the trie when SHAMap::walkSubTree is executed.

    Note that other objects in rippled also have sequence numbers (e.g. ledgers). The SHAMap and node sequence numbers should not be confused with these other sequence numbers (no relation).

    -

    +

    SHAMap Creation

    A SHAMap is usually not created from vacuum. Once an initial SHAMap is constructed, later SHAMaps are usually created by calling snapShot(bool isMutable) on the original SHAMap. The returned SHAMap has the expected characteristics (mutable or immutable) based on the passed in flag.

    It is cheaper to make an immutable snapshot of a SHAMap than to make a mutable snapshot. If the SHAMap snapshot is mutable then sharable nodes must be copied before they are placed in the mutable map.

    A new SHAMap is created with each new ledger round. Transactions not executed in the previous ledger populate the SHAMap for the new ledger.

    -

    +

    Storing SHAMap data in the database

    When consensus is reached, the ledger is closed. As part of this process, the SHAMap is stored to the database by calling SHAMap::flushDirty.

    Both unshare() and flushDirty walk the SHAMap by calling SHAMap::walkSubTree. As unshare() walks the trie, nodes are not written to the database, and as flushDirty walks the trie nodes are written to the database. walkSubTree visits every node in the trie. This process must ensure that each node is only owned by this trie, and so "unshares" as it walks each node (from the root down). This is done in the preFlushNode function by ensuring that the node has a sequence number equal to that of the SHAMap. If the node doesn't, it is cloned.

    For each inner node encountered (starting with the root node), each of the children are inspected (from 1 to 16). For each child, if it has a non-zero sequence number (unshareable), the child is first copied. Then if the child is an inner node, we recurse down to that node's children. Otherwise we've found a leaf node and that node is written to the database. A count of each leaf node that is visited is kept. The hash of the data in the leaf node is computed at this time, and the child is reassigned back into the parent inner node just in case the COW operation created a new pointer to this leaf node.

    After processing each node, the node is then marked as sharable again by setting its sequence number to 0.

    After all of an inner node's children are processed, then its hash is updated and the inner node is written to the database. Then this inner node is assigned back into it's parent node, again in case the COW operation created a new pointer to it.

    -

    +

    Walking a SHAMap

    The private function SHAMap::walkTowardsKey is a good example of how to walk a SHAMap, and the various functions that call walkTowardsKey are good examples of why one would want to walk a SHAMap (e.g. SHAMap::findKey). walkTowardsKey always starts at the root of the SHAMap and traverses down through the inner nodes, looking for a leaf node along a path in the trie designated by a uint256.

    As one walks the trie, one can optionally keep a stack of nodes that one has passed through. This isn't necessary for walking the trie, but many clients will use the stack after finding the desired node. For example if one is deleting a node from the trie, the stack is handy for repairing invariants in the trie after the deletion.

    @@ -148,7 +148,7 @@ Walking a SHAMap
  • In the database.

    • If the node is not found in the trie, then it is installed into the trie as part of the traversal process.

    -

    +

    Late-arriving Nodes

    As we noted earlier, SHAMaps (even immutable ones) may grow. If a SHAMap is searching for a node and runs into an empty spot in the trie, then the SHAMap looks to see if the node exists but has not yet been made part of the map. This operation is performed in the SHAMap::fetchNodeNT() method. The NT is this case stands for 'No Throw'.

    The fetchNodeNT() method goes through three phases:

    @@ -159,29 +159,29 @@ Late-arriving Nodes
  • If the node is not in the TreeNodeCache, we attempt to locate the node in the historic data stored by the data base. The call to to fetchNodeFromDB(hash) does that work for us.
  • Finally if a filter exists, we check if it can supply the node. This is typically the LedgerMaster which tracks the current ledger and ledgers in the process of closing.
    • -

    +

    Canonicalize

    canonicalize() is called every time a node is introduced into the SHAMap.

    A call to canonicalize() stores the node in the TreeNodeCache if it does not already exist in the TreeNodeCache.

    The calls to canonicalize() make sure that if the resulting node is already in the SHAMap, node TreeNodeCache or database, then we don't create duplicates by favoring the copy already in the TreeNodeCache.

    By using canonicalize() we manage a thread race condition where two different threads might both recognize the lack of a SHAMapLeafNode at the same time (during a fetch). If they both attempt to insert the node into the SHAMap, then canonicalize makes sure that the first node in wins and the slower thread receives back a pointer to the node inserted by the faster thread. Recall that these two SHAMaps will share the same TreeNodeCache.

    -

    +

    <tt>TreeNodeCache</tt>

    The TreeNodeCache is a std::unordered_map keyed on the hash of the SHAMap node. The stored type consists of shared_ptr<SHAMapTreeNode>, weak_ptr<SHAMapTreeNode>, and a time point indicating the most recent access of this node in the cache. The time point is based on std::chrono::steady_clock.

    The container uses a cryptographically secure hash that is randomly seeded.

    The TreeNodeCache also carries with it various data used for statistics and logging, and a target age for the contained nodes. When the target age for a node is exceeded, and there are no more references to the node, the node is removed from the TreeNodeCache.

    -

    +

    <tt>FullBelowCache</tt>

    This cache remembers which trie keys have all of their children resident in a SHAMap. This optimizes the process of acquiring a complete trie. This is used when creating the missing nodes list. Missing nodes are those nodes that a SHAMap refers to but that are not stored in the local database.

    As a depth-first walk of a SHAMap is performed, if an inner node answers true to isFullBelow() then it is known that none of this node's children are missing nodes, and thus that subtree does not need to be walked. These nodes are stored in the FullBelowCache. Subsequent walks check the FullBelowCache first when encountering a node, and ignore that subtree if found.

    -

    +

    <tt>SHAMapTreeNode</tt>

    This is an abstract base class for the concrete node types. It holds the following common data:

    1. A hash
    2. An identifier used to perform copy-on-write operations
    -

    +

    <tt>SHAMapInnerNode</tt>

    SHAMapInnerNode publicly inherits directly from SHAMapTreeNode. It holds the following data:

      @@ -190,22 +190,22 @@ Canonicalize
    1. A bitset to indicate which of the 16 children exist.
    2. An identifier used to determine whether the map below this node is fully populated
    -

    +

    <tt>SHAMapLeafNode</tt>

    SHAMapLeafNode is an abstract class which publicly inherits directly from SHAMapTreeNode. It isIt holds the following data:

    1. A shared_ptr to a const SHAMapItem.
    -

    +

    <tt>SHAMapAccountStateLeafNode</tt>

    SHAMapAccountStateLeafNode is a class which publicly inherits directly from SHAMapLeafNode. It is used to represent entries (i.e. account objects, escrow objects, trust lines, etc.) in a state map.

    -

    +

    <tt>SHAMapTxLeafNode</tt>

    SHAMapTxLeafNode is a class which publicly inherits directly from SHAMapLeafNode. It is used to represent transactions in a state map.

    -

    +

    <tt>SHAMapTxPlusMetaLeafNode</tt>

    SHAMapTxPlusMetaLeafNode is a class which publicly inherits directly from SHAMapLeafNode. It is used to represent transactions along with metadata associated with this transaction in a state map.

    -

    +

    SHAMapItem

    This holds the following data:

      diff --git a/namespaceripple.html b/namespaceripple.html index 2df43649b1..c1f92bbfe8 100644 --- a/namespaceripple.html +++ b/namespaceripple.html @@ -8285,7 +8285,7 @@ template<class T >
    lsFATAL  -

    Definition at line 37 of file Log.h.

    +

    Definition at line 38 of file Log.h.

    @@ -11779,7 +11779,7 @@ template<typename E , -

    Definition at line 39 of file FileUtilities.cpp.

    +

    Definition at line 40 of file FileUtilities.cpp.

    @@ -11815,7 +11815,7 @@ template<typename E , -

    Definition at line 80 of file FileUtilities.cpp.

    +

    Definition at line 81 of file FileUtilities.cpp.

    diff --git a/namespaceripple_1_1test.html b/namespaceripple_1_1test.html index c940e1a25b..1e195db35c 100644 --- a/namespaceripple_1_1test.html +++ b/namespaceripple_1_1test.html @@ -5989,7 +5989,7 @@ template<typename PreVote = decltype(defaultPreVote)>
    -

    Definition at line 719 of file TrustedPublisherServer.h.

    +

    Definition at line 718 of file TrustedPublisherServer.h.

    diff --git a/overlay_2Slot_8h_source.html b/overlay_2Slot_8h_source.html index 545cbf7307..b193ad1036 100644 --- a/overlay_2Slot_8h_source.html +++ b/overlay_2Slot_8h_source.html @@ -795,7 +795,7 @@ $(function() {
    beast::Journal
    A generic endpoint for log messages.
    Definition: Journal.h:60
    beast::detail::aged_unordered_container
    Associative container where each element is also indexed by time.
    Definition: aged_unordered_container.h:88
    -
    ripple::Logs
    Manages partitions for logging.
    Definition: Log.h:51
    +
    ripple::Logs
    Manages partitions for logging.
    Definition: Log.h:52
    ripple::Peer::id_t
    std::uint32_t id_t
    Uniquely identifies a peer.
    Definition: xrpld/overlay/Peer.h:53
    ripple::PublicKey
    A public key.
    Definition: PublicKey.h:61
    ripple::Slice
    An immutable linear range of bytes.
    Definition: Slice.h:46
    diff --git a/reduce__relay__test_8cpp_source.html b/reduce__relay__test_8cpp_source.html index 465ede29ad..ca82afb647 100644 --- a/reduce__relay__test_8cpp_source.html +++ b/reduce__relay__test_8cpp_source.html @@ -1805,7 +1805,7 @@ $(function() {
    ripple::Config::loadFromString
    void loadFromString(std::string const &fileContents)
    Load the config from the contents of the string.
    Definition: Config.cpp:478
    ripple::Config::COMPRESSION
    bool COMPRESSION
    Definition: Config.h:220
    ripple::Config::VP_REDUCE_RELAY_SQUELCH_MAX_SELECTED_PEERS
    std::size_t VP_REDUCE_RELAY_SQUELCH_MAX_SELECTED_PEERS
    Definition: Config.h:254
    -
    ripple::Logs
    Manages partitions for logging.
    Definition: Log.h:51
    +
    ripple::Logs
    Manages partitions for logging.
    Definition: Log.h:52
    ripple::Logs::journal
    beast::Journal journal(std::string const &name)
    Definition: Log.cpp:160
    ripple::Peer
    Represents a peer connection in the overlay.
    Definition: xrpld/overlay/Peer.h:44
    ripple::Peer::id_t
    std::uint32_t id_t
    Uniquely identifies a peer.
    Definition: xrpld/overlay/Peer.h:53
    diff --git a/structripple_1_1test_1_1TrustedPublisherServer_1_1BlobInfo.html b/structripple_1_1test_1_1TrustedPublisherServer_1_1BlobInfo.html index 9c80c13357..f98ccbaacb 100644 --- a/structripple_1_1test_1_1TrustedPublisherServer_1_1BlobInfo.html +++ b/structripple_1_1test_1_1TrustedPublisherServer_1_1BlobInfo.html @@ -105,7 +105,7 @@ Public Attributes

    Detailed Description

    -

    Definition at line 102 of file TrustedPublisherServer.h.

    +

    Definition at line 103 of file TrustedPublisherServer.h.

    Constructor & Destructor Documentation

    ◆ BlobInfo()

    @@ -133,7 +133,7 @@ Public Attributes
    -

    Definition at line 104 of file TrustedPublisherServer.h.

    +

    Definition at line 105 of file TrustedPublisherServer.h.

    @@ -150,7 +150,7 @@ Public Attributes
    -

    Definition at line 109 of file TrustedPublisherServer.h.

    +

    Definition at line 110 of file TrustedPublisherServer.h.

    @@ -166,7 +166,7 @@ Public Attributes
    -

    Definition at line 111 of file TrustedPublisherServer.h.

    +

    Definition at line 112 of file TrustedPublisherServer.h.

    diff --git a/structripple_1_1test_1_1TrustedPublisherServer_1_1Validator.html b/structripple_1_1test_1_1TrustedPublisherServer_1_1Validator.html index 960f35f88a..8b603e1241 100644 --- a/structripple_1_1test_1_1TrustedPublisherServer_1_1Validator.html +++ b/structripple_1_1test_1_1TrustedPublisherServer_1_1Validator.html @@ -106,7 +106,7 @@ Public Attributes

    Detailed Description

    -

    Definition at line 115 of file TrustedPublisherServer.h.

    +

    Definition at line 116 of file TrustedPublisherServer.h.

    Member Data Documentation

    ◆ masterPublic

    @@ -120,7 +120,7 @@ Public Attributes
    -

    Definition at line 117 of file TrustedPublisherServer.h.

    +

    Definition at line 118 of file TrustedPublisherServer.h.

    @@ -136,7 +136,7 @@ Public Attributes
    -

    Definition at line 118 of file TrustedPublisherServer.h.

    +

    Definition at line 119 of file TrustedPublisherServer.h.

    @@ -152,7 +152,7 @@ Public Attributes
    -

    Definition at line 119 of file TrustedPublisherServer.h.

    +

    Definition at line 120 of file TrustedPublisherServer.h.

    diff --git a/structripple_1_1test_1_1TrustedPublisherServer_1_1lambda.html b/structripple_1_1test_1_1TrustedPublisherServer_1_1lambda.html index 8043919dd0..bad43cc48c 100644 --- a/structripple_1_1test_1_1TrustedPublisherServer_1_1lambda.html +++ b/structripple_1_1test_1_1TrustedPublisherServer_1_1lambda.html @@ -118,7 +118,7 @@ Public Attributes

    Detailed Description

    -

    Definition at line 417 of file TrustedPublisherServer.h.

    +

    Definition at line 416 of file TrustedPublisherServer.h.

    Constructor & Destructor Documentation

    ◆ lambda()

    @@ -158,7 +158,7 @@ Public Attributes
    -

    Definition at line 425 of file TrustedPublisherServer.h.

    +

    Definition at line 424 of file TrustedPublisherServer.h.

    @@ -178,7 +178,7 @@ Public Attributes
    -

    Definition at line 439 of file TrustedPublisherServer.h.

    +

    Definition at line 438 of file TrustedPublisherServer.h.

    @@ -195,7 +195,7 @@ Public Attributes
    -

    Definition at line 419 of file TrustedPublisherServer.h.

    +

    Definition at line 418 of file TrustedPublisherServer.h.

    @@ -211,7 +211,7 @@ Public Attributes
    -

    Definition at line 420 of file TrustedPublisherServer.h.

    +

    Definition at line 419 of file TrustedPublisherServer.h.

    @@ -227,7 +227,7 @@ Public Attributes
    -

    Definition at line 421 of file TrustedPublisherServer.h.

    +

    Definition at line 420 of file TrustedPublisherServer.h.

    @@ -243,7 +243,7 @@ Public Attributes
    -

    Definition at line 422 of file TrustedPublisherServer.h.

    +

    Definition at line 421 of file TrustedPublisherServer.h.

    @@ -259,7 +259,7 @@ Public Attributes
    -

    Definition at line 423 of file TrustedPublisherServer.h.

    +

    Definition at line 422 of file TrustedPublisherServer.h.