ARCHIVE/rippled
1
0
Fork 0
mirror of https://github.com/XRPLF/rippled.git synced 2025-11-11 22:55:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix version to say 'rippled'

Browse Source
This commit is contained in:
Vinnie Falco
2014-07-04 17:34:08 -07:00
parent 8dc0844c79
commit 3ff919ccf1
5 changed files with 5 additions and 218 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
src/ripple/module/data/protocol/BuildInfo.cpp
View File

@@ -115,7 +115,7 @@ char const* BuildInfo::getFullVersionString ()
{
beast::String s;
s << "Ripple-" << getVersionString ();
s << "rippled-" << getVersionString ();
fullVersionString = s.toStdString ();
}

2
src/ripple/peerfinder/README.md
View File

@@ -117,8 +117,6 @@ value for outPeers:
**(Need example here)**
### Livecache
The Livecache holds relayed IP addresses that have been received recently in

127
src/ripple/peerfinder/README_WIP.md
View File

@@ -1,127 +0,0 @@
## Bootstrap Strategy
Fresh endpoints are ones we have seen recently via mtENDPOINTS.
These are best to give out to someone who needs additional
connections as quickly as possible, since it is very likely
that the fresh endpoints have open incoming slots.
Reliable endpoints are ones which are highly likely to be
connectible over long periods of time. They might not necessarily
have an incoming slot, but they are good for bootstrapping when
there are no peers yet. Typically these are what we would want
to store in a database or local config file for a future launch.
Nouns:
bootstrap_ip
numeric IPAddress
bootstrap_domain
domain name / port combinations, resolution only
bootstrap_url
URL leading to a text file, with a series of entries.
ripple.txt
Separately parsed entity outside of PeerFinder that can provide
bootstrap_ip, bootstrap_domain, and bootstrap_url items.
The process of obtaining the initial peer connections for accessing the Ripple
peer to peer network, when there are no current connections, is called
"bootstrapping." The algorithm is as follows:
1. If ( unusedLiveEndpoints.count() > 0
OR activeConnectionAttempts.count() > 0)
Try addresses from unusedLiveEndpoints
return;
2. If ( domainNames.count() > 0 AND (
unusedBootstrapIPs.count() == 0
OR activeNameResolutions.count() > 0) )
ForOneOrMore (DomainName that hasn't been resolved recently)
Contact DomainName and add entries to the unusedBootstrapIPs
return;
3. If (unusedBootstrapIPs.count() > 0)
Try addresses from unusedBootstrapIPs
return;
4. Try entries from [ips]
5. Try entries from [ips_urls]
6. Increment generation number and go to 1
- Keep a map of all current outgoing connection attempts
"Connection Strategy"
---------------------
This is the overall strategy a peer uses to maintain its position in the Ripple
network graph
We define these values:
peerCount (calculated)
The number of currently connected and established peers
outCount (calculated)
The number of peers in PeerCount that are outbound connections.
MinOutCount (hard-coded constant)
The minimum number of OutCount we want. This also puts a floor
on PeerCount. This protects against sybil attacks and makes
sure that ledgers can get retrieved reliably.
10 is the proposed value.
MaxPeerCount (a constant set in the rippled.cfg)
The maximum number of peer connections, inbound or outbound,
that a peer wishes to maintain. Setting MaxPeerCount equal to
or below MinOutCount would disallow incoming connections.
OutPercent (a baked-in program constant for now)
The peer's target value for OutCount. When the value of OutCount
is below this number, the peer will employ the Outgoing Strategy
to raise its value of OutCount. This value is initially a constant
in the program, defined by the developers. However, it
may be changed through the consensus process.
15% is a proposed value.
However, lets consider the case where OutDesired is exactly equal to MaxPeerCount / 2.
In this case, a stable state will be reached when every peer is full, and
has exactly the same number of inbound and outbound connections. The problem
here is that there are now no available incoming connection slots. No new
peers can enter the network.
Lets consider the case where OutDesired is exactly equal to (MaxPeerCount / 2) - 1.
The stable state for this network (assuming all peers can accept incoming) will
leave us with network degree equal to MaxPeerCount - 2, with all peers having two
available incoming connection slots. The global number of incoming connection slots
will be equal to twice the number of nodes on the network. While this might seem to
be a desirable outcome, note that the connectedness (degree of the overlay) plays
a large part in determining the levels of traffic and ability to receive validations
from desired nodes. Having every node with available incoming connections also
means that entries in pong caches will continually fall out with new values and
information will become less useful.
For this reason, we advise that the value of OutDesired be fractional. Upon startup,
a node will use its node ID (its 160 bit unique ID) to decide whether to round the
value of OutDesired up or down. Using this method, we can precisely control the
global number of available incoming connection slots.
"Outgoing Strategy"
-------------------
This is the method a peer uses to establish outgoing connections into the
Ripple network.
A peer whose PeerCount is zero will use these steps:
1. Attempt addresses from a local database of addresses
2. Attempt addresses from a set of "well known" domains in rippled.cfg
This is the method used by a peer that is already connected to the Ripple network,
to adjust the number of outgoing connections it is maintaining.
"Incoming Strategy"
------------------------------
This is the method used by a peer to announce its ability and desire to receive
incoming connections both for the purpose of obtaining additional peer connections
and also for receiving requests from clients.

88
src/ripple/peerfinder/TODO.md
View File

@@ -1,88 +0,0 @@
# PeerFinder TODO
- Add TestOverlay unit test that passes mtENDPOINTs messages
around and enforces connection policy using a custom Callback.
- Detect self connection
- Detect duplicate connection
- Migrate portions of Peer handling code
- Track more stats in Bootcache and report them in onWrite
- Test onPeerConnectionChanged() for PROXY handshakes
- Remove uptime, slots from mtENDPOINTS message.
- Finish mtENDPOINTS message-sending rate limit code.
- Make the graceful close state also work for active peers that we want to close.
- Fix FixedPeers correctly
- Keep track of which peers have sent us endpoints, and which endpoints we
have sent to peers, and try not to send a peer an endpoint that we have
either received from them, or sent to them lately.
- Use EphemeralCache as the name of the live endpoint cache.
- Rename Endpoint to Address where it makes sense to do so.
- Remove uptime, slots from mtENDPOINTS
- Consider removing featureList from mtENDPOINTS
* For security reasons we might want to only advertise other people's
features if we have verified them locally.
- Add firewalled test.
Consider ourselves firewalled (can't receive incoming connections) if:
* We have advertised ourselves for incomingFirewalledThresholdSeconds (Tuning.h)
without receiving an incoming connection.
- We may want to provide hooks in RPC and WSConnection logic that allows incoming
connections to those ports from public IPs to count as incoming connections for
the purpose of the firewalled tests.
- Send mtENDPOINTS if all these conditions are met:
1. We are not full
2. No incoming peer within the last incomingPeerCooldownSeconds (Tuning.h)
3. We have not failed the firewalled test
- When an outgoing attempt fails, penalize the entry if it exists in the
ephemeral cache as if it failed the listening test.
- Avoid propagating ephemeral entries if they failed the listening test.
- Make fixed peers more robust by remembering the public key and using it to
know when the fixed peer is connected regardless of whether the connection is
inbound.
- Track more stats in Bootcache and report them in onWrite
- Test onPeerConnectionChanged() for PROXY handshakes
- Remove uptime, slots from mtENDPOINTS message.
- Finish mtENDPOINTS message-sending rate limit code.
- Make the graceful close state also work for active peers that we want to close.
- Fix FixedPeers correctly
- Keep track of which peers have sent us endpoints, and which endpoints we
have sent to peers, and try not to send a peer an endpoint that we have
either received from them, or sent to them lately.
- Use EphemeralCache as the name of the live endpoint cache.
- Rename Endpoint to Address where it makes sense to do so.
- Remove uptime, slots from mtENDPOINTS
- Consider removing featureList from mtENDPOINTS
* For security reasons we might want to only advertise other people's
features if we have verified them locally.
- Add firewalled test.
Consider ourselves firewalled (can't receive incoming connections) if:
* We have advertised ourselves for incomingFirewalledThresholdSeconds (Tuning.h)
without receiving an incoming connection.
- We may want to provide hooks in RPC and WSConnection logic that allows incoming
connections to those ports from public IPs to count as incoming connections for
the purpose of the firewalled tests.
- Send mtENDPOINTS if all these conditions are met:
1. We are not full
2. No incoming peer within the last incomingPeerCooldownSeconds (Tuning.h)
3. We have not failed the firewalled test
- When an outgoing attempt fails, penalize the entry if it exists in the
ephemeral cache as if it failed the listening test.
- Avoid propagating ephemeral entries if they failed the listening test.
- Make fixed peers more robust by remembering the public key and using it to
know when the fixed peer is connected regardless of whether the connection is
inbound.

4
src/ripple/peerfinder/impl/Manager.cpp
View File

@@ -17,6 +17,10 @@
*/
//==============================================================================
#if DOXYGEN
#include <ripple/overlay/README.md>
#endif
namespace ripple {
namespace PeerFinder {