If the JobQueue is used during shutdown then those Jobs may access
Stoppables after they have already stopped. This violates the
preconditions of Stoppables and may lead to undefined behavior.
The solution taken here is to reference count all Jobs in the
JobQueue. At stop time all Jobs already in the JobQueue are
allowed to run to completion, but no further Jobs are allowed
into the JobQueue.
If a Job is rejected from the JobQueue (because we are stopping),
then JobQueue::addJob() returns false, so the caller can make any
necessary adjustments.
A full ledger on the production Ripple network could
exceed the default maximum reply size for the
HTTPClient code. Remove the reply size maximum for
responses that include a Content-Length header.
* Force jtx to request/receive the 2.0 API
* Force the JSON and WebSocket tests to use 2.0 API
* This specifically allows the Websocket to create 2.0 json/ripple
and get back a 2.0 response.
* Add test for malformed json2
* Add check for parse failure
* Add check for params to be in array form.
* Correct type-o discovered in tests due to stricter checking.
* Add API version to the WSClient & JSONRPCClient test
* Update source.dox with more headers
A recent commit (0d0227e744a81746714dee71c4c2c63d41e3e691) broke the
parser for the rpc command `account_lines` such that an empty
string ("") was no longer required for the second parameter. This commit
fixes that bug.
Note the empty peer field string requirement only applies to the rippled
command line. It can be comitted with a ledger via HTTP or WebSocket.
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.
Replace Journal public data members with member function accessors
in order to make Journal lighter weight. The change makes a
Journal cheaper to pass by value.
Also add missing stream checks (e.g., calls to JLOG) to avoid
text processing that ultimately will not be stored in the log.
The RippleAddress class was used to represent a number of fundamentally
different types: account public keys, account secret keys, node public
keys, node secret keys, seeds and generators.
The class is replaced by the following types:
* PublicKey for account and node public keys
* SecretKey for account and node private keys
* Generator for generating secp256k1 accounts
* Seed for account, node and generator seeds
The new code removes the ability to specify domain names
in the [validators] configuration block, and no longer
supports the [validators_site] option.
More details on the supported configurations are available
under doc/rippled-example.cfg.
In command line usage (only), the "sign", "submit", and "sign_for"
commands do not require the submitted JSON to be wrapped in a
tx_json object. Make the submit_multisigned command line behave
consistently with the command line form of those other commands.
Subscribe to "peer_status" stream (admin only) permits
reception of "peerStatusChange" notifications.
These can include the event the peer is reporting, the peer's
new status, the peer's currently accepted ledger hash and sequence,
the peer's network time, and the range of ledgers the peer has
available for remote querying.
o Remove warning written to log by sign_for command.
o The sign_for RPC command previously only worked in the
"json sign_for" form. The command now works as a straight
"sign_for". The "offline" parameter also works.
o Don't autofill Fee or Paths when signing offline.
Eventually multisign will need to be enabled onto the network, at
which point compiling it in or out will no longer be an option.
In preparation, the compile guards are removed and multisign is
being enabled with a Feature.
You can locally enable a Feature using your config file. To
enable multisign with your config file add a section like this:
[features]
MultiSign
The exact spelling and capitalization of both "features" and
"MultiSign" is important. If you don't get those right multisign
will not be enabled.
There is a minor issue. The "sign_for" and "submit_multisigned"
RPC commands are only enabled if multisign is enabled. However
those commands are still shown in the help message even if
multisign is disabled. This is because the code that produces
the help message doesn't read the config file (where the Features
are kept). This problem will become irrelevant once multisign is
enabled onto the network.
All AccountID functionality is removed from RippleAddress and
replaced with free functions. The AccountID to string conversion
cache is factored out as an explicit type with an instance in
the Application object. New base58 conversion functions are used,
with no dependence on OpenSSL.
All types and free functions related to AccountID are consolidated
into one header file. Routines to operate on "tokens" are also
introduced and consolidated into a single header file.
A token one of the cryptographic primitives used in Ripple:
Secret Seed
Server Public Key
Server Secret Key
Account ID
Account Public Key
Account Private Key
and these deprecated primitives:
Account Family Seed
Account Family Generator
