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.
This is designed for use by proxies in front of rippled. Configured IPs
can forward identifying user data in HTTP headers, including
user name and origin IP. If the user name exists, then resource limits
are lifted for that session. However, administrative commands are still
reserved only for administrative sessions.
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.
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.
* Add fields for local and remote IP addresses in hello.
* Add configuration for known local public IP address
* Set fields appropriately
* Check the fields
* Disallow self connection by key
* Do not forward manifests to peers that already know that manifest
* Do not forward historical manifests to peers
* Save/Load ValidatorManifests from a database
* Python test for setting ephmeral keys
* Cleanup manifest interface
* Deprecate rpc_admin_allow section from configuration file
* New port-specific setting 'admin':
* Comma-separated list of IP addresses that are allowed administrative
privileges (subject to username & password authentication if configured)
* 127.0.0.1 is no longer a default admin IP.
* 0.0.0.0 may be specified to indicate "any IP" but cannot be combined
with other IP addresses.
Inbound and outbound peer connections always use HTTP handshakes to
negotiate connections, instead of the deprecated TMHello protocol
message.
rippled versions 0.27.0 and later support both optional HTTP handshakes
and legacy TMHello messages, so always using HTTP handshakes should not
cause disruption. However, versions before 0.27.0 will no longer be
able to participate in the overlay network - support for handshaking
via the TMHello message is removed.
* A legacy value is a config section with a single-line.
* These values may be read from the BasicConfig interface so
the deprecated Config class does not need to be exposed to
clients.
* Made Config class more testable.
This adds support for a cgi /crawl request, issued over HTTPS to the configured
peer protocol port. The response to the request is a JSON object containing
the node public key, type, and IP address of each directly connected neighbor.
The IP address is suppressed unless the neighbor has requested its address
to be revealed by adding "Crawl: public" to its HTTP headers. This field is
currently set by the peer_private option in the rippled.cfg file.