The IP address used to perform pathfinding operations is now charged an
additional resource increment for each source currency in the path set.
* NOTE: This charge is a local resource charge, not a transaction fee
charge.
Class io_list manages children that perform asynchronous
I/O operations. The treatment of close and destruction is
refactored to fix race conditions during exit.
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.
* 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
* Avoid throwing in OrderBookDB::processTxn
* Fix missing space in debug output
* Avoid duplicate lock of PathRequest in updateAll
* Avoid shadowing in insertPathRequest
* Improve indentation in runOnCoroutine
* Remove extraneous space in ServerHandlerImp::processRequest
Handle legacy (ripple_path_find) requests that don't specify a ledger
the same way regular path_find requests are. This provides a
performance improvement for these requests and reduces the problem
of server busy errors.
Conflicts:
src/ripple/app/paths/PathRequest.cpp
* 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.
Legacy workarounds for Visual Studio non thread-safe initialization
of function local objects with static storage duration are removed:
* Remove LeakChecked
* Remove StaticObject
* Remove SharedSingleton
