This introduces the STVar container, capable of holding any STBase-derived
class and implementing a "small string" optimization. STObject is changed
to store std::vector<STVar> instead of boost::ptr_vector<STBase>. This
eliminates a significant number of needless dynamic memory allocations and
deallocations during transaction processing when ledger entries are
deserialized. It comes at the expense of larger overall storage requirements
for STObject.
General RPC command that can retrieve objects in the account root.
* Add account objects integration test.
* Support tickets.
* Add removeElement in Json::Value
* Each peer has a "sane/insane/unknown" status
* Status updated based on peer ledger sequence
* Status reported in peer json
* Only sane peers preferred for historical ledgers
* Overlay endpoints only accepted from known sane peers
* Untrusted proposals not relayed from insane peers
* Untrusted validations not relayed from insane peers
* Transactions from insane peers are not processed
* Periodically drop outbound connections to bad peers
* Bad peers get bootcache valence of zero
Peer "sanity" is based on the ledger sequence number they are on. We
quickly become able to assess this based on current trusted validations.
We quarrantine rogue messages and disconnect bad outbound connections to
help maintain the configured number of good outbound connections.
In some corner cases, an incorrect resume marker could be
returned, preventing the complete enumeration of account
transactions.
* Robust markers via improved paging support
* New unit tests
* Cleanup
The analysis of differences between locally built ledgers and consensus
ledgers is now more intelligent. Differences in these values will be
categorized:
- Operation results
- Transaction ordering
- Generated metadata
* Support PreviousTxnID until the switchover
* Implement "No Ripple" for issue_iou and redeem_iou.
* Do not utilize issue_iou and redeem_iou from legacy code
* Rename 0.27.x legacy files to account for VS build process
* Misc. cleanups
* Set transaction valid in hash router correctly
* Properly account for root nodes in walkLedger
* If loaded ledger is insane, log details
* Extra logging while loading replay ledger
* Don't test unsigned transactions expecting them to succeed
* Don't be too noisy about signature failures
In some code paths, we bump the SHAMap sequence number
before we unshare. This forces SHAMapTreeNode to be
copied. By making the ledger immutable we cause the
unsharing to occur earlier, eliminating the copies.
This creates a new InboundTransactions object that handles transaction sets,
removing this responsibility from the consensus object. The main benefit is
that many inbound transaction operations no longer require the master lock.
Improve logic to decide which peers to query, when to add more peers, and
when to re-query existing peers.
Certain checks that determine if a transaction is malformed can be performed
without needing to look up accounts or access the ledger.
Perform those checks as early as possible to optimize transaction processing.
* Performance motivated.
* Several of these called size() which is O(N) in gcc-4.8.
* Remove container copy from LedgerConsensusImp::playbackProposals().
* Addresses RIPD-284.
* Don't acquire the master lock where it's not needed
* InfoSub tracks RT and validated accounts separately
* Correctly remove accounts from the InfoSub
* Brings the soci subtree into rippled.
* Validator, peerfinder, and SHAMapStore use new soci backend.
* Optional postgresql backend for soci (if POSTGRESQL_ROOT env var is set).
AccountSet set/clear, asfDefaultRipple = 8
AccountRoot flag, lsfDefaultRipple = 0x00800000
In trustCreate, set no ripple flag if appropriate.
If an account does not have the default ripple flag set,
new ripple lines created as a result of its offers being
taken or people creating trust lines to it have no ripple
set by that account's side automatically
Trust lines can be deleted if the no ripple flag matches
its default setting based on the account's default ripple
setting.
Fix default no-rippling in integration tests.
Changes made to support autobridging and improve the offer-crossing and
pathfinding logic result in transaction-breaking changes which cause
incompatibilities between 0.27 and 0.28 builds of RippleD.
This patch simplifies deployment of 0.28 on the Ripple network by allowing
RippleD to emulate the 0.27 semantics while the last closed ledger closed
before March 30, 2015 at 13:00:00 PDT, after which time the new 0.28
semantics will become active.
The transaction-breaking changes addressed in this commit are:
3ccbd7c9b2b203db27a4
This adds a limit of 1,000 passes to the payment engine. It protects against
possible cases where the execution of a pass fails to exhaust the liquidity
that made the pass possible or cases where two passes alternate providing
liquidity for each other.
* Compute the effective recipient.
* Make sure the effective recipient exists.
* Prohibit paths to the recipient, if not the effective recipient.
* Treat paths to the effective recipient as complete.
* Don't find looped paths.
* Use the effective recipient for getPathsOut weight.
* When starting up, we no longer rely just on the standard
system RNG to generate entropy: we attempt to squeeze some
from the execution state, and to recover any entropy that
we had previously stored.
* When shutting down, if sufficient entropy has been accumulated
attempt to store it for future use.
