All cases that still used the old RPF code now use new-style pathfinding.
This includes unit tests, RPF requests with a ledger specified, and RPF
requests in standalone mode.
Create SetRegularKey test to replace existing js test. Copy and simplify
some existing test logic from Env_test.cpp and MultiSign.test.cpp. Add
coverage for tfUniversalMask tx flag error case.
Payment channels permit off-ledger checkpoints of XRP payments flowing
in a single direction. A channel sequesters the owner's XRP in its own
ledger entry. The owner can authorize the recipient to claim up to a
give balance by giving the receiver a signed message (off-ledger). The
recipient can use this signed message to claim any unpaid balance while
the channel remains open. The owner can top off the line as needed. If
the channel has not paid out all its funds, the owner must wait out a
delay to close the channel to give the recipient a chance to supply any
claims. The recipient can close the channel at any time. Any transaction
that touches the channel after the expiration time will close the
channel. The total amount paid increases monotonically as newer claims
are issued. When the channel is closed any remaining balance is returned
to the owner. Channels are intended to permit intermittent off-ledger
settlement of ILP trust lines as balances get substantial. For
bidirectional channels, a payment channel can be used in each direction.
port of js test, account_objects-test.js
- bob account setup and rpc invoke
- error tests; no account, non-existant account, bad seed, validation
- combined unstepped testcase then stepped with limit/marker
Details
-------
* covers existing account_offers-test.js
* adds new coverage for results limiting and some
negative tests (bad input)
* fix bug in json value copying logic for bad seed/account error
case
* using new BEAST_EXPECT macros
cmake support in rippled. Currently supports:
* unity/nounity debug/release
* running protobuf
* sanitizer builds
* optional release build with assert turned on
* `target` variable to easily set compiler/debug/unity
(i.e. -Dtarget=gcc.debug.nounity)
* gcc/clang/visual studio/xcode
* linux/mac/win
* gcc 4 ABI, when needed
* ninja builds
* check openssl for acceptably recent release
* static builds
TBD:
* jemalloc support
* count
Notes:
* Use the -G"Visual Studio 14 2015 Win64" generator on Windows. Without
this a 32-bit project will be created. There is no way to set the
generator or force a 64-bit build in CMakeLists.txt (setting
CMAKE_GENERATOR_PLATFORM won't work). The best solution may be to
wrap cmake with a script.
* It is not possible to generate a visual studio project on linux or
mac. The visual studio generator is only available on windows.
* The visual studio project can be _either_ unity or
non-unity (selected at generation time). It does not appear possible
to disable compilation based on configuration.
* Language is _much_ worse than python, poor documentation and "quirky"
language support (for example, generator expressions can only be used
in limited contexts and seem to work differently based on
context (set_property can set multiple values, add_compile_options
can not/or is buggy)
* Could not call out to `sed` because cmake messed with the regular
expression before calling the external command. I did not see a way
around this.
* Makefile generators want to be single target. It wants a separate
directory for each target type. I saw some mentions on the web for
ways around this bug haven't look into it. The visual studio project
does support debug/release configurations in the same project (but
not unity/non-unity).
Log thread name and exception type on unhandled exceptions and use a
terminate handler to get a stack trace that includes the function that
thows the exception.
The Ripple protocol represent transfer rates and trust line
qualities as fractions of one billion. For example, a transfer
rate of 1% is represented as 1010000000.
Previously, such rates where represented either as std::uint32_t
or std::uint64_t. Other, nominally related types, also used an
integral representation and could be unintentionally substituted.
The new Rate class addresses this by providing a simple, type
safe alternative which also helps make the code self-documenting
since arithmetic operations now can be clearly understood to
involve the scaling of an amount by a rate.
The CBigNum class is a wrapper around OpenSSL's BIGNUM implementation
to make use simpler.
Replacing the implementation with boost::multiprecision helps reduce
the size of the codebase and improves performance (benchmarks show
the new boost-based implementation is ~7x faster).
Beast.WebSocket provides developers with a robust WebSocket
implementation built on Boost.Asio with a consistent asynchronous
model using a modern C++ approach.
New classes are introduced to represent HTTP messages and their
associated bodies. The parser interface is reworked to use CRTP,
error codes, and trait checks.
New classes:
* basic_headers
Models field/value pairs in a HTTP message.
* message
Models a HTTP message, body behavior defined by template argument.
Parsed message carries metadata generated during parsing.
* parser
Produces parsed messages.
* empty_body, string_body, basic_streambuf_body
Classes used to represent content bodies in various ways.
New functions:
* read, async_read, write, async_write
Read and write HTTP messages on a socket.
New concepts:
* Body: Represents the HTTP Content-Body.
* Field: A HTTP header field.
* FieldSequence: A forward sequence of fields.
* Reader: Parses a Body from a stream of bytes.
* Writer: Serializes a Body to buffers.
basic_parser changes:
* add write methods which throw exceptions instead
* error_code passed via parameter instead of return value
* fold private member calls into existing callbacks
* basic_parser uses CRTP instead of virtual members
* add documentation on Derived requirements for CRTP
impl/http-parser changes:
* joyent renamed to nodejs to reflect upstream changes
New classes:
class async_completion:
Helper class for implementing asynchronous initiation functions.
See n3964:
Library Foundations for Asynchronous Operations, Revision 1
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3964.pdf
class basic_streambuf:
Meets the requirements of Streambuf.
class buffered_readstream:
Buffers a ReadStream with a ConstBufferSequence.
class consuming_buffers:
Adapts a BufferSequence which wraps the underlying buffer
sequence and presents fewer bytes, with the retained bytes
occurring at the end of the sequence.
class handler_alloc:
A C++ Allocator the uses asio handler allocation hooks.
class static_streambuf:
An implementation of the Streambuf concept that uses a
fixed size buffer with size determined at compile-time.
class streambuf_readstream:
Buffers a ReadStream with a Streambuf.
New functions:
append_buffers()
Returns a new BufferSequence which efficiently concatenates
two or more buffer sequences together.
prepare_buffers()
Shortens a buffer sequence. The bytes excluded are at the
end of the underlying buffer sequence.
boost::asio::read_until()
A copy of boost::asio::read_until overloads, modified to work
with a beast::asio::basic_streambuf.
Debugging:
buffers_to_string()
Convert a ConstBufferSequence to a human readable string
suitable for diagnostics.
type_check.h:
Metafunctions for checking asio concepts:
AsyncReadStream, AsyncWriteStream
SyncReadStream, SyncWriteStream
ConstBufferSequence, MutableBufferSequence
Streambuf
Handler
Changes:
* All symbols moved up a namespace level.
* streambuf provides all move and copy special members,
behavior of moved from objects is well-defined.
Fixes:
* Fix basic_streambuf iterator category.
Add a new algorithm for finding the liquidity in a payment path. There
is still a reverse and forward pass, but the forward pass starts at the
limiting step rather than the payment source. This insures the limiting
step is completely consumed rather than potentially leaving a 'dust'
amount in the forward pass.
Each step in a payment is either a book step, a direct step (account to
account step), or an xrp endpoint. Each step in the existing
implementation is a triple, where each element in the triple is either
an account of a book, for a total of eight step types.
Since accounts are considered in pairs, rather than triples, transfer
fees are handled differently. In V1 of payments, in the payment path
A -> gw ->B, if A redeems to gw, and gw issues to B, a transfer fee is
changed. In the new code, a transfer fee is changed even if A issues to
gw.
