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.
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.
* SConstruct will set ABI based on ubuntu flavor
* Script to bring in packages for various ubuntu flavors
* Script to bring in packages for various fedora 22
* Remove unneeded environment variable from travis
* Script to build boost with correct API flags
* `--static` flag to control static linking
* Move InboundTransactions to app/ledger
* Move TransactionAcquire to app/ledger
* Move LocalTxs to app/ledger
* Move Transaction to app/misc
* Move TransactionMaster to app/ledger
The first few transactions are added to the open ledger at
the base fee (ie. 10 drops). Once enough transactions are
added, the required fee will jump dramatically. If additional
transactions are added, the fee will grow exponentially.
Transactions that don't have a high enough fee to be applied to
the ledger are added to the queue in order from highest fee to
lowest. Whenever a new ledger is accepted as validated, transactions
are first applied from the queue to the open ledger in fee order
until either all transactions are applied or the fee again jumps
too high for the remaining transactions.
Current implementation is restricted to one transaction in the
queue per account. Some groundwork has been laid to expand in
the future.
Note that this fee logic escalates independently of the load-based
fee logic (ie. LoadFeeTrack). Submitted transactions must meet
the load fee to be considered for the queue, and must meet both
fees to be put into open ledger.
* Remove cxx14 compatibility layer from ripple
* Update travis to clang 3.6 and drop gcc 4.8
* Remove unneeded beast CXX14 defines
* Do not run clang build with gdb with travis
* Update circle ci to clang 3.6 & gcc-5
* Don't run rippled in gdb, clang builds crash gdb
* Staticly link libstdc++, boost, ssl, & protobuf
* Support builds on ubuntu 15.10
o The sign_for RPC command automatically fills in an empty
"SigningPubKey" field if the field is missing.
o The sign_for command returns the Signers list inside the
tx_json. This re-establishes symmetry with the
submit_multisigned command. It also means the returned
tx_blob might be useful, since it contains the multisignature.
o The sign_for command also now allows the inclusion of a Signers
array field in the input tx_json. If a Signers array is present,
the new signature is incorporated into the passed array. This
supports a model where multisignatures are accumulated serially.
o Syntax hints are improved.
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.
The digest for a transaction (its transaction ID, or tid) is
computed once upon constructed when the STTx is deserialized.
Subsequent calls to retrieve the digest use the cached value.
Any code which modifies the STTx and then attempts to
retrieve the digest will terminate the process with a
logic error contract violation.
* Nested types removed
* All STTx are contained as const
(Except in transaction sign, which must modify)
* tid in STTx is computed once on deserialization