ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-21 04:05:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #527 from mDuo13/peer_crawler_options

Browse Source 
Peer Protocol, Peer Crawler documentation updates
This commit is contained in:
Rome Reginelli
2019-03-11 14:39:51 -07:00
committed by GitHub
parent 215e8c7d2a a3b71bff7c
commit 441dc8af9a
10 changed files with 385 additions and 143 deletions
Download Patch File Download Diff File Expand all files Collapse all files

176
content/_code-samples/peer-crawler/crawl.json Normal file
View File

@@ -0,0 +1,176 @@
{
"overlay": {
"active": [
{
"complete_ledgers": "45498918-45500918",
"ip": "88.99.137.170",
"port": "51235",
"public_key": "AkU+AY9FWh8AXMc43fAUM69SzfAMGat0d/N+qx3kD6Dg",
"type": "out",
"uptime": 208,
"version": "rippled-1.2.1"
},
{
"complete_ledgers": "45500790-45500918",
"ip": "198.13.58.221",
"port": "51235",
"public_key": "AlQvJAlNDYtoBSaZCXM0pT5RWvdOW9QhMW5++mHswkej",
"type": "out",
"uptime": 208,
"version": "rippled-1.2.0"
},
{
"complete_ledgers": "45500662-45500918",
"ip": "52.90.101.104",
"port": "51235",
"public_key": "AkA04ujnwMn8mRyfJg4K7vzcQSOG7FHq4wUg60OQWnCY",
"type": "out",
"uptime": 209,
"version": "rippled-1.2.1"
},
{
"complete_ledgers": "45500662-45500918",
"ip": "54.202.12.93",
"port": "51235",
"public_key": "AxoekFvFYzELGty9cqiXZB+NsOWTZ0Qs9mFIw69CGb3d",
"type": "out",
"uptime": 209,
"version": "rippled-1.2.1"
},
{
"complete_ledgers": "45498918-45500918",
"ip": "173.255.240.113",
"port": "51235",
"public_key": "A4lWBMIDEQrO8Eerp9Hj3rFacbV0FiID3wTIx8Aoplq2",
"type": "out",
"uptime": 209,
"version": "rippled-1.1.0"
},
{
"complete_ledgers": "45499894-45500918",
"ip": "54.186.73.52",
"port": "51235",
"public_key": "AjikFnq0P2XybCyREr2KPiqXqJteqwPwVRVbVK+93+3o",
"type": "out",
"uptime": 209,
"version": "rippled-1.2.1"
},
{
"complete_ledgers": "45499894-45500918",
"ip": "54.186.248.91",
"port": "51235",
"public_key": "A4A4TPA17KlUjstp7fcL0qaWd4X+fvZ5MTxG5P5AggHW",
"type": "out",
"uptime": 209,
"version": "rippled-1.2.1"
},
{
"complete_ledgers": "45490918-45500918",
"ip": "162.243.114.118",
"port": "51235",
"public_key": "AufDkW4E1DOxjzRPj46Eu+AyJdsakUeJTz3xklv1kCfp",
"type": "out",
"uptime": 209,
"version": "rippled-1.2.1"
},
{
"complete_ledgers": "45498918-45500918",
"ip": "::ffff:45.56.78.201",
"port": "51235",
"public_key": "AmsXz4UUqjlz6iy8HHhZdHmBHteEBwYZLOHCHA4puCwj",
"type": "out",
"uptime": 209,
"version": "rippled-1.1.0"
},
{
"complete_ledgers": "32570-45500918",
"ip": "169.55.164.30",
"port": "51235",
"public_key": "Aw7J0CVhFKt0h6PDEpqu6t4LbPY0PsX8jCFbvSQFDOkW",
"type": "out",
"uptime": 209,
"version": "rippled-1.2.1"
}
]
},
"server": {
"build_version": "1.2.1",
"complete_ledgers": "45500881-45500888",
"io_latency_ms": 1,
"jq_trans_overflow": "0",
"last_close": {
"converge_time": 3002,
"proposers": 25
},
"load_base": 256,
"load_factor": 256,
"load_factor_fee_reference": 256,
"load_factor_server": 256,
"peer_disconnects": "0",
"peer_disconnects_resources": "0",
"peers": 10,
"pubkey_node": "n9MJZBu5HyxyEq8xPGBxXFTfT3uzdnNsvR6R1NyXxbEzt79SrZJE",
"published_ledger": 45500888,
"server_state": "full",
"server_state_duration_us": "40756665",
"state_accounting": {
"connected": {
"duration_us": "163459544",
"transitions": 1
},
"disconnected": {
"duration_us": "2539592",
"transitions": 1
},
"full": {
"duration_us": "40756665",
"transitions": 1
},
"syncing": {
"duration_us": "5071794",
"transitions": 1
},
"tracking": {
"duration_us": "1",
"transitions": 1
}
},
"time": "2019-Mar-02 01:48:50.912360",
"uptime": 213,
"validated_ledger": {
"close_time": 604806530,
"hash": "00415B0ECF1D31E8DC9A7DCB04CAF1FD47E61D4D9D047743C1508CDBD36576CE",
"reserve_base": 20000000,
"reserve_inc": 5000000,
"seq": 45500918
}
},
"unl": {
"local_static_keys": [],
"publisher_lists": [
{
"available": true,
"expiration": "2019-Mar-06 00:00:00.000000000",
"pubkey_publisher": "ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734",
"seq": 47,
"uri": "https://vl.ripple.com",
"version": 1
}
],
"validator_list": {
"count": 1,
"expiration": "2019-Mar-06 00:00:00.000000000",
"status": "active"
},
"validator_sites": [
{
"last_refresh_status": "accepted",
"last_refresh_time": "2019-Mar-02 01:45:19.940242379",
"next_refresh_time": "2019-Mar-02 01:50:19.568004480",
"refresh_interval_min": 5,
"uri": "https://vl.ripple.com"
}
]
},
"version": 2
}

174
content/concepts/the-rippled-server/peer-protocol.md
View File

@@ -1,10 +1,19 @@
# Peer Protocol
Servers in the XRP Ledger communicate to each other using the XRP Ledger peer protocol, also known as RTXP. Peer servers connect via HTTPS and then do 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).)
Servers in the XRP Ledger communicate to each other using the XRP Ledger peer protocol, also known as RTXP.
## Configuring the Peer Protocol
The peer protocol is the main mode of communication between servers in the XRP Ledger. All information about the behavior, progress, and connectivity of the XRP Ledger passes through the peer protocol. Examples of peer-to-peer communications include all of the following:
To participate in the XRP Ledger, `rippled` servers connects to arbitrary peers using the peer protocol. (All such peers are treated as untrusted, unless they are [clustered](clustering.html) with the current server.)
- Requesting a connection to other servers in the peer-to-peer network, or advertising that connection slots are available.
- Sharing candidate transactions with the rest of the network.
- Requesting ledger data from historical ledgers, or providing that data.
- Proposing a set of transactions for consensus, or sharing the calculated outcome of applying a consensus transaction set.
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 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` configuration 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.
@@ -17,152 +26,35 @@ ip = 0.0.0.0
protocol = peer
```
## Peer Crawler
The peer protocol port also serves the [special Peer Crawler API method](peer-crawler.html).
The Peer Crawler asks a `rippled` server to report information about the other `rippled` servers it is connected to as peers. The [`peers` command](peers.html) in the [WebSocket and JSON-RPC APIs](get-started-with-the-rippled-api.html) also returns a similar, more comprehensive set of information, but requires [administrative access](admin-rippled-methods.html) to the server. The Peer Crawler response is available to other servers on a non-privileged basis through the Peer Protocol (RTXP) port.
### Node Key Pair
#### Request Format
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.
To request the Peer Crawler information, make the following HTTP request:
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][].
* **Protocol:** https
* **HTTP Method:** GET
* **Host:** (any `rippled` server, by hostname or IP address)
* **Port:** (port number where the `rippled` server uses the Peer Protocol, typically 51235)
* **Path:** `/crawl`
* **Notes:** Most `rippled` servers use a self-signed certificate to respond to the request. By default, most tools (including web browsers) flag or block such responses for being untrusted. You must ignore the certificate checking (for example, if using cURL, add the `--insecure` flag) to display a response from those servers.
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).
#### Response Format
The response has the status code **200 OK** and a JSON object in the message body.
The JSON object has the following fields:
| `Field` | Value | Description |
|:-----------------|:------|:--------------------------------------------------|
| `overlay.active` | Array | Array of Peer Objects, where each member is a peer that is connected to this server. |
Each member of the `active` array is a Peer Object with the following fields:
| `Field` | Value | Description |
|:-------------|:-------------------------|:-----------------------------------|
| `ip` | String (IPv4 Address) | The IP address of this connected peer. |
| `port` | String (Number) | The port number on the peer server that serves RTXP. Typically 51235. |
| `public_key` | String (Base-64 Encoded) | The public key of the ECDSA key pair used by this peer to sign RTXP messages. (This is the same data as the `pubkey_node` reported in the peer server's [`server_info` command](server_info.html).) |
| `type` | String | The value `in` or `out`, indicating whether the TCP connection to the peer is incoming or outgoing. |
| `uptime` | Number | The number of seconds the server has been connected to this peer. |
| `version` | String | The `rippled` version number the peer reports to be using. |
#### Example
Request:
<!-- MULTICODE_BLOCK_START -->
*HTTP*
```
GET https://s1.ripple.com:51235/crawl
```
*cURL*
```
curl -k https://s1.ripple.com:51235/crawl
```
<!-- MULTICODE_BLOCK_END -->
Response:
```json
200 OK
{
"overlay": {
"active": [{
"ip": "208.43.252.243",
"port": "51235",
"public_key": "A2GayQNaj7qbqLFiCFW2UXtAnEPghP/KWVqix2gUa6dM",
"type": "out",
"uptime": 107926,
"version": "rippled-0.31.0-rc1"
}, {
"ip": "184.172.237.226",
"port": "51235",
"public_key": "Asv/wKq/dqMWbP2M4eR+QvkuojYMLRXhKhIPnW40bsaF",
"type": "out",
"uptime": 247376,
"version": "rippled-0.31.0-rc1"
}, {
"ip": "54.186.73.52",
"port": "51235",
"public_key": "AjikFnq0P2XybCyREr2KPiqXqJteqwPwVRVbVK+93+3o",
"type": "out",
"uptime": 328776,
"version": "rippled-0.31.0-rc1"
}, {
"ip": "169.53.155.59",
"port": "51235",
"public_key": "AyIcVhAhOGnP0vtfCt+HKUrx9B2fDvP/4XUkOtVQ37g/",
"type": "out",
"uptime": 328776,
"version": "rippled-0.31.1"
}, {
"ip": "169.53.155.44",
"port": "51235",
"public_key": "AuVZszWXgMgM8YuTVhQsGE9OciEeBD8aMVe1mFid3n63",
"type": "out",
"uptime": 328776,
"version": "rippled-0.32.0-b12"
}, {
"ip": "184.173.45.39",
"port": "51235",
"public_key": "Ao2GbGbp2QYQ2B4S9ckCtON7CsZdXqdK5Yon4x7qmWFm",
"type": "out",
"uptime": 63336,
"version": "rippled-0.31.0-rc1"
}, {
"ip": "169.53.155.34",
"port": "51235",
"public_key": "A3inNJsIQzO7z7SS7uB9DyvN0wsiS9it/RGY/kNx6KEG",
"type": "out",
"uptime": 328776,
"version": "rippled-0.31.0-rc1"
}, {
"ip": "169.53.155.45",
"port": "51235",
"public_key": "AglUUjwXTC2kUlK41WjDs2eAVN0SnlMpzYA9lEgB0UGP",
"type": "out",
"uptime": 65443,
"version": "rippled-0.31.0-rc1"
}, {
"ip": "99.110.49.91",
"port": "51301",
"public_key": "AuQDH0o+4fpl2n+pR5U0Y4FTj0oGr4iEKe0MObPcSYj9",
"type": "out",
"uptime": 328776,
"version": "rippled-0.32.0-b9"
}, {
"ip": "169.53.155.36",
"port": "51235",
"public_key": "AsR4xub7MLg2Zl5Fwd/n7dTz7mhbBoSyCc/v9bnubrVy",
"type": "out",
"uptime": 328776,
"version": "rippled-0.31.0-rc1"
}]
}
}
```
## Private Peers
<!--{# TODO: unify with the very similar "Public-Facing Server" section of rippled-setup and probably move to a tutorial #}-->
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.
You can use the `[peer_private]` stanza of the `rippled` config file to request that peer servers do not report your IP address in the Peer Crawler response. Servers you do not control can be modified not to respect this setting. However, you can use this to hide the IP addresses of `rippled` servers you control that _only_ connect to peers you control (using `[ips_fixed]` and a firewall). In this way, you can use public rippled servers you control as proxies for your private rippled servers.
Configuring a server as a private server has several effects:
To protect an important [validating server](rippled-server-modes.html), Ripple recommends configuring one or more public tracking servers to act as proxies, while the validating server is protected by a firewall and only connects to the public tracking servers.
- 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.
- The server does not accept incoming connections from other servers unless it has been explicitly configured to accept connections from those servers.
- The server asks its direct peers not to reveal its IP address in untrusted communications, including the [peer crawler API response](peer-crawler.html). This does not affect trusted communications such as the [peers admin method][peers method].
<!--{# TODO: network diagram of private peers #}-->
Validators always ask their peers to hide the validators' IP addresses, regardless of the private server settings. This helps protect validators from being overloaded by denial of service attacks. [New in: rippled 1.2.1][]
**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.
### 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:
@@ -175,3 +67,9 @@ Example configuration:
[peer_private]
1
```
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/references/data-api.md
View File

@@ -5231,7 +5231,7 @@ Volume objects represent the total volumes of money moved, in either payments or
[Server Object]: #server-objects
[Server Objects]: #server-objects
A "Server Object" describes one `rippled` server in the XRP Ledger peer-to-peer network. Server objects are returned by the [Get Topology](#get-topology), [Get Toplogy Nodes](#get-topology-nodes), and [Get Topology Node](#get-topology-node) methods. The Data API collects reported network topology approximately every 30 seconds using the [peer crawler](peer-protocol.html#peer-crawler).
A "Server Object" describes one `rippled` server in the XRP Ledger peer-to-peer network. Server objects are returned by the [Get Topology](#get-topology), [Get Toplogy Nodes](#get-topology-nodes), and [Get Topology Node](#get-topology-node) methods. The Data API collects reported network topology approximately every 30 seconds using the [peer crawler](peer-crawler.html).
Server objects have the following fields, with some only appearing if the request specified a verbose response:

4
content/references/rippled-api/admin-rippled-methods/key-generation-methods/validation_create.md
View File

@@ -1,11 +1,11 @@
# validation_create
[[Source]<br>](https://github.com/ripple/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/ValidationCreate.cpp "Source")
Use the `validation_create` command to generate cryptographic keys a `rippled` server can use to identify itself to the network. Similar to the [wallet_propose method][], this command makes no real changes, but only generates a set of keys in the proper format.
Use the `validation_create` command to generate [cryptographic keys a `rippled` server can use to identify itself to the network](peer-protocol.html#node-key-pair). Similar to the [wallet_propose method][], this method only generates a set of keys in the proper format. It does not any makes changes to the XRP Ledger data or server configuration.
_The `validation_create` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._
You can configure your server to use the generated key pair to sign validations (validation key pair) or regular peer-to-peer communications (node key pair).
You can configure your server to use the generated key pair to sign validations (validation key pair) or regular peer-to-peer communications ([node key pair](peer-protocol.html#node-key-pair)).
**Tip:** For configuring a robust validator, you should use the `validator-keys` tool (included in the `rippled` RPM) to generate validator tokens (which can be rotated) with an offline master key. For more information, see [Validator Setup](run-rippled-as-a-validator.html#3-enable-validation-on-your-rippled-server).

2
content/references/rippled-api/admin-rippled-methods/status-and-debugging-methods/peers.md
View File

@@ -1,7 +1,7 @@
# peers
[[Source]<br>](https://github.com/ripple/rippled/blob/52f298f150fc1530d201d3140c80d3eaf781cb5f/src/ripple/rpc/handlers/Peers.cpp "Source")
The `peers` command returns a list of all other `rippled` servers currently connected to this one, including information on their connection and sync status.
The `peers` command returns a list of all other `rippled` servers currently connected to this one over the [Peer Protocol](peer-protocol.html), including information on their connection and sync status.
*The `peers` request is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users!*

86
content/references/rippled-api/peer-crawler.md Normal file
View File

@@ -0,0 +1,86 @@
# Peer Crawler
The Peer Crawler is a special API endpoint for reporting on the health and topology of the peer-to-peer network. This API method is available by default on a non-privileged basis through the [Peer Protocol](peer-protocol.html) port, which is also used for `rippled` servers' peer-to-peer communications about consensus, ledger history, and other necessary information.
The information reported by the peer crawler is effectively public, and can be used to report on the overall XRP Ledger network, its health, and topology.
## Request Format
To request the Peer Crawler information, make the following HTTP request:
- **Protocol:** https
- **HTTP Method:** GET
- **Host:** (any `rippled` server, by hostname or IP address)
- **Port:** (the port number where the `rippled` server uses the Peer Protocol, typically 51235)
- **Path:** `/crawl`
- **Security:** Most `rippled` servers use a self-signed certificate to respond to the request. By default, most tools (including web browsers) flag or block such responses for being untrusted. You must ignore the certificate checking (for example, if using cURL, add the `--insecure` flag) to display a response from those servers.
**Tip:** Since this request uses the GET method, you can test this request using just the URL bar of your web browser. For example, <https://s1.ripple.com:51235/crawl> requests peer crawler information from one of Ripple's public servers.
## Response Format
The response has the status code **200 OK** and a JSON object in the message body.
The JSON object has the following fields:
| `Field` | Value | Description |
|:-----------------|:-------|:-------------------------------------------------|
| `counts` | Object | _(May be omitted)_ Stats about this server's health, similar to the response from the [get_counts method][]. The default configuration does not report this field. Information reported includes: how large the ledger and transaction databases are, the cache hit rate for the in-application caches, and how many objects of various types are cached in memory. Types of objects that may be stored in memory include ledgers (`Ledger`), transactions (`STTx`), validation messages (`STValidation`), and more. |
| `overlay` | Object | _(May be omitted)_ Information about the peer servers currently connected to this one, similar to the response from the [peers method][]. Contains one field, `active`, which is an array of objects (see below). |
| `server` | Object | _(May be omitted)_ Information about this server. Contains public fields from the [server_state method][], including what `rippled` version you are running (`build_version`), which [ledger versions](ledger-history.html) your server has available (`complete_ledgers`), and the amount of load your server is experiencing. [Updated in: rippled 1.2.1][New in: rippled 1.2.1] |
| `unl` | Object | _(May be omitted)_ Information about the validators and validator list sites this server is configured to trust, similar to the response from the [validators method][] and [validator_list_sites method][]. [Updated in: rippled 1.2.1][New in: rippled 1.2.1] |
| `version` | Number | Indicates the version of this peer crawler response format. The current peer crawler version number is `2`. [Updated in: rippled 1.2.1][New in: rippled 1.2.1] |
Each member of the `overlay.active` array is an object with the following fields:
| `Field` | Value | Description |
|:-------------|:-------------------------|:-----------------------------------|
| `complete_ledgers` | String | The range of [ledger versions](ledger-history.html) this peer has available. |
| `complete_shards` | String | _(May be omitted)_ The range of [ledger history shards](history-sharding.html) this peer has available. |
| `ip` | String (IPv4 Address) | _(May be omitted)_ The IP address of this connected peer. Omitted if the peer is configured as a validator or a [private peer](peer-protocol.html#private-peers). [Updated in: rippled 1.2.1][New in: rippled 1.2.1] |
| `port` | String (Number) | _(May be omitted)_ The port number on the peer server that serves RTXP. Typically `51235`. Omitted if the peer is configured as a validator or a [private peer](peer-protocol.html#private-peers). [Updated in: rippled 1.2.1][New in: rippled 1.2.1] |
| `public_key` | String (Base-64 Encoded) | The public key of the ECDSA key pair used by this peer to sign RTXP messages. (This is the same data as the `pubkey_node` reported by the peer server's [server_info method][].) |
| `type` | String | The value `in` or `out`, indicating whether the TCP connection to the peer is incoming or outgoing. |
| `uptime` | Number | The number of seconds the server has been connected to this peer. |
| `version` | String | The `rippled` version number the peer reports to be using. |
#### Example
Request:
<!-- MULTICODE_BLOCK_START -->
*HTTP*
```
GET https://localhost:51235/crawl
```
*cURL*
```
curl --insecure https://localhost:51235/crawl
```
<!-- MULTICODE_BLOCK_END -->
Response:
```json
200 OK
{% include '_code-samples/peer-crawler/crawl.json' %}
```
## See Also
- [Peer Protocol](peer-protocol.html)
- [Configure the Peer Crawler](configure-the-peer-crawler.html)
- The [XRPL Network Crawler](https://github.com/ripple/rippled-network-crawler) is an example of a tool that uses the peer crawler data to collect and store information about the XRP Ledger network.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

61
content/tutorials/manage-the-rippled-server/configuration/configure-the-peer-crawler.md Normal file
View File

@@ -0,0 +1,61 @@
# Configure the Peer Crawler
By default, `rippled` servers provide statistics publicly to anyone who asks using the [peer crawler API](peer-crawler.html), to make it easier to track the health and topology of the XRP Ledger's peer-to-peer network. You can configure your server to provide more or less information, or to reject peer crawler requests entirely. [New in: rippled 1.2.0][]
This document contains steps for two options:
- [Change the Information Reported by the Peer Crawler](#change-the-information-reported-by-the-peer-crawler)
- [Disable the Peer Crawler](#disable-the-peer-crawler)
## Change the Information Reported by the Peer Crawler
To configure how much information your server provides in response to peer crawler requests, complete the following steps:
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. Add or update the `[crawl]` stanza in your config file, and save the changes:
[crawl]
overlay = 1
server = 1
counts = 0
unl = 1
The fields in this stanza control which fields the server returns in the [peer crawler response](peer-crawler.html#response-format). The names of the config fields match the fields of the API response. A setting with a value of `1` means to include the field in the response. A value of `0` means to omit that field from the response. This example shows the default values for each setting.
3. After saving the changes to the config file, restart your `rippled` server to apply the updated configuration:
systemctl restart rippled
## Disable the Peer Crawler
To disable the peer crawler API on your server, so it does not respond to peer crawler requests at all, complete the following steps:
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. Add or update the `[crawl]` stanza in your config file, and save the changes:
[crawl]
0
Remove or comment out all other contents of the crawl stanza.
3. After saving the changes to the config file, restart your `rippled` server to apply the updated configuration:
systemctl restart rippled
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

1
content/tutorials/manage-the-rippled-server/configuration/enable-public-signing.md
View File

@@ -29,6 +29,7 @@ To enable public signing, perform the following steps:
systemctl restart rippled
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

2
content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.md
View File

@@ -192,7 +192,7 @@ The benefit of this configuration is more redundancy and access to a lot of safe
$ sudo systemctl restart rippled.service
7. Use the [Peer Crawler](peer-protocol.html#peer-crawler) endpoint on one of your stock `rippled` servers. The response should not include your validator. This verifies that your validator's `[peer_private]` configuration is working. One of the effects of enabling `[peer_private]` on your validator is that your validator's peers do not include it in their Peer Crawler results.
7. Use the [Peer Crawler](peer-crawler.html) endpoint on one of your stock `rippled` servers. The response should not include your validator. This verifies that your validator's `[peer_private]` configuration is working. One of the effects of enabling `[peer_private]` on your validator is that your validator's peers do not include it in their Peer Crawler results.
## 5. Verify your network connection

20
dactyl-config.yml
View File

@@ -1132,6 +1132,16 @@ pages:
targets:
- local
- 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.
targets:
- local
- md: tutorials/manage-the-rippled-server/configuration/enable-public-signing.md
html: enable-public-signing.html
funnel: Docs
@@ -2694,6 +2704,16 @@ pages:
targets:
- local
- md: references/rippled-api/peer-crawler.md
html: peer-crawler.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Peer Crawler
blurb: Special API method for sharing network topology and status metrics.
targets:
- local
# --------------- end "rippled API" section --------------------------------
- name: RippleAPI Reference # name is required for remote-sourced files