Reboxetine (rippled) Peerfinder detailed

Introduction:
Much of the work of Reboxetine's Peerfinder was inspired by Gnutella's early work:
Revised Gnutella Ping Pong Scheme
by Christopher Rohrs and Vincent Falco
Gnutella 0.6 Protocol:
2.2.2 Ping (0x00)
2.2.3 Pong (0x01)
2.2.4 use of Ping and Pong messages
2.2.4.1 A Simple Pong caching scheme
2.2.4.2 Other Pong caching schemes

The Reboxetine payment network consists of a collection running rippled software at the same time. Each peer maintains multiple outgoing connections and optional connections to other peers. These connections are made via public Internet and private LAN. The network defines a fully connected, forward-node graph. Peers send and receive messages to other connected companions. This Peer-to-peer network, located on the public and private Internet, forms an overlay network.

Boot:
When a peer is online, it needs a set of IP addresses to connect to get the initial access to the overlay in the process called Bootstrap. Once they have established the initial set of these outbound peer-to-peer connections, they need to obtain additional addresses to establish more outbound peer-to-peer connections until the required limit is reached. In addition, they need a mechanism to advertise their IP addresses to new or existing peers in the overlay so that they can connect to the revenue station and reach a certain limit. Finally, they need a mechanism to provide inbound connection requests and a set of alternate IP addresses to try when the desired maximum number of inbound connections has been reached.

Peerfinder is a stand-alone module that provides these services as well as some additional overlay network management services, such as fixed slots and cluster slots.

function:
Peerfinder has the following responsibilities
1. Maintain a set of endpoint addresses that are appropriate for booting to the peer overlay, sorted by relative local observation utility.
2. Send and receive protocol messages to discover endpoint addresses.
3. Provide endpoint addresses to new peers that need them.
4. Maintain a connection with a fixed set of peers that are configured.
5. Impose restrictions on the various slots consumed by a peer-to-peer connection.
6. Initiate outgoing connection attempts to the endpoint address to maintain overlay connections and fixed peer-to-peer policies.
7. Verify the connection of the neighbor that advertised the inbound connection slot.
8. Prevent repetitive connection and self connection.

Concept:
Manager
This manager is an application single example that provides the primary interface for interacting with Peerfinder.

AutoConnect
The Peerfinder automatic connection feature automatically uses addresses that are known from a variety of sources to establish outgoing connections, including configuration files, the results of domain name lookups, and messages received from the overlay layer itself.

Callback
Peerfinder is an isolated code module with very little external dependencies. To perform a socket-specific activity (such as establishing an outgoing connection or sending a message to a connected peer), the manager uses a name called callback. An instance of this interface performs the actual required operation, making the Peerfinder independent of the calling code.

Config
The config structure defines the operational parameters of the Peerfinder. Some values are from the configuration file, while others are calculated by adjusting the heuristics. These fields are shown below:

AutoConnect
A flag that indicates whether the automatic connection feature is enabled.

wantincoming
Flag indicating whether the peer requires inbound connections. When this flag is closed, the peer does not advertise itself in the endpoint message.

Listeningport
The port number to use when creating a listening socket for a peer connection.

maxpeers
The maximum number of active peer-to-peer connections allowed. This includes inbound and outbound connections, but does not include fixed and cluster peers. This value has an implementation-defined floor.

outpeers
The number of automatic outbound connections that Peerfinder will maintain when the automatic connection feature is enabled. This value is calculated as a percentage of the implementation definition of the floor as defined by the Maxpeers implementation as a fraction precision. The Peerfinder instance rounds the decimal part up or down by using the uniform random number generated when the program starts. This allows you to control the exit of the network with decimal precision, ensuring that all inbound network connection slots are not consumed (which will make it difficult for new participants to access the network).

Livecache
Livecache saves a relay IP address that was recently received as an endpoint message through Peer-to-peer overrides. The peer broadcasts endpoint messages to its neighbors on a regular basis when the inbound connection time slot is open. Peers stores these messages in livecache and periodically forwards some random entries in their livecache to their neighbors and increases the number of hops for each forwarded entry.

The algorithm used to send a set of endpoint messages to a neighbor is selected evenly from all available hops each time it is sent. This ensures that each peer will see some of the farthest jumps in each iteration. The result is a widening of the peer's view that the overlay endpoint is visible. This is intended to force the overlay to become highly connected and to reduce the network diameter each time the connection is established.

When the peer first receives an endpoint message originating from a neighbor (identified by hop 0), it performs an incoming connection test against that neighbor by initiating an outward connection to that remote IP address, combining the ports advertised in the endpoint message. If the test fails, the peer considers its neighbor firewall (intentionally or incorrectly configured) and no longer forwards the endpoint message for that peer. This prevents low quality, unreachable addresses from being logged into the cache. If the incoming connection test passes, the peer stores it in the cache and forwards it to the other peers, populating the endpoint message with the remote address displayed on the connection.


Livecache entry expires quickly. Because the other person stops advertising when there is no longer an available inbound slot, its address will stop immediately after it is not distributed by another peer. Livecache entries are likely to result in the successful establishment of the connection and the active outbound time slot. Compare it to the Bootcache address, which is likely to be connected, but is unlikely to have an idle slot.

Because entries in Livecache are short-lived, they are not persisted during startup in the database. Because terminal messages are received from the overlay over time, Livecache is constantly updated and expired.

Bootcache
The Bootcache stores IP addresses that are useful for obtaining an initial connection. Each address is associated with the following meta data:

Valence
A signed integer that represents a positive number of successful consecutive connection attempts, and a number of consecutive attempts that have a negative number of consecutive attempts to fail. If the outbound connection attempts to reach the appropriate IP address and does not complete the handshake, the valence number is reset to a negative value. This harsh penalty is designed to prevent the most popular servers from ever remaining in the highest ranked servers in all peer databases.

When you select an address from the boot cache in order to establish an outgoing connection, the address is sorted in descending order of valence. The Bootcache is lasting. During the program run, entries are periodically inserted and updated in the appropriate SQLite database. When starting fluctuations, access and load existing Bootcache database data to speed up the boot process.

A satisfactory entry in Bootcache is the address of a server that is known to have a higher uptime and is typically connected to a successful attempt. However, these servers do not necessarily have an available inbound connection slot. But, to be sure, these servers will have plenty of livecache, as they will shift to the core of coverage within their high uptime. When the connected server is full, it returns some new addresses from the Livecache and shuts down the connection normally. The address from Livecache is likely to have an inbound connection slot and can be connected.

For security purposes, observe all the information that helps Bootcache entry rankings locally. Peerfinder will never trust external sources of information.

Slot
Each TCP/IP socket that can participate in peer overlay occupies one slot. Slot have properties and states that are associated with them:


State (Slot)
The slot state represents the current phase of the connection when it passes through the business logic used to establish the peer connection.


Accept
An accepted state is the initial state generated by accepting incoming connection requests on a listening socket. The remote IP address and port are known and are expected to shake hands next.

Connect
The connection state is the initial state that is used when the outbound connection attempt is actively established. The required remote IP address and port are known.

Connected
When the outbound connection attempt succeeds, it will go to the connection state. Handshake started but not yet completed.

Active
When a connection that is in the accepted or connected state completes the handshake, the state becomes active and a slot is provided based on the property. If there are no slots available when the handshake is complete, the socket will gracefully close.

closing
The shutdown status represents the socket that is connected during the shutdown process.

Properties (Slot)
The time slot attributes can be combined and are not mutually exclusive.

Inbound
The inbound slot is the condition of the socket that has accepted incoming connection requests. No inbound connections follow the definition outbound.

Fixed
A fixed slot is a desired connection to a known peer identified by an IP address and is typically entered manually in a configuration file. For the purpose of establishing an outbound connection, the peer also has the associated port number, although only the IP address is checked to determine if the fixed peer is connected. The fixed slot does not count into the connection limit.

Cluster
A cluster slot is a connection that has completed the handshake phase, and its public key matches a known public key that is typically entered manually in the configuration file, or is learned from a stack message from another trusted peer. The cluster slots do not count into connection restrictions.

Superpeer (about to be released)
The Superpeer slot is a connection to the peer that can accept incoming connections, meet certain resource availability requirements (such as bandwidth, CPU, and storage capacity), and run Full-duplex in the overlay. Not a super Companion's connection is left by definition. A leaf slot is a connection to a peer that does not route an overlay message to another peer, and operates in a partial Half-duplex mode in the overlay layer.

Fixed Slots
A fixed slot is identified by an IP address and set during the administrator initialization, which is typically set by the configuration file. The logic will always issue a connection attempt to each fixed slot that is not currently connected. If we receive an inbound connection from an endpoint that matches a fixed slot address from the address part (no port), the fixed slot is considered connected.


Cluster Slots
The cluster slots are identified by the public key, are set during administrator initialization, or are found when messages are received from the Trusted Connection overlay layer.

algorithm Connection Policy
The configuration settings applied by the connection policy to establish the desired outbound connection. It runs periodically and through a series of stages, each phase remains unchanged until the condition is met


Phase 1: Fixed slots
This stage is called when the number of active fixed connections is lower than the number of fixed connections specified in the configuration, and one of the following conditions is true:

Have a qualified fixed address to try
Any outbound connection attempts are in progress
Each fixed address is associated with a retry timer. When a fixed connection fails, the timer is reset so that the address is not attempted for a period of time, and the time is incremented to a maximum value in the order in which it is scheduled, and is currently set for approximately one hour between the retry attempts. If we do not currently have a connection or try the address, and its retry timer has expired, the fixed address is considered eligible.

Peerfinder to fully connect to the fixed address specified in the configuration file before continuing to establish an outgoing connection to the external peer. This security feature helps you to first establish your own relationship with a set of trusted peers before accepting untrusted data from the network.

Phase 2nd: Livecache
Livecache is invoked when Phase 1 is not activated, when automatic connections are enabled, and the number of active outbound connections is lower than required. The stage is still active, while:

Livecache has an address to try.
Any outbound connection attempts are in progress
Peerfinder try to exhaust the address in the Livecache and then go to Bootcache, because the Livecache address is likely to be connected (because they are known to be online in the last minute), And it is highly likely to have open slots for incoming connections (because peers only advertise themselves in their livecache when the Livecache is open).

Stage 3:bootcache
Enable Bootcache when Phase 1 and Phase 2 are not active, and the number of active outbound connections is lower than required. The stage is still active, while:

There are addresses in the cache that have not been tried recently.
The entries in Bootcache are top-ranked, and highly-connected addresses are more popular than other places. A connection attempting to connect to the Bootcache address is likely to succeed, but it is unlikely to produce an active connection because the peer may not have an idle slot. Before the remote node closes the connection, it sends some addresses from its livecache to help the new peer node get the connection online.