mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 20:05:50 +00:00
Merge pull request #750 from mDuo13/validator_peer_mgmt
Improved Peer Management Docs
This commit is contained in:
Rome Reginelli
4
content/_snippets/peer_reservation_object.md
Normal file
4
content/_snippets/peer_reservation_object.md
Normal file
@@ -0,0 +1,4 @@
|
||||
| `Field` | Type | Description |
|
||||
|:--------------|:-------|:----------------------------------------------------|
|
||||
| `node` | String | The [node public key][] of the peer server this reservation is for, as [base58][]. |
|
||||
| `description` | String | _(May be omitted)_ The description provided with this peer reservation, if any. |
|
||||
@@ -23,6 +23,9 @@
|
||||
[ledger format]: ledger-data-formats.html
|
||||
[Marker]: markers-and-pagination.html
|
||||
[マーカー]: markers-and-pagination.html
|
||||
[node public key]: peer-protocol.html#node-key-pair
|
||||
[peer reservation]: peer-protocol.html#fixed-peers-and-peer-reservations
|
||||
[peer reservations]: peer-protocol.html#fixed-peers-and-peer-reservations
|
||||
[result code]: transaction-results.html
|
||||
[seconds since the Ripple Epoch]: basic-data-types.html#specifying-time
|
||||
[Rippleエポック以降の経過秒数]: basic-data-types.html#時間の指定
|
||||
@@ -93,6 +96,9 @@
|
||||
"logrotate",
|
||||
"noripple_check",
|
||||
"path_find",
|
||||
"peer_reservations_add",
|
||||
"peer_reservations_del",
|
||||
"peer_reservations_list",
|
||||
"peers",
|
||||
"ping",
|
||||
"print",
|
||||
|
||||
@@ -28,7 +28,7 @@ protocol = peer
|
||||
|
||||
ピアプロトコルポートは[特殊なPeer Crawler APIメソッド](peer-crawler.html)も処理します。
|
||||
|
||||
### ノードキーペア
|
||||
## ノードキーペア
|
||||
|
||||
サーバーを初めて起動すると、ピアプロトコル通信でサーバー自体を識別するための _ノードキーペア_ が生成されます。サーバーはこのキーを使用して、ピアプロトコル通信のすべてに署名します。これにより、ピアツーピアネットワーク内の別のサーバーからのメッセージの整合性を、信頼できる方法で識別、検証できます。これは、そのサーバーのメッセージが信頼できないピアにより中継される場合も同様です。
|
||||
|
||||
@@ -37,6 +37,12 @@ protocol = peer
|
||||
ノードキーペアは、このサーバーと共に[クラスター化](clustering.html)されている他のサーバーも識別します。サーバークラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバーを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
|
||||
|
||||
|
||||
## Fixed Peers and Peer Reservations
|
||||
<a id="pros-and-cons-of-peering-configurations"></a> <!-- TODO: remove this anchor when the corresponding section is translated -->
|
||||
|
||||
**注意:** 現在の所はこの部分は日本語では利用できません。[英語版](/{{currentpage.html}})をご覧下さい。
|
||||
|
||||
|
||||
## プライベートピア
|
||||
|
||||
`rippled`サーバーが「プライベート」サーバーとして動作するように設定し、そのIPアドレスを非公開にすることができます。これは、信頼できるバリデータなどの重要な`rippled`サーバーへのサービス拒否攻撃や侵入の試みに対する予防対策として有用です。ピアツーピアネットワークに参加するには、プライベートサーバーは1つ以上の非プライベートサーバーに接続するように設定されている必要があります。この非プライベートサーバーにより、メッセージがネットワークのその他の部分へ中継されます。
|
||||
|
||||
@@ -11,11 +11,24 @@ The peer protocol is the main mode of communication between servers in the XRP L
|
||||
|
||||
To establish a peer-to-peer connection, one server connects to another via HTTPS and requests an [HTTP upgrade](https://tools.ietf.org/html/rfc7230#section-6.7) to switch to RTXP. (For more information, see the [Overlay Network](https://github.com/ripple/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake) article in the [`rippled` repository](https://github.com/ripple/rippled).)
|
||||
|
||||
## Peer Discovery
|
||||
|
||||
The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it reconnects to any other peers it previously connected to. As a fallback, it uses the [hardcoded public hubs](https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). After a server successfully connects to a peer, it asks that peer for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server establishes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.
|
||||
|
||||
Typically, a server needs to connect to a public hub only once, for a short amount of time, to find other peers. After doing so, the server may or may not remain connected to the hub, depending on how stable its network connection is, how busy the hub is, and how many other high-quality peers the server finds. The server saves the addresses of these other peers so it can try reconnecting directly to those peers later, after a network outage or a restart.
|
||||
|
||||
The [peers method][] shows a list of peers your server is currently connected to.
|
||||
|
||||
For certain high-value servers (such as important [validators](rippled-server-modes.html#rippled-server-modes)) you may prefer not to have your server connect to untrusted peers through the peer discovery process. In this case, you can configure your server to use [private peers](#private-peers) only.
|
||||
|
||||
|
||||
## Peer Protocol Port
|
||||
|
||||
To participate in the XRP Ledger, `rippled` servers connect to arbitrary peers using the peer protocol. (All peers are treated as untrusted, unless they are [clustered](clustering.html) with the current server.)
|
||||
|
||||
Ideally, the server should be able to send _and_ receive connections on the peer port. You should forward the port used for the peer protocol through your firewall to the `rippled` server. The [default `rippled` config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg) listens for incoming peer protocol connections on port 51235 on all network interfaces. You can change the port used by editing the appropriate stanza in your `rippled.cfg` file.
|
||||
Ideally, the server should be able to send _and_ receive connections on the peer port. You should [forward the port used for the peer protocol through your firewall](forward-ports-for-peering.html) to the `rippled` server.
|
||||
|
||||
The [default `rippled` config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg) listens for incoming peer protocol connections on port 51235 on all network interfaces. You can change the port used by editing the appropriate stanza in your `rippled.cfg` file.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -28,19 +41,34 @@ protocol = peer
|
||||
|
||||
The peer protocol port also serves the [special Peer Crawler API method](peer-crawler.html).
|
||||
|
||||
### Node Key Pair
|
||||
## Node Key Pair
|
||||
|
||||
When a server first starts up, it generates a _node key pair_ to use to identify itself in peer protocol communications. The server uses its key to sign all its peer protocol communications. This makes it possible to reliably identify and verify the integrity of messages from another server in the peer-to-peer network even if that server's messages are being relayed by untrusted peers.
|
||||
|
||||
The node key pair is saved in the database and reused when the server restarts. If you delete the server's databases, it creates a new node key pair, effectively coming online with a different identity. To reuse the same key pair even if the databases are deleted, you can configure the server with a `[node_seed]` stanza. To generate a value suitable for use in the `[node_seed]` stanza, use the [validation_create method][].
|
||||
|
||||
The node key pair also identifies other servers [clustered](clustering.html) with this one. If you have a cluster of servers, you should configure each server in the cluster with a unique `[node_seed]` setting. For more information on setting up a cluster, see [Cluster `rippled` Servers](cluster-rippled-servers.html).
|
||||
The node key pair also identifies other servers for purposes of [clustering](clustering.html) or [reserving peer slots](#fixed-peers-and-peer-reservations). If you have a cluster of servers, you should configure each server in the cluster with a unique `[node_seed]` setting. For more information on setting up a cluster, see [Cluster `rippled` Servers](cluster-rippled-servers.html).
|
||||
|
||||
|
||||
## Fixed Peers and Peer Reservations
|
||||
|
||||
Normally, a `rippled` server attempts to maintain a healthy number of peers, and automatically connects to untrusted peers up to a maximum number. You can configure a `rippled` server to remain connected to specific peer servers in several ways:
|
||||
|
||||
- Use **Fixed Peers** to remain always connected to specific other peers based on their IP addresses. This only works if the peers have fixed IP addresses. Use the `[ips_fixed]` config stanza to configure fixed peers. This is a necessary part of [clustering](clustering.html) or [private peers](#private-peers). Fixed peers are defined in the config file, so changes only apply after restarting the server. Fixed peers are most useful for keeping servers connected if those servers are run by the same person or organization.
|
||||
- Use **Peer Reservations** to prioritize specific peers. If your server has a peer reservation for a specific peer, then your server always accepts connection requests from that peer even if your server is already at its maximum number of connected peers. (This can cause your server to go _over_ the maximum number of peers.) You identify a reserved peer by its [node key pair](#node-key-pair), so you can do this even for peers with variable IP addresses. Peer reservations are configured through admin commands and saved in the server databases, so they can be adjusted while the server is online and are saved across restarts. Peer reservations are most useful for connecting servers operated by different people or organizations. [New in: rippled 1.4.0][]
|
||||
|
||||
In the following cases, a `rippled` server does not connect to untrusted peers:
|
||||
|
||||
- If the server is configured as a [private peer](#private-peers), it connects _only_ to its fixed peers.
|
||||
- If the server is running in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode) it does not connect to _any_ peers.
|
||||
|
||||
|
||||
## Private Peers
|
||||
|
||||
You can configure a `rippled` server to act as a "private" server to keep its IP address hidden from the general public. This can be a useful precaution against denial of service attacks and intrusion attempts on important `rippled` servers such as trusted validators. To participate in the peer-to-peer network, a private server must be configured to connect to at least one non-private server, which relays its messages to the rest of the network.
|
||||
|
||||
**Caution:** If you configure a private server without any [fixed peers](#fixed-peers-and-peer-reservations), the server cannot connect to the network, so it cannot know network state, broadcast transactions, or participate in the consensus process.
|
||||
|
||||
Configuring a server as a private server has several effects:
|
||||
|
||||
- The server does not make outgoing connections to other servers in the peer-to-peer network unless it has been explicitly configured to connect to those servers.
|
||||
@@ -51,22 +79,65 @@ Configuring a server as a private server has several effects:
|
||||
|
||||
**Caution:** It is possible to modify a server's source code so that it ignores this request and shares its immediate peers' IP addresses anyway. You should configure your private server to connect only to servers that you know are not modified in this way.
|
||||
|
||||
### Pros and Cons of Peering Configurations
|
||||
|
||||
To be part of the XRP Ledger, a `rippled` server must be connected to the rest of the open peer-to-peer network. Roughly speaking, there are three categories of configurations for how a `rippled` server connects to the network:
|
||||
|
||||
- Using **discovered peers**. The server connects to any untrusted servers it finds and stays connected as long as those servers behave appropriately. (For example, they don't request too much data, their network connections are stable, and they appear to be following the same [network](parallel-networks.html).) This is the default.
|
||||
- As a **private server using proxies** run by the same person or organization. The proxies are stock `rippled` servers (also connected to discovered peers) that maintain a fixed peering connection with the private server.
|
||||
- As a **private server using public hubs**. This is similar to using proxies, but it relies on specific third parties.
|
||||
|
||||
The pros and cons of each configuration are as follows:
|
||||
|
||||
|
||||
<table>
|
||||
<thead><tr>
|
||||
<th>Configuration</th> <th>Pros</th> <th>Cons</th>
|
||||
</tr></thead>
|
||||
<tbody>
|
||||
<tr><th>Discovered Peers</th>
|
||||
<td><ul>
|
||||
<li><p>Simplest configuration, with a low maintenance burden.</p></li>
|
||||
<li><p>Creates the opportunity for a lot of direct peer connections. Having more direct peers comes with several benefits. Your server can <a href="ledger-history.html#fetching-history">fetch history</a> from multiple peers in parallel, both when syncing and when backfilling history. Since not all peers maintain full history, having access to more peers can also provide access to a wider selection of historical data.</p></li>
|
||||
<li><p>Lowers the possibility of disconnecting from the network because your server can replace disconnected peers with new ones.</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>Doesn't allow you to select your server's peers, which means that you have no idea whether your peers may decide to act maliciously. Although `rippled` servers are designed to protect against malicious peers, there is always a risk that malicious peers could exploit software flaws to affect your server.</p></li>
|
||||
<li><p>Your server's peers may disconnect or change frequently.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr><th>Private Server Using Proxies</th>
|
||||
<td><ul>
|
||||
<li><p>Most secure and reliable configuration when implemented effectively.</p></li>
|
||||
<li><p>As reliable and as redundant as you make it.</p></li>
|
||||
<li><p>Can optimize the private server's performance with <a href="clustering.html">clustering</a>.</p></li>
|
||||
<li><p>Enables you to create as many direct peer connections as you want. Your private server can <a href="ledger-history.html#fetching-history">fetch history</a> from multiple peers in parallel. Since you run the peers, you also control how much ledger history each peer keeps.</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>Higher maintenance burden and cost from running multiple servers.</p></li>
|
||||
<li><p>Does not completely eliminate the possibility of peer connection outages. No matter how many proxies you run, if they all exist on the same server rack, then one network or power outage can affect all of them.</p></li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
<tr><th>Private Server Using Public Hubs</th>
|
||||
<td><ul>
|
||||
<li><p>Low maintenance burden with a small amount of configuration.</p></li>
|
||||
<li><p>Provides easy access to safe connections to the network.</p></li>
|
||||
<li><p>Compared to connecting using proxies, may be less likely to cause your private server to disconnect from the network due to a simultaneous peer outage.</p></li>
|
||||
</ul></td>
|
||||
<td><ul>
|
||||
<li><p>Depends on high-reputation third parties to remain reliable.</p></li>
|
||||
<li>
|
||||
<p>May cause your server to become disconnected from the network if the public hubs you rely on are too busy. Due to the nature of public hubs, they are the most popular and may not be able to keep a steady connection open to everyone.</p>
|
||||
<p>To help avoid this issue, use more public hubs; the more the better. It can also help to use non-default hubs, which are less likely to be busy.</p>
|
||||
</li>
|
||||
</ul></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### Configuring a Private Server
|
||||
|
||||
Use the `[peer_private]` stanza of the `rippled` config file to make your server act as a private peer. Use the `[ips_fixed]` to list servers you want your server to connect to. (If you enable `[peer_private]` without any addresses in `[ips_fixed]`, your server does not connect to the network.) As an additional precaution, use a firewall to block incoming connections from other servers.
|
||||
|
||||
Example configuration:
|
||||
|
||||
```
|
||||
# Configuration on a private server that only connects through
|
||||
# a second rippled server at IP address 10.1.10.55
|
||||
[ips_fixed]
|
||||
10.1.10.55
|
||||
|
||||
[peer_private]
|
||||
1
|
||||
```
|
||||
To configure your server as a private server, set the `[peer_private]` setting to `1` in the config file. For detailed instructions, see [Configure a Private Server](configure-a-private-server.html).
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
@@ -25,6 +25,17 @@
|
||||
|
||||
最後に、各自で検証サーバーを運用する場合には、ストックサーバーをパブリックネットワークへのプロキシとして使用し、ストックサーバー経由でのみ外部にアクセス可能なプライベートサブネット上で検証サーバーを維持することができます。これにより、検証サーバーの整合性を危うくすることはさらに難しくなります。
|
||||
|
||||
### 公開ハブ
|
||||
|
||||
**Note:** この部分は日本語ではまだ利用できません。助けたいと思うなら、[提供して下さい！](https://github.com/ripple/xrpl-dev-portal#contributing)
|
||||
|
||||
A public hub is a stock server with lots of [peer protocol connections](peer-protocol.html) to other servers. You can help the XRP Ledger network maintain efficient connectivity by running a stock server as a public hub. Successful public hubs embody the following traits:
|
||||
|
||||
- Good bandwidth.
|
||||
|
||||
- Connections with a lot of reliable peers.
|
||||
|
||||
- Ability to relay messages reliably.
|
||||
|
||||
## バリデータを運用する理由
|
||||
|
||||
|
||||
@@ -0,0 +1,136 @@
|
||||
# peer_reservations_add
|
||||
[[Source]](https://github.com/ripple/rippled/blob/4a1148eb2849513dd1e7ae080288fd47ab57a376/src/ripple/rpc/handlers/Reservations.cpp#L36 "Source")
|
||||
|
||||
The `{{currentpage.name}}` method adds or updates a reserved slot for a specific peer server in the XRP Ledger [peer-to-peer network](peer-protocol.html).
|
||||
|
||||
_The `{{currentpage.name}}` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._
|
||||
|
||||
|
||||
### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "peer_reservations_add_example_1",
|
||||
"command": "{{currentpage.name}}",
|
||||
"public_key": "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99",
|
||||
"description": "Ripple s1 server 'WOOL'"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "{{currentpage.name}}",
|
||||
"params": [{
|
||||
"public_key": "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99",
|
||||
"description": "Ripple s1 server 'WOOL'"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```sh
|
||||
#Syntax: {{currentpage.name}} <public_key> [<description>]
|
||||
rippled {{currentpage.name}} n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99 "Ripple s1 server 'WOOL'"
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The request includes the following parameters:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:--------------|:-------|:----------------------------------------------------|
|
||||
| `public_key` | String | The [node public key][] of the peer reservation to add a reservation for, in [base58][]. |
|
||||
| `description` | String | _(Optional)_ A custom description for the peer reservation. The server truncates descriptions longer than 64 characters when it restarts. |
|
||||
|
||||
|
||||
|
||||
### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "peer_reservations_add_example_1",
|
||||
"result": {
|
||||
"previous": {
|
||||
"description": "Maecenas atavis edite regibus, O et praesidium et dulce decus meum, Sunt quos curriculo pulverem Olympicum Collegisse iuvat metaque fervidis Evitata rotis palmaque nobilis Terrarum dominos evehit ad deos; Hunc, si mobilium turba Quiritium Certat tergeminis tollere honoribus; Illum, si proprio condidit horreo, Quidquid de Libycis verritur areis.",
|
||||
"node": "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
}
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"previous": {
|
||||
"description": "Maecenas atavis edite regibus, O et praesidium et dulce decus meum, Sunt quos curriculo pulverem Olympicum Collegisse iuvat metaque fervidis Evitata rotis palmaque nobilis Terrarum dominos evehit ad deos; Hunc, si mobilium turba Quiritium Certat tergeminis tollere honoribus; Illum, si proprio condidit horreo, Quidquid de Libycis verritur areis.",
|
||||
"node": "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```json
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
|
||||
{
|
||||
"result": {
|
||||
"previous": {
|
||||
"description": "Maecenas atavis edite regibus, O et praesidium et dulce decus meum, Sunt quos curriculo pulverem Olympicum Collegisse iuvat metaque fervidis Evitata rotis palmaque nobilis Terrarum dominos evehit ad deos; Hunc, si mobilium turba Quiritium Certat tergeminis tollere honoribus; Illum, si proprio condidit horreo, Quidquid de Libycis verritur areis.",
|
||||
"node": "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The response follows the [standard format][], with a successful result containing the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:-----------|:-------|:-------------------------------------------------------|
|
||||
| `previous` | Object | _(May be omitted)_ The previous entry for the same [node public key][], if there was already a reservation with the same node public key. This object is formatted as a **Peer Reservation Object**, as described below. |
|
||||
|
||||
If there was not a previous entry for the same [node public key][], the `result` object is empty.
|
||||
|
||||
#### Peer Reservation Object
|
||||
|
||||
If the `previous` field is provided, it shows the previous status of this peer reservation, with the following fields:
|
||||
|
||||
{% include '_snippets/peer_reservation_object.md' %}
|
||||
<!--_ -->
|
||||
|
||||
|
||||
### Possible Errors
|
||||
|
||||
- Any of the [universal error types][].
|
||||
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
|
||||
- `publicMalformed` - The `public_key` field of the request is not valid. It must be a valid node public key in [base58][] format.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,132 @@
|
||||
# peer_reservations_del
|
||||
[[Source]](https://github.com/ripple/rippled/blob/4a1148eb2849513dd1e7ae080288fd47ab57a376/src/ripple/rpc/handlers/Reservations.cpp#L89 "Source")
|
||||
|
||||
The `{{currentpage.name}}` method removes a specific [peer reservation][], if one exists.
|
||||
|
||||
_The `{{currentpage.name}}` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._
|
||||
|
||||
**Note:** Removing a peer reservation does not automatically disconnect the corresponding peer, if that peer is connected.
|
||||
|
||||
### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "peer_reservations_del_example_1",
|
||||
"command": "{{currentpage.name}}",
|
||||
"public_key": "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "{{currentpage.name}}",
|
||||
"params": [{
|
||||
"public_key": "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```sh
|
||||
#Syntax: {{currentpage.name}} <public_key>
|
||||
rippled {{currentpage.name}} n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The request includes the following parameter:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:------------|:--------------------------|:-----------------------------------|
|
||||
| `public_key` | String | The [node public key][] of the [peer reservation][] to remove, in [base58][] format. |
|
||||
|
||||
|
||||
### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "peer_reservations_del_example_1",
|
||||
"result": {
|
||||
"previous": {
|
||||
"description": "Ripple s1 server 'WOOL'",
|
||||
"node": "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
}
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
"result" : {
|
||||
"previous" : {
|
||||
"description" : "Ripple s1 server 'WOOL'",
|
||||
"node" : "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
},
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```json
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
|
||||
{
|
||||
"result" : {
|
||||
"previous" : {
|
||||
"description" : "Ripple s1 server 'WOOL'",
|
||||
"node" : "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
},
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The response follows the [standard format][], with a successful result containing the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:--------|:-------|:----------------------------------------------------------|
|
||||
| `previous` | Object | _(May be omitted)_ A **peer reservation object** with the last state of the peer reservation before deleting it. This field is always provided if a peer reservation was successfully deleted. |
|
||||
|
||||
**Note:** If the specified reservation did not exist, this command returns success with an empty result object. In this case, the `previous` field is omitted.
|
||||
|
||||
#### Peer Reservation Object
|
||||
|
||||
If the `previous` field is provided, it shows the previous status of this peer reservation, with the following fields:
|
||||
|
||||
{% include '_snippets/peer_reservation_object.md' %}
|
||||
<!--_ -->
|
||||
|
||||
### Possible Errors
|
||||
|
||||
- Any of the [universal error types][].
|
||||
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
|
||||
- `publicMalformed` - The `public_key` field of the request is not valid. It must be a valid node public key in [base58][] format.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,134 @@
|
||||
# peer_reservations_list
|
||||
[[Source]](https://github.com/ripple/rippled/blob/4a1148eb2849513dd1e7ae080288fd47ab57a376/src/ripple/rpc/handlers/Reservations.cpp#L116 "Source")
|
||||
|
||||
The `{{currentpage.name}}` method lists [peer reservations][].
|
||||
|
||||
_The `{{currentpage.name}}` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._
|
||||
|
||||
|
||||
### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "peer_reservations_list_example_1",
|
||||
"command": "{{currentpage.name}}"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "{{currentpage.name}}"
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```sh
|
||||
#Syntax: {{currentpage.name}}
|
||||
rippled {{currentpage.name}}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
This request does not take any parameters.
|
||||
|
||||
|
||||
### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "peer_reservations_list_example_1",
|
||||
"result": {
|
||||
"reservations": [
|
||||
{
|
||||
"description": "Ripple s1 server 'WOOL'",
|
||||
"node": "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
},
|
||||
{
|
||||
"node": "n9MZRo92mzYjjsa5XcqnPC7GFYAnENo9VfJzKmpcS9EFZvw5fgwz"
|
||||
}
|
||||
]
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
"result" : {
|
||||
"reservations" : [
|
||||
{
|
||||
"description" : "Ripple s1 server 'WOOL'",
|
||||
"node" : "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
},
|
||||
{
|
||||
"node" : "n9MZRo92mzYjjsa5XcqnPC7GFYAnENo9VfJzKmpcS9EFZvw5fgwz"
|
||||
}
|
||||
],
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```json
|
||||
Loading: "/etc/rippled.cfg"
|
||||
2019-Dec-27 21:56:07.253260422 HTTPClient:NFO Connecting to 127.0.0.1:5005
|
||||
|
||||
{
|
||||
"result" : {
|
||||
"reservations" : [
|
||||
{
|
||||
"description" : "Ripple s1 server 'WOOL'",
|
||||
"node" : "n9Jt8awsPzWLjBCNKVEEDQnw4bQEPjezfcQ4gttD1UzbLT1FoG99"
|
||||
},
|
||||
{
|
||||
"node" : "n9MZRo92mzYjjsa5XcqnPC7GFYAnENo9VfJzKmpcS9EFZvw5fgwz"
|
||||
}
|
||||
],
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The response follows the [standard format][], with a successful result containing the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:---------------|:------|:----------------------------------------------------|
|
||||
| `reservations` | Array | List of existing [peer reservations][]. Each member is a peer reservation object, as described below. |
|
||||
|
||||
#### Peer Reservation Object
|
||||
|
||||
Each member of the `reservations` array is a JSON object describing one [peer reservation][]. This object has the following fields:
|
||||
|
||||
{% include '_snippets/peer_reservation_object.md' %}
|
||||
<!--_ -->
|
||||
|
||||
### Possible Errors
|
||||
|
||||
- Any of the [universal error types][].
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,101 @@
|
||||
# TODO_method_name
|
||||
[[Source]](TODO_URL "Source")
|
||||
|
||||
The `{{currentpage.name}}` method TODO_description.
|
||||
|
||||
_The `{{currentpage.name}}` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._
|
||||
|
||||
|
||||
### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
TODO
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "{{currentpage.name}}",
|
||||
"params": [{
|
||||
TODO
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```sh
|
||||
#Syntax: {{currentpage.name}} TODO
|
||||
rippled {{currentpage.name}}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The request includes the following parameters:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:------------|:--------------------------|:-----------------------------------|
|
||||
TODO_request_params
|
||||
|
||||
|
||||
### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
TODO
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
TODO
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```json
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
|
||||
{
|
||||
TODO
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The response follows the [standard format][], with a successful result containing the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:--------|:-------|:----------------------------------------------------------|
|
||||
TODO_response_params
|
||||
|
||||
|
||||
### Possible Errors
|
||||
|
||||
- Any of the [universal error types][].
|
||||
- TODO_errors
|
||||
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -6,12 +6,12 @@ The XRP Ledger prefixes different types of values with a specific 8-bit number b
|
||||
|
||||
The following table lists all the encodings the XRP Ledger uses:
|
||||
|
||||
| Data Type | Starts With | Type Prefix | Content size¹ | Maximum characters |
|
||||
|:-----------------------------|:------------|:---------------|:--------------|:--|
|
||||
| [Account][] address | r | `0x00` | 20 bytes | 35 |
|
||||
| Account public key | a | `0x23` | 33 bytes | 53 |
|
||||
| Seed value (for secret keys) | s | `0x21` | 16 bytes | 29 |
|
||||
| Validation public key | n | `0x1C` | 33 bytes | 53 |
|
||||
| Data Type | Starts With | Type Prefix | Content size¹ | Maximum characters |
|
||||
|:-----------------------------------------|:------------|:------------|:--------------|:--|
|
||||
| [Account][] address | r | `0x00` | 20 bytes | 35 |
|
||||
| Account public key | a | `0x23` | 33 bytes | 53 |
|
||||
| Seed value (for secret keys) | s | `0x21` | 16 bytes | 29 |
|
||||
| Validation public key or node public key | n | `0x1C` | 33 bytes | 53 |
|
||||
|
||||
¹ Content size excludes the 1-byte type prefix.
|
||||
|
||||
|
||||
@@ -120,34 +120,18 @@ On your validator:
|
||||
|
||||
This section describes three different configurations you can use to connect your validator to the XRP Ledger network. Use the configuration that best suits your use case.
|
||||
|
||||
- [Discovered peers](#connect-using-discovered-peers)
|
||||
- [Discovered peers](#connect-using-discovered-peers): Connect to any servers in the peer-to-peer network.
|
||||
|
||||
- [Proxies](#connect-using-proxies)
|
||||
- [Proxies](#connect-using-proxies): Run stock `rippled` servers as proxies between your validator and the rest of the peer-to-peer network.
|
||||
|
||||
- [Public hubs](#connect-using-public-hubs)
|
||||
- [Public hubs](#connect-using-public-hubs): Connect only to specific public servers with a high reputation.
|
||||
|
||||
For a comparison of these approaches, see [Pros and Cons of Peering Configurations](peer-protocol.html#pros-and-cons-of-peering-configurations).
|
||||
|
||||
|
||||
### Connect using discovered peers
|
||||
|
||||
This configuration connects your validator to the XRP Ledger network using discovered peers. This is the default behavior for `rippled` servers.
|
||||
|
||||
Specifically, it instructs your validator to connect to the [hardcoded public hubs](https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). Once connected, the public hub suggests other servers that might be looking for peers and provides your validator with contact information it can use to connect to them. Your validator can then connect to these servers and ask them for contact information for other servers until your validator has enough reliable peers that you don't have to worry about one or two of them suddenly dropping offline.
|
||||
|
||||
Your validator needs to connect to the public hub once and only for a short amount of time to find other peers. After doing so, your server may or may not remain connected to the hub, depending on how stable your network connection is, how busy the hub is, and how many other high-quality peers your server finds. Your validator saves the addresses of these other peers so it can try reconnecting directly to those peers later, even if you restart your validator.
|
||||
|
||||
**Pros:**
|
||||
|
||||
- Increases the chances of your validator finding a peer, probably several, to connect to.
|
||||
|
||||
- Creates the opportunity for a lot of direct peer connections. Having more direct peers comes with several benefits. Your validator can [fetch history](ledger-history.html#fetching-history) from multiple peers in parallel, both when syncing and when backfilling history. Since not all peers maintain full history, having access to more peers can also provide access to a wider selection of historical data.
|
||||
|
||||
- Lowers the possibility of your validator disconnecting from the network because it provides the ability to constantly replace disconnected peers with new ones.
|
||||
|
||||
**Cons:**
|
||||
|
||||
- Doesn't allow you to select your validator's peers, which means that you have no idea whether your peers may decide to act maliciously. Your validator is designed to protect itself against malicious peers, but avoiding direct contact with unknown peers is the safest configuration possible.
|
||||
|
||||
- May connect you to peers that disconnect and change frequently, depending on whether you manage to connect to any reliable ones.
|
||||
This configuration connects your validator to the XRP Ledger network using [discovered peers](peer-protocol.html#peer-discovery). This is the default behavior for `rippled` servers.
|
||||
|
||||
_**To connect your validator to the XRP Ledger network using discovered peers,**_ omit the `[peer_private]` stanza or set it to `0` in your validator's `rippled.cfg` file. The [example rippled.cfg file](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg) is delivered with this configuration.
|
||||
|
||||
@@ -156,24 +140,6 @@ _**To connect your validator to the XRP Ledger network using discovered peers,**
|
||||
|
||||
This configuration connects your validator to the network through stock `rippled` servers that you run yourself. These proxy servers sit between your validator and inbound and outbound network traffic.
|
||||
|
||||
**Note:** While these servers are acting as proxies, they are not web proxies for HTTP(S) traffic.
|
||||
|
||||
**Pros:**
|
||||
|
||||
- Guarantees that these servers will try to maintain a connection with your validator.
|
||||
|
||||
- Provides your validator with connections to the network that are as redundant and reliable as you make them.
|
||||
|
||||
- Enables you to trust your validator's peers.
|
||||
|
||||
- Enables you to create as many direct peer connections as you want. Being able to request content from more peers enables your validator to parallelize the process of downloading the current ledger (when syncing) or backfilling history and gives it direct access to a wider selection of history.
|
||||
|
||||
**Cons:**
|
||||
|
||||
- While it does allow for high redundancy, doesn't eliminate the possibility of peer connection outages. No matter how many proxies you run, if they all exist on the same server rack, then one network or power outage means they can't deliver messages to and from your validator.
|
||||
|
||||
To mitigate this risk, you can use proxies in different geophysical locations.
|
||||
|
||||
_**To connect your validator to the XRP Ledger network using proxies:**_
|
||||
|
||||
1. Set up stock `rippled` servers. For more information, see [Install rippled](install-rippled.html).
|
||||
@@ -205,20 +171,6 @@ _**To connect your validator to the XRP Ledger network using proxies:**_
|
||||
|
||||
This configuration connects your validator to the network using two [public hubs](rippled-server-modes.html#public-hubs). This configuration is similar to [connecting using proxies you run yourself](#connect-using-proxies), but instead you connect through public hubs.
|
||||
|
||||
**Pros:**
|
||||
|
||||
- Enables you to trust your validator's peers because you only connect to well-known servers with a high reputation.
|
||||
|
||||
- Provides easy access to safe connections to the network.
|
||||
|
||||
- Compared to [connecting using proxies](#connect-using-proxies), may be less likely to cause your validator to disconnect from the network due to a simultaneous peer outage.
|
||||
|
||||
**Cons:**
|
||||
|
||||
- Uses the default (most popular) public hubs, so it's distinctly possible that a public hub may be too busy to provide your validator with a connection to the network. Assuming that you can solely rely on a default public hub to provide your validator with a connection to the network may not be the best idea.
|
||||
|
||||
To help avoid this issue, use more public hubs; the more the better. It can also help to use non-default hubs, which are less likely to be busy helping new servers find other peers.
|
||||
|
||||
_**To connect your validator to the network using public hubs:**_
|
||||
|
||||
1. In your validator's `rippled.cfg` file, include the following `[ips_fixed]` stanza. The two values, `r.ripple.com 51235` and `zaphod.alloy.ee 51235`, are default public hubs. This stanza tells `rippled` to always attempt to maintain peer connections with these public hubs.
|
||||
|
||||
@@ -0,0 +1,90 @@
|
||||
# Configure a Private Server
|
||||
|
||||
A [private server](peer-protocol.html#private-peers) is a `rippled` server that connects to the network only through specific, trusted peers instead of connecting directly to discovered peers in the open peer-to-peer network. This kind of configuration is an optional precaution most commonly recommended for [validators](run-rippled-as-a-validator.html), but it can be useful for other specific purposes.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To use a private server, you must meet the following requirements:
|
||||
|
||||
- You must have [`rippled` installed](install-rippled.html) and updated to the latest version, but not running yet.
|
||||
- You must decide whether to connect through **proxies** you run yourself, or through **public hubs**. For a comparison of these options, see [Pros and Cons of Peering Configurations](peer-protocol.html#pros-and-cons-of-peering-configurations).
|
||||
- If you are using proxies, you must have additional machines with `rippled` installed and running to use as the proxies. These servers must be able to connect to the outside network and to your private server.
|
||||
- For either configuration, you must know the IP addresses and ports of the peers you intend to connect to.
|
||||
|
||||
## Steps
|
||||
|
||||
To set up a specific server as a private peer, complete the following steps:
|
||||
|
||||
1. Edit your `rippled`'s config file.
|
||||
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
2. Enable private peering.
|
||||
|
||||
Add or uncomment the following stanza in your config file:
|
||||
|
||||
[peer_private]
|
||||
1
|
||||
|
||||
3. Add fixed peers.
|
||||
|
||||
Add or uncomment an `[ips_fixed]` stanza in your config file. Each line in this stanza should be the hostname or IP address of a peer to connect to, followed by a space and the port where this peer accepts peer protocol connections.
|
||||
|
||||
For example, to connect using **public hubs**, you could use the following stanza:
|
||||
|
||||
[ips_fixed]
|
||||
r.ripple.com 51235
|
||||
zaphod.alloy.ee 51235
|
||||
|
||||
If your server connects using **proxies**, the IP addresses and ports should match the configurations of the `rippled` servers you are using as proxies. For each of those servers, the port number should match the `protocol = peer` port in that server's config file (usually 51235). For example, your configuration might look like this:
|
||||
|
||||
[ips_fixed]
|
||||
192.168.0.1 51235
|
||||
192.168.0.2 51235
|
||||
|
||||
4. If using proxies, cluster them with your private peer and each other.
|
||||
|
||||
If you are using public hubs, skip this step.
|
||||
|
||||
If you are using proxies, [configure the proxies as a cluster](cluster-rippled-servers.html) that includes your private peer. Each member of the cluster should have an `[ips_fixed]` stanza that lists each _other_ member of the cluster. However, **only the private server** should have a `[peer_private]` stanza.
|
||||
|
||||
Restart `rippled` on the proxies one-by-one. On each proxy server:
|
||||
|
||||
sudo service systemctl restart rippled
|
||||
|
||||
5. Start `rippled` on the private server.
|
||||
|
||||
sudo service systemctl start rippled
|
||||
|
||||
6. Use the [peers method][] to confirm that your private server is connected _only_ to its peers.
|
||||
|
||||
The `peers` array in the response should not contain any objects whose `address` is not one of your configured peers. If this is not the case, double-check your config file and restart the private server.
|
||||
|
||||
|
||||
## Next Steps
|
||||
|
||||
As an additional precaution, you should configure your firewall to block incoming connections to your private server from servers that are not your specific peers. If you are running proxy servers, [forward peer ports](forward-ports-for-peering.html) through your firewall to the proxies, but **not** to the private peer. The exact details of how to configure this depend on what firewall you use.
|
||||
|
||||
Be sure the firewall **does not block** outgoing HTTP connections on port 80. The default configuration uses this port to download the latest recommended validator list from **vl.ripple.com**. Without a validator list, the server does not know which validators to trust and cannot recognize when the network reaches a consensus.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Peer Protocol](peer-protocol.html)
|
||||
- [Consensus](consensus.html)
|
||||
- [Parallel Networks](parallel-networks.html)
|
||||
- **Tutorials:**
|
||||
- [Configure the Peer Crawler](configure-the-peer-crawler.html)
|
||||
- **References:**
|
||||
- [peers method][]
|
||||
- [connect method][]
|
||||
- [fetch_info method][]
|
||||
- [Peer Crawler](peer-crawler.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,5 @@
|
||||
# Configure Peering
|
||||
|
||||
The XRP Ledger's peer-to-peer protocol automatically manages peer connections in most cases. In some cases, you may want to manually adjust which peers your server connects to, to maximize your server's availability and connectivity with the rest of the network.
|
||||
|
||||
If you run multiple servers in the same datacenter, you may want [to cluster them](cluster-rippled-servers.html) to improve efficiency. You can use reserved peer slots for servers you don't run but want to stay connected to, such as important hubs in the topology of the peer-to-peer network. For other peers, the server can automatically find peers and manage its connections, although you may occasionally want to intervene to block a peer that's behaving undesirably.
|
||||
@@ -0,0 +1,59 @@
|
||||
# Forward Ports for Peering
|
||||
|
||||
Servers in the XRP Ledger peer-to-peer network communicate over the [peer protocol](peer-protocol.html). For the best combination of security and connectivity to the rest of the network, you should use a firewall to protect your server from most ports, but open or forward the peer protocol port.
|
||||
|
||||
While your `rippled` server is running, you can check to see how many peers you have by running the [server_info method][]. The `peers` field of the `info` object shows how many peers are currently connected to your server. If this number is exactly 10 or 11, that usually means your firewall is blocking incoming connections.
|
||||
|
||||
Example of a `server_info` result (trimmed) showing only 10 peers, likely because a firewall is blocking incoming peer connections:
|
||||
|
||||
```json
|
||||
$ ./rippled server_info
|
||||
Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
2019-Dec-23 22:15:09.343961928 HTTPClient:NFO Connecting to 127.0.0.1:5005
|
||||
|
||||
{
|
||||
"result" : {
|
||||
"info" : {
|
||||
... (trimmed) ...
|
||||
"load_factor" : 1,
|
||||
"peer_disconnects" : "0",
|
||||
"peer_disconnects_resources" : "0",
|
||||
"peers" : 10,
|
||||
"pubkey_node" : "n9KUjqxCr5FKThSNXdzb7oqN8rYwScB2dUnNqxQxbEA17JkaWy5x",
|
||||
"pubkey_validator" : "n9KM73uq5BM3Fc6cxG3k5TruvbLc8Ffq17JZBmWC4uP4csL4rFST",
|
||||
"published_ledger" : "none",
|
||||
"server_state" : "connected",
|
||||
... (trimmed) ...
|
||||
},
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
To allow incoming connections, configure your firewall to forward the peer protocol port, which is served on **port 51235** in the default config file. The instructions to forward a port depend on your firewall. For example, if you use the `firewalld` software firewall on Red Hat Enterprise Linux, you can [use the `firewall-cmd` tool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-port_forwarding) to forward TCP traffic as follows:
|
||||
|
||||
```sh
|
||||
$ sudo firewall-cmd --add-forward-port=port=51235:proto=tcp:toport=51235
|
||||
```
|
||||
|
||||
For other software and hardware firewalls, see the manufacturer's official documentation.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Peer Protocol](peer-protocol.html)
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- **Tutorials:**
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [connect method][]
|
||||
- [peers method][]
|
||||
- [print method][]
|
||||
- [server_info method][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,72 @@
|
||||
# Manually Connect to a Specific Peer
|
||||
|
||||
Use these steps to manually connect your server to a specific [peer](peer-protocol.html) in the XRP Ledger network.
|
||||
|
||||
**Tip:** If you want to make sure your server automatically connects to this server on startup and remains connected later, you may want to configure a [peer reservation](use-a-peer-reservation.html) for that peer.
|
||||
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- You must know the IP address of the peer you want to connect to.
|
||||
- You must know what port the peer you want to connect to uses for the XRP Ledger [peer protocol](peer-protocol.html). By default, this is port 51235.
|
||||
- You must have a network connection from your server to the peer. For example, the peer server must [forward the apppropriate port through its firewall](forward-ports-for-peering.html).
|
||||
- The peer server must have available peer slots. If the peer is already at its maximum number of peers, you can ask the peer server's operator to add a [peer reservation](use-a-peer-reservation.html) for your server.
|
||||
|
||||
## Steps
|
||||
|
||||
To connect, use the [connect method][]. For example:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command": "connect",
|
||||
"ip": "169.54.2.151",
|
||||
"port": 51235
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "connect",
|
||||
"params": [
|
||||
{
|
||||
"ip": "169.54.2.151",
|
||||
"port": 51235
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
rippled connect 169.54.2.151 51235
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Peer Protocol](peer-protocol.html)
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- **Tutorials:**
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [connect method][]
|
||||
- [peers method][]
|
||||
- [print method][]
|
||||
- [server_info method][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,48 @@
|
||||
# Set Maximum Number of Peers
|
||||
|
||||
The `rippled` server has a configurable soft maximum number of [peers](peer-protocol.html) to connect to. The default maximum number of peers is **21**.
|
||||
|
||||
**Note:** Internally, the server generates approximate quotas of incoming and outgoing peers. You can potentially go over the soft maximum if you are using [fixed peers, peer reservations](peer-protocol.html#fixed-peers-and-peer-reservations), or if you manually connect to additional peers using the [connect method][].
|
||||
|
||||
To change the maximum number of peers your server allows, complete the following steps:
|
||||
|
||||
1. Edit your `rippled`'s config file.
|
||||
|
||||
$ vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
2. In the config file, uncomment and edit the `[peers_max]` stanza, or add one if you don't have one already:
|
||||
|
||||
[peers_max]
|
||||
30
|
||||
|
||||
The only content of the stanza should be an integer indicating the total number of peers to allow. By default, the server attempts to maintain a ratio of about 85% incoming and 15% outgoing peers, but with a minimum of 10 outgoing peers, so any value less than 68 won't increase the number of outgoing peer connections your server makes.
|
||||
|
||||
If the `[peers_max]` value is less than 10, the server still allows a hardcoded minimum of 10 outgoing peers so that it can maintain connectivity with the network. To block all outgoing peer connections, [configure the server as a private peer](run-rippled-as-a-validator.html#connect-using-proxies) instead.
|
||||
|
||||
**Caution:** The more peer servers you are connected to, the more network bandwidth your `rippled` server uses. You should only configure large numbers of peer servers if your `rippled` server has a good network connection and you can afford the costs you may incur for the bandwidth it uses.
|
||||
|
||||
3. Restart the `rippled` server.
|
||||
|
||||
$ sudo systemctl restart rippled.service
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Peer Protocol](peer-protocol.html)
|
||||
- [The `rippled` Server](the-rippled-server.html)
|
||||
- **Tutorials:**
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [connect method][]
|
||||
- [peers method][]
|
||||
- [print method][]
|
||||
- [server_info method][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,178 @@
|
||||
# Use a Peer Reservation
|
||||
|
||||
A [peer reservation][] is a setting that makes a `rippled` server always accept connections from a peer matching the reservation. This page describes how to use peer reservations to keep a consistent peer-to-peer connection between two servers, with the cooperation of the administrators of both servers.
|
||||
|
||||
Peer reservations are most useful when the two servers are run by different parties, and the server that receives the incoming connection is a [hub server](rippled-server-modes.html#public-hubs) with many peers. For clarity, these instructions use the following terms:
|
||||
|
||||
- The server making the outgoing connection is the **stock server**. This server _uses_ the peer reservation on the hub server.
|
||||
- The server receiving the incoming connection is the **hub server**. The administrator _adds_ the peer reservation to this server.
|
||||
|
||||
However, you can use these instructions to set up a peer reservation regardless of whether one server or both are hubs, validators, or stock servers. It is also possible to use a peer reservation when the busier server is the one making the outgoing connection, but this process does not describe that configuration.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To complete these steps, you must meet the following prerequisites:
|
||||
|
||||
- The administrators both servers must have `rippled` [installed](install-rippled.html) and running.
|
||||
- The administrators of both servers must agree to cooperate and must be able to communicate. A public communications channel is fine because you don't need to share any secret information.
|
||||
- The hub server must be able to receive incoming peer connections. For instructions on how to configure a firewall to allow this, see [Forward Ports for Peering](forward-ports-for-peering.html).
|
||||
- Both servers must be configured to sync with the same [XRP Ledger network](parallel-networks.html), such as the production XRP Ledger, the Testnet, or the Devnet.
|
||||
|
||||
## Steps
|
||||
|
||||
To use a peer reservation, complete the following steps:
|
||||
|
||||
### 1. (Stock Server) Set up a permanent node key pair
|
||||
|
||||
The administrator of the stock server completes this step.
|
||||
|
||||
If you have already configured your server with a permanent node key pair value, you can skip ahead to [step 2: Communicate your node public key to the peer's admin](#2-communicate-the-stock-servers-node-public-key). (For example, setting up a permanent node key pair for each server is part of the process of [setting up a server cluster](cluster-rippled-servers.html).)
|
||||
|
||||
**Tip:** Setting up a permanent node key pair is optional, but makes it easier to keep the peer reservation set up if you need to erase your server's databases or move to a new machine. If you don't want to set up a permanent node key pair, you can use your server's automatically-generated node public key as reported in the `pubkey_node` field of the [server_info method][] response.
|
||||
|
||||
1. Generate a new, random key pair using the [validation_create method][]. (Omit the `secret` value.)
|
||||
|
||||
For example:
|
||||
|
||||
rippled validation_create
|
||||
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"status" : "success",
|
||||
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
|
||||
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
|
||||
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
|
||||
}
|
||||
}
|
||||
|
||||
Save the `validation_seed` (your node seed value) and the `validation_public_key` value (your node public key )
|
||||
|
||||
2. Edit your `rippled`'s config file.
|
||||
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
3. Add a `[node_seed]` stanza using the `validation_seed` value you generated earlier.
|
||||
|
||||
For example:
|
||||
|
||||
[node_seed]
|
||||
ssZkdwURFMBXenJPbrpE14b6noJSu
|
||||
|
||||
**Warning:** All servers should have unique `[node_seed]` values. If you copy your config file to another server, be sure to remove or change the `[node_seed]` value. Keep your `[node_seed]` secret; if a malicious actor gains access to this value, they could use it to impersonate your server in XRP Ledger peer-to-peer communications.
|
||||
|
||||
4. Restart your `rippled` server:
|
||||
|
||||
systemctl restart rippled
|
||||
|
||||
### 2. Communicate the stock server's node public key
|
||||
|
||||
The administrator of the stock server tells the administrator of the hub server what the stock server's node public key is. (Use the `validation_public_key` from step 1.) The administrator of the hub server needs this value for the next steps.
|
||||
|
||||
### 3. (Hub Server) Add the peer reservation
|
||||
|
||||
The administrator of the hub server completes this step.
|
||||
|
||||
Use the [peer_reservations_add method][] to add a reservation using the node public key that you got in the previous step. For example:
|
||||
|
||||
```sh
|
||||
$ rippled peer_reservations_add n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG "Description here"
|
||||
|
||||
Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
|
||||
{
|
||||
"result": {
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Tip:** The description is an optional field that you can provide to add a human-readable note about who this reservation is for.
|
||||
|
||||
### 4. Communicate the hub server's current IP address and peer port
|
||||
|
||||
The administrator of the hub server must tell their server's current IP address and peer port to the administrator of the stock server. If the hub server is behind a firewall that does network address translation (NAT), use the server's _external_ IP address. The default config file uses port 51235 for the peer protocol.
|
||||
|
||||
### 5. (Stock Server) Connect to the peer server
|
||||
|
||||
The administrator of the stock server completes this step.
|
||||
|
||||
Use the [connect method][] to connect your server to the hub server. For example:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command": "connect",
|
||||
"ip": "169.54.2.151",
|
||||
"port": 51235
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "connect",
|
||||
"params": [
|
||||
{
|
||||
"ip": "169.54.2.151",
|
||||
"port": 51235
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
*Commandline*
|
||||
|
||||
```
|
||||
rippled connect 169.54.2.151 51235
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
If the hub server's administrator has set up the peer reservation as described in the previous steps, this should automatically connect and remain connected as long as possible.
|
||||
|
||||
|
||||
## Next Steps
|
||||
|
||||
As a server administrator, you can manage the reservations your server has for other peers. (It is not possible to check which other servers have reservations for yours.) You can:
|
||||
|
||||
- Add more peer reservations or update their descriptions, using the [peer_reservations_add method][].
|
||||
- Check which servers you have configured reservations for, using the [peer_reservations_list method][].
|
||||
- Remove one of your reservations using the [peer_reservations_del method][].
|
||||
- Check which peers are currently connected and how much bandwidth they have used, using the [peers method][].
|
||||
|
||||
**Tip:** Although there is no API method to immediately disconnect from an unwanted peer, you can use a software firewall such as `firewalld` to block an unwanted peer from connecting to your server. For examples, see the community-contributed [rbh script](https://github.com/gnanderson/rbh).
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Peer Protocol](peer-protocol.html)
|
||||
- [Consensus](consensus.html)
|
||||
- [Parallel Networks](parallel-networks.html)
|
||||
- **Tutorials:**
|
||||
- [Capacity Planning](capacity-planning.html)
|
||||
- [Troubleshooting `rippled`](troubleshoot-the-rippled-server.html)
|
||||
- **References:**
|
||||
- [peers method][]
|
||||
- [peer_reservations_add method][]
|
||||
- [peer_reservations_del method][]
|
||||
- [peer_reservations_list method][]
|
||||
- [connect method][]
|
||||
- [fetch_info method][]
|
||||
- [Peer Crawler](peer-crawler.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -272,6 +272,10 @@ targets:
|
||||
"use-payment-channels.html#9-when-the-payer-and-payee-are-done-doing-business-the-payer-requests-for-the-channel-to-be-closed": "use-payment-channels.html#9-支払人と受取人の取引完了後支払人はchannelの閉鎖を要求します"
|
||||
# Fix 1 link from untranslated accountdelete.html. REMOVE when accounts.html is updated w/ deletable accounts info.
|
||||
"accounts.html#deletion-of-accounts": "accounts.html#アカウントの永続性"
|
||||
# Fix links from untranslated peer protocol updates
|
||||
"peer-protocol.html#node-key-pair": "peer-protocol.html#ノードキーペア"
|
||||
"run-rippled-as-a-validator.html#connect-using-proxies": "run-rippled-as-a-validator.html#プロキシを使用した接続"
|
||||
"rippled-server-modes.html#public-hubs": "rippled-server-modes.html#公開ハブ"
|
||||
|
||||
|
||||
- name: xrp-api-only
|
||||
@@ -2381,26 +2385,6 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/cluster-rippled-servers.md
|
||||
html: cluster-rippled-servers.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configuration
|
||||
blurb: Set up a group of servers that share work for higher efficiency.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/cluster-rippled-servers.ja.md
|
||||
html: cluster-rippled-servers.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configuration
|
||||
blurb: Set up a group of servers that share work for higher efficiency. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-online-deletion.md
|
||||
html: configure-online-deletion.html
|
||||
funnel: Docs
|
||||
@@ -2481,17 +2465,6 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-the-peer-crawler.md
|
||||
html: configure-the-peer-crawler.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configuration
|
||||
blurb: Configure how much information your server reports publicly about its status and peers. #TODO:translate
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/enable-public-signing.md
|
||||
html: enable-public-signing.html
|
||||
funnel: Docs
|
||||
@@ -2512,6 +2485,104 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configure-peering/configure-peering.md
|
||||
html: configure-peering.html
|
||||
template: template-landing-children.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configure Peering #TODO:translate
|
||||
blurb: Configure how your server connects to the peer-to-peer network. #TODO:translate
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configure-peering/cluster-rippled-servers.md
|
||||
html: cluster-rippled-servers.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configure Peering
|
||||
blurb: Set up a group of servers that share work for higher efficiency.
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configure-peering/cluster-rippled-servers.ja.md
|
||||
html: cluster-rippled-servers.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configure Peering
|
||||
blurb: Set up a group of servers that share work for higher efficiency. #TODO:translate
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configure-peering/configure-a-private-server.md
|
||||
html: configure-a-private-server.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configure Peering #TODO:translate
|
||||
blurb: Set up a server to connect only to specific, trusted peers. #TODO:translate
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configure-peering/configure-the-peer-crawler.md
|
||||
html: configure-the-peer-crawler.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configure Peering
|
||||
blurb: Configure how much information your rippled server reports publicly about its status and peers. #TODO:translate
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configure-peering/forward-ports-for-peering.md
|
||||
html: forward-ports-for-peering.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configure Peering
|
||||
blurb: Configure your firewall to allow incoming peers to your rippled server. #TODO:translate
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configure-peering/manually-connect-to-a-specific-peer.md
|
||||
html: manually-connect-to-a-specific-peer.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configure Peering
|
||||
blurb: Connect your rippled server to a specific peer. #TODO:translate
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configure-peering/set-max-number-of-peers.md
|
||||
html: set-max-number-of-peers.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configure Peering
|
||||
blurb: Set the maximum number of peers your rippled server connects to. #TODO:translate
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.md
|
||||
html: use-a-peer-reservation.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
subcategory: Configure Peering
|
||||
blurb: Set up a more reliable connection to a specific peer using a peer reservation. #TODO:translate
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- name: Test rippled Functionality in Stand-Alone Mode
|
||||
html: use-stand-alone-mode.html
|
||||
funnel: Docs
|
||||
@@ -4107,28 +4178,6 @@ pages:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/server-control-methods/connect.md
|
||||
html: connect.html
|
||||
blurb: Force the rippled server to connect to a specific peer.
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Server Control Methods
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/server-control-methods/connect.ja.md
|
||||
html: connect.html
|
||||
blurb: 特定のピアrippledサーバーに強制的に接続します。
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Server Control Methods
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/server-control-methods/ledger_accept.md
|
||||
html: ledger_accept.html
|
||||
blurb: Close and advance the ledger in stand-alone mode.
|
||||
@@ -4195,6 +4244,100 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
|
||||
- name: Peer Management Methods
|
||||
html: peer-management-methods.html
|
||||
blurb: Use these methods to manage your server's peer-to-peer connections. #TODO:translate
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Peer Management Methods
|
||||
template: template-landing-children.html
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/peer-management-methods/connect.md
|
||||
html: connect.html
|
||||
blurb: Force the rippled server to connect to a specific peer.
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Peer Management Methods
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/peer-management-methods/connect.ja.md
|
||||
html: connect.html
|
||||
blurb: 特定のピアrippledサーバーに強制的に接続します。
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Peer Management Methods
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/peer-management-methods/peer_reservations_add.md
|
||||
html: peer_reservations_add.html
|
||||
blurb: Add a reserved slot for a specific peer server. #TODO:translate
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Peer Management Methods
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/peer-management-methods/peer_reservations_del.md
|
||||
html: peer_reservations_del.html
|
||||
blurb: Remove a reserved slot for a specific peer server. #TODO:translate
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Peer Management Methods
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/peer-management-methods/peer_reservations_list.md
|
||||
html: peer_reservations_list.html
|
||||
blurb: List reserved slots for specific peer servers. #TODO:translate
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Peer Management Methods
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/peer-management-methods/peers.md
|
||||
html: peers.html
|
||||
blurb: Get information about the peer servers connected.
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Peer Management Methods
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/peer-management-methods/peers.ja.md
|
||||
html: peers.html
|
||||
blurb: ピアプロトコルでこのサーバーに現在接続されているその他のすべてのrippledサーバーのリストを返します。
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Peer Management Methods
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- name: Status and Debugging Methods
|
||||
html: status-and-debugging-methods.html
|
||||
blurb: Use these methods to check the status of the network and server. #TODO:translate
|
||||
@@ -4296,28 +4439,6 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/status-and-debugging-methods/peers.md
|
||||
html: peers.html
|
||||
blurb: Get information about the peer servers connected.
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Status and Debugging Methods
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/status-and-debugging-methods/peers.ja.md
|
||||
html: peers.html
|
||||
blurb: ピアプロトコルでこのサーバーに現在接続されているその他のすべてのrippledサーバーのリストを返します。
|
||||
funnel: Docs
|
||||
doc_type: References
|
||||
supercategory: rippled API
|
||||
category: Admin rippled Methods
|
||||
subcategory: Status and Debugging Methods
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/status-and-debugging-methods/print.md
|
||||
html: print.html
|
||||
blurb: Get information about internal subsystems.
|
||||
|
||||
Reference in New Issue
Block a user