Very small payment could fail when STAmount::mulRound underflowed
and returned zero, when it should have rounded up to the smallest
representable value.
The existing delivered_amount logic will erroneously report
unavailable for ledgers that aren't in the network's live
chain because it is based solely on ledger sequence number.
This adds a check based on the ledger close time to permit
the code to give correct results in standalone mode and on
test networks.
Add a LedgerMaster function to get a ledger's
close time from either its hash or sequence number.
Use this function when adding the 'date' fields to
transaction JSON. This avoids constructing large numbers
of ledgers.
Added a safety to close the ledger quickly if there's
evidence validators we trust have already closed the
ledger. Base the minimum ledger open time on how long
we saw the ledger open. Do not rely on the rounded
close time for enforcing the minimum ledger open time.
* LastLedgerSequence
* Zero-fee txn has infinite fee level.
* Remove pseudo-transaction fee levels, since pseudos never get to the open ledger.
* preflight/preclaim failure cases
* Queued transaction failure handling.
Since a non-default STAccount is now guaranteed to always be
160 bits, it was possible to reduce the number of methods that
it provides.
In the process of narrowing the STAccount interface it became
reasonable to remove some methods that duplicated functionality.
A few classes offered both a value() and a getValue() method.
The getValue() method is removed from those classes.
If someone attempts to construct an STAccount with something
other than 160 bits the constructor now throws.
Since an STAccount now enforces that it always stores exactly
160 bits, we use a fixed-sized uint160 for the storage, replacing
a variable sized STBlob.
In order to leave the ledger and wire formats unaffected, the
STAccount still serializes and deserializes itself as though
it were variable length.
Multiple servers behind NAT might share a single public IP, making it
difficult for them to connect to the Ripple network since multiple
incoming connections from the same non-private IP are currently not
allowed.
RippleD now automatically allows between 2 and 5 incoming connections,
from the same public IP based on the total number of peers that it is
configured to accept.
Administrators can manually change the limit by adding an "ip_limit"
key value pair in the [overlay] stanza of the configuration file and
specifying a positive non-zero number. For example:
[overlay]
ip_limit=3
The previous "one connection per IP" strategy can be emulated by
setting "ip_limit" to 1.
The implementation imposes both soft and hard upper limits and will
adjust the value so that a single IP cannot consume all inbound slots.
Properly take close time rounding and monotonic ledger close times
into account when determining if we have a close time consensus.
In some cases, we send an extra proposal at the end of a round. This
can be removed once all servers have the correct end of round detection
logic.
If we built a different ledger from the one we ultimately
validate, log the status of the consensus round. This will
make it easier to rule out transaction processing issues
as the cause of these discrepancies and generally make them
easier to diagnose.
