ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-27 23:25:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

Information Architecture v3 (#1934)

Browse Source 
* Update look up escrows to remove redundant info about lookups via sender/destination. Modify cancel expired escrow for brevity.

* Cancel escrow: fix notes

* Add draft of updated cancel-escrow.js.

* Update intro to escrows.

* Add Escrow Tutorial

* Minor corrections

* Fix headings, add HTML

* Update escrow docs

This commit re-creates f205a92db2 with
some adjustments:

- Omit the accidentally-created dir full of junk
- Fix some typos and one mistake in the Escrow limitations section
- Add a table to the EscrowCreate ref to clarify valid combos of fields.

* Concept info from send-a-time-held-escrow added to escrow.md

* IA: Move "Consensus Network" files

This re-creates some work from the original commit 56fffe0b9f

* Rewrite escrows article (re-created)

This commit re-creates relevant work from the following commits:

9a4a588f2b Update escrow.md context info
e1b017dc83 Remove references to using escrow for interledger payments.

* IA: Move "XRPL servers" files

This re-creates some work from original commit 7611979abf

* IA: move "production readiness" files.

Re-creates work from the following commit:

692438693a  Move tutorials to concepts

* New intro articles

Original commit: 56fffe0b9f

* IA: Reorg account concepts

Re-creates some work from original commit 56fffe0b9f

* IA: reorg transaction concepts

Original commits:
9d4eff9940  WIP - reorg accounts
7611979abf  WIP dir. reorg

* IA: reorg consensus concepts

Original commit: 56fffe0b9f

* IA: Reorg ledger docs

Original commit: 56fffe0b9f

- Rephrased some details of the section

* IA: rename issuing/operational addresses page

Original commit: 56fffe0b9f

* Moving use cases

* Fleshing out Use Cases

Note, the dactyl-config.yml file has not been fully updated.

* Clean up checks conceptual info.

* Remove redundant checks use case section

Original commit: 3c29e9c05e

* IA: move Dex under tokens

Original commit: d08b3ba7d7

* Touch up stablecoin issuer use case (#1856)

* Consolidate stablecoin use case

* Stablecoin issuer: cleanup progress through sending

* Stablecoin issuer: reorg second half

(Note: the dactyl-config.yml is not fully reconciled yet)

* Move rippled and clio tutorials into infrastructure

* Remove link to checks amendement.

* Add note to account_objects.md about commandline interface type field.

* Merge expiration case with lifecycle section.

* Interoperability Use Cases

* Add graphics to intro

* Move escrow use cases to dedicated page.

* Update use case page intros and corresponding concept info.

* Clarify meaning of direct XRP payments.

* Intro link updates

* Payment use cases

* Remove some unnecessary links in transactions section

Original commit: e6fcf4a4dc

* Link cleanup in Tokens section

Original commit: 9588dd5e70

* Touch up 'Configure Peering' section

Original commit: fc8f0990b8

* Clean up links in accounts section

Original commit: 3da5fde7a8

* Add NFT mkt use case

* p2p payments: edits to Wallets

* Clean up payments use cases

* Refine history description

* IA: use case cleanup

* IA: reconcile servers, ledgers sections

* IA: reconcile payment types, tx, tokens

* IA: reconcile accounts section

* IA: reconcile infra

* IA: Fix most broken links

* Full Docs Index: omit from sidebar

* IA: fix up most broken links

* fix Absolute path link to internal content

* Quick updates to Software Ecosystem

* Remove some absolute links to internal resources

* Fix remaining broken links in JA target

* Contributing: tweak formatting

* Tutorials: fix some minor issues

* remove interop use cases

* remove intro image and personal references to dennis

* alphabetize-transaction-nav

* Remove unused files

* Add QS escrow tutorials

* IA: move ledgers, consensus protocol files around

* IA: update nav for new page hierarchy

* reordering of topics under new networks and servers top-nav

* Move "Naming" to "What is XRP?"

* Update dactyl-config.yml

Remove xrp.md from the TOC.

* Update list-xrp-as-an-exchange.md

Update link to what-is-xrp

* Update list-xrp-as-an-exchange.ja.md

Change link to what-is-xrp

* Update currency-formats.md

Change link to what-is-xrp

* Update currency-formats.ja.md

Change link to what-is-xrp

* Update cancel-an-expired-escrow.md

Change link to what-is-xrp

* Update paymentchannelfund.md

Change link to what-is-xml

* Update look-up-escrows.md

Change link to what-is-xrp

* Update tokens.md

change link to what-is-xrp

* Update use-payment-channels.md

* Update send-a-time-held-escrow.md

Update link to what-is-xml

* fix broken links

* Update parallel-networks.md

Change link to what-is-xml

* Update parallel-networks.ja.md

* Update invariant-checking.md

Remove link to xrp.html

* Update invariant-checking.ja.md

Remove link to xrp.html

* Update transaction-cost.md

Change link to what-is-xrp

* Update transaction-cost.ja.md

Change link to what-is-xrp

* Update send-a-conditionally-held-escrow.md

Change link to what-is-xrp

* Update stablecoin-issuer.md

Change link to what-is-xrp

* Update tokens.ja.md

Change link to what-is-xml

* Update autobridging.ja.md

Change link to what-is-xrp

* Update currency-formats.md

update text

* reorganize infrastructure nav section

* Update currency-formats.md

Try removing link altogether.

* Update currency-formats.ja.md

Remove link to what-is-xrp.html

* move commandline usage topic to infrastructure

* initial intro rewrite

* minor update to language

* IA.v3: rm Production Readiness

* Delete xrp.md

* Update xrp link in snippet

* Add redirect for old xrp.html URL

* Small edits to 'What is XRP?' article

* Add missing imgs

* XRP - copy edit per @DennisDawson

* restructure tutorials nav and pages

* fix broken links

* more broken link fixes

* Algo trading: 1st draft

* Algo trading: notes on taxes

* Algo trading: edits per review

* algo trading: fix broken link

* Ledger structure: rewrite for accuracy and clarity

* Update links to removed 'tree format' header

* Ledger Structure: Update diagrams

* Re-gen CSS for ledger structure changes

* Ledger structure: edits per review

* IA.v3: fix broken NFT links introduced by rebase

* Desktop Wallet (py): update little stuff

* Update some capacity/storage details

* contribute doc nav update

* fix image link in create diagram page

* IAv3: Fix 'Ledgers' blurb

* Update full history requirements with details from community members

* add reviewer suggestions

* Edits per @trippled review

* Apply suggestions from peer review

Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>

* FH: reword file size limit note per review

* Update software ecosystem

* updates per review

* Minor tweaks to graphics

* fixTypos

* Update content/concepts/introduction/software-ecosystem.md

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* Update content/concepts/introduction/software-ecosystem.md

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* [JA] update AccountDelete cost

* custom transactors doc

* add doc to dactyl config

* [JA] fix NonFungibleTokensV1_1 amendment status

* [JA] update NFTokenOffer page

* Remove old, unused XRP article (#2039)

* add reviewer suggestions

* Add tooling to check for file/nav consistency

- From the repo top, run tool/check_file_consistency.py to look for
  Markdown files that exist in the "content/" directory but aren't used
  in the documentation.
- New "enforce_filenames" filter prints a warning to console when
  building, if a file's path and filename don't match expectations
  based on its place in the nav and top heading.

* File consistency checker: correctly handle filenames starting in _

* Remove unused old 'get started' and associated code

* Create Resources section & reorg some files

- Rename some files/folders based on their place in the nav
- Move a bunch of non-documentation stuff, and docs on contributing code
  and/or docs to the new "Resources" section.
- Known issue: nav spills into a second row on page widths between
  993px-1110px. To be fixed in a later CSS update, maybe along with
  making the Resources dropdown multi-column.

* Fix #2078 code tab bug

CSS not built yet, to reduce merge conflicts. Won't have any effect
until that happens.

* fix Transaction JSON

* [JA] translate contributing contents

* fix contributing-to-documentation parent

* fix contribute-code blurb

* Top nav: add cols for Resources, fix broken links

* CSS: fix top nav overflows

* Fix broken link from redirect not in JA target

* Top nav: add Infra to article types

* Update contrib info & rename intro file

* [ja] Update link to suggested first page to translate

* [ja] fix contribute docs organization

* Run private network with docker tutorial (#2065)

* [NO-ISSUE] Run private network with docker tutorial

Adds a tutorial page in the Infrastructure section on how to run a private XRPL network with Docker.

Please let me know if you think this is a useful page to include for developers, whether the steps are clear or not, and if you have suggestions on what can be added to it.

* Add minor link fixes and Japanese target

* Apply suggestions from code review

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* Add link to ripple-docker-testnet setup scripts in See Also section

* Update repo URL

---------

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* add intro gfx (#2036)

* add intro gfx

* Move graphic up

* Update some graphics with their revised versions

* Add updated version of the custodial vs non-custodial graphic

---------

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>

* Update to reflect current UNL publishers

* [ja] update contributing

Co-authored-by: tequ <git@tequ.dev>

* Incorporate feedback on "What is XRP" page. (#2099)

* Add trademark info for XRP

* Revert section to previous state

* Fix broken link (#2101)

---------

Co-authored-by: Oliver Eggert <oeggert@ripple.com>
Co-authored-by: ddawson <dennis.s.dawson@gmail.com>
Co-authored-by: Maria Shodunke <mshodunke@ripple.com>
Co-authored-by: tequ <git@tequ.dev>
Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: develoQ <develoQ.jp@gmail.com>
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>
This commit is contained in:
Rome Reginelli
2023-09-01 12:40:18 -07:00
committed by GitHub
parent 31a068e6ae
commit b51bcb4ea3
445 changed files with 9020 additions and 4411 deletions
Download Patch File Download Diff File Expand all files Collapse all files

94
content/infrastructure/rippled/configure-peering/cluster-rippled-servers.ja.md Normal file
View File

@@ -0,0 +1,94 @@
---
html: cluster-rippled-servers.html
parent: configure-peering.html
blurb: サーバーのグループで処理を分担するように設定して効率化します。
labels:
- コアサーバー
---
# rippledサーバーのクラスター化
1つのデータセンターで複数の`rippled`サーバーを稼働している場合は、これらのサーバーを[クラスター](clustering.html)に構成して、効率を最大化できます。クラスター構成の設定は次のとおりです。
1. 各サーバーのIPアドレスをメモします。
2. [validation_createメソッド][]を使用して各サーバーの一意のシードを生成します。
コマンドラインインターフェイスを使用する場合の例を以下に示します。
$ 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"
}
}
各応答の`validation_seed`パラメーターと`validation_public_key`パラメーターを安全な場所に保存します。
3. 各サーバーで[構成ファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)を編集し、以下のセクションを変更します。
1. `[ips_fixed]`セクションに、クラスターの _その他の_ 各メンバーのIPアドレスとポートを記入します。各サーバーのポート番号は、サーバーの `rippled.cfg`に指定されている`protocol = peer`ポート（通常は51235）と一致している必要があります。例:
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
この例では、このサーバーがダイレクトピアツーピア接続の維持を常に試みる先のピアサーバーを特定しています。
2. `[node_seed]`セクションでは、サーバーのノードシードを、ステップ2で[validation_createメソッド][]を使用して生成した`validation_seed`の値の1つに設定します。各サーバーは一意のノードシードを使用する必要があります。例:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
この例では、ピアツーピア通信（検証メッセージを除く）の署名にサーバーが使用するキーペアを定義しています。
3. `[cluster_nodes]`セクションでは、サーバーのクラスターのメンバーを設定します。これらのメンバーは`validation_public_key`の値で識別されます。各サーバーのクラスターの _その他の_ すべてのメンバーをここに記入する必要があります。任意で、各サーバーのカスタム名を追加します。例:
[cluster_nodes]
n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar keynes
n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa friedman
この例は、サーバーがクラスターのメンバーを認識するために使用するキーペアを定義しています。
4. 構成ファイルを保存した後、各サーバーで`rippled`を再起動します。
# systemctl restart rippled
5. 各サーバーがクラスターのメンバーになっていることを確認するには、[peersメソッド][]を使用します。`cluster`フィールドに、各サーバーの公開鍵とカスタム名（構成している場合）のリストが表示されます。
コマンドラインインターフェイスを使用する場合の例を以下に示します。
$ rippled peers
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"cluster" : {
"n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar": {
"tag": "keynes",
"age": 1
},
"n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa": {
"tag": "friedman",
"age": 1
}
},
"peers" : [
...(omitted) ...
],
"status" : "success"
}
}
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

104
content/infrastructure/rippled/configure-peering/cluster-rippled-servers.md Normal file
View File

@@ -0,0 +1,104 @@
---
html: cluster-rippled-servers.html
parent: configure-peering.html
blurb: Set up a group of servers that share work for higher efficiency.
labels:
- Core Server
---
# Cluster rippled Servers
If you run multiple [`rippled` servers](xrpl-servers.html) in the same data center, you can configure them in a [cluster](clustering.html) to maximize efficiency. To configure clustering:
1. For each of your servers, note the IP address of the server.
2. For each of your servers, generate a unique seed using the [validation_create method][].
For example, using the commandline interface:
$ 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` and `validation_public_key` parameters from each response somewhere secure.
3. On each server, edit the [config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg), modifying the following sections:
1. In the `[ips_fixed]` section, list the IP address and port of each _other_ member of the cluster. For each of those servers, the port number should match the `protocol = peer` port (usually 51235) from that server's `rippled.cfg`. For example:
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
This defines specific peer servers to which this server should always attempt to maintain a direct peer-to-peer connection.
**Note:** If you omit the port number, the server uses port 2459, the IANA-assigned port for the XRP Ledger protocol.
2. In the `[node_seed]` section, set the server's node seed to one of the `validation_seed` values you generated using the [validation_create method][] in step 2. Each server must use a unique node seed. For example:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
This defines the key pair the server uses to sign peer-to-peer communications, excluding validation messages.
3. In the `[cluster_nodes]` section, set the members of the server's cluster, identified by their `validation_public_key` values. Each server should list the public keys of all _other_ members of the cluster here. Optionally, add a custom name for each server. For example:
[cluster_nodes]
n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar keynes
n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa friedman
This defines the key pairs the server uses to recognize members of its cluster.
4. After saving the config file, restart `rippled` on each server.
# systemctl restart rippled
5. To confirm that each server is now a member of the cluster, use the [peers method][]. The `cluster` field should list the public keys and (if configured) the custom names for each server.
For example, using the commandline interface:
$ rippled peers
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"cluster" : {
"n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar": {
"tag": "keynes",
"age": 1
},
"n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa": {
"tag": "friedman",
"age": 1
}
},
"peers" : [
... (omitted) ...
],
"status" : "success"
}
}
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- **Tutorials:**
- [Install rippled](install-rippled.html)
- **References:**
- [validation_create method][]
- [peers method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

98
content/infrastructure/rippled/configure-peering/configure-a-private-server.ja.md Normal file
View File

@@ -0,0 +1,98 @@
---
html: configure-a-private-server.html
parent: configure-peering.html
blurb: サーバーが特定の信頼できるピアのみに接続するように設定します。
labels:
- コアサーバー
- セキュリティ
---
# プライベートサーバーの設定
[プライベートサーバー](peer-protocol.html#プライベートピア)は、オープンなピアツーピアネットワーク内の検出されたピアに直接接続するのではなく、特定の信頼できるピアのみを通じてネットワークに接続する`rippled`サーバーです。この種の構成は、[バリデータ](run-rippled-as-a-validator.html)に一般的に推奨される任意の対策ですが、その他の特定の目的でも役立ちます。
## 前提条件
プライベートサーバーを使用するには、次の前提条件を満たしている必要があります。
- [`rippled`をインストール](install-rippled.html)して最新バージョンにアップデートし、まだ実行していない状態である必要があります。
- 自社で運用している**プロキシ**を通じて接続するか、**公開ハブ**を通じて接続するかを決める必要があります。これらの選択肢の違いについては、[ピアリング構成のメリットとデメリット](peer-protocol.html#ピア接続設定のメリットとデメリット)を参照してください。
- プロキシを使用している場合、`rippled`がインストールされていてプロキシとして使用し実行される別のマシンが必要です。これらのサーバーは、外部のネットワークとプライベートサーバーに接続できる必要があります。
- どちらの構成でも、接続先のピアのIPアドレスとポートを把握しておく必要があります。
## 手順
特定のサーバーをプライベートピアとして設定するには、次の手順を実行します。
1. `rippled`の構成ファイルを編集します。
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. プライベートピアリングを有効にします。
構成ファイルに以下のスタンザを追加するか、コメントを解除します。
[peer_private]
1
3. 固定数のピアを追加します。
構成ファイルに`[ips_fixed]`スタンザを追加するか、コメントを解除します。このスタンザの各行は、接続先のピアのホスト名またはIPアドレス、1個の空白文字、このピアがピアプロトコル接続を受け付けるポートの順に記載されている必要があります。
例えば、**公開ハブ**を使用して接続する場合は、以下のスタンザを使用できます。
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
サーバーが**プロキシ**を使用して接続している場合は、IPアドレスとポートが、プロキシとして使用している`rippled`サーバーの構成と一致している必要があります。これらの各サーバーについては、ポート番号が、サーバーの構成ファイルに記載されている`protocol = peer`ポート（通常は51235）と一致している必要があります。例えば、構成は次のようになります。
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
4. プロキシを使用している場合、プロキシをプライベートピアと互いを含めてクラスター化します。
公開ハブを使用している場合は、このステップをスキップします。
プロキシを使用している場合、プライベートピアを含む[クラスターとしてプロキシを構成](cluster-rippled-servers.html)します。クラスターの各メンバーは、クラスターの_他の_各メンバーをリストにした`[ips_fixed]`スタンザを持っている必要があります。ただし、`[peer_private]`スタンザを持つのは**プライベートサーバーのみ**とします。
各プロキシで`rippled`を再起動します。各プロキシサーバーで、次のようにします。
sudo service systemctl restart rippled
5. プライベートサーバーで`rippled`を起動します。
sudo service systemctl start rippled
6. [peersメソッド][]を使用して、プライベートサーバーが自身のピアに _のみ_ 接続していることを確認します。
応答の`peers`配列に、構成済みのピアのいずれでもない`address`を持つオブジェクトが含まれていてはなりません。含まれている場合は、構成ファイルを再度確認して、プライベートサーバーを再起動します。
## 次のステップ
追加の予防対策として、自身のピアでないサーバーからプライベートサーバーへの着信接続をブロックするようにファイアウォールを設定する必要があります。プロキシサーバーを実行している場合は、ファイヤーウォールを通じてプロキシに[ピアポートを転送](forward-ports-for-peering.html)するようにします。ただし、プライベートピアで**ない**ものに転送します。この設定方法の具体的な手順は、使用するファイアウォールによって異なります。
ファイアウォールがポート80で発信HTTP接続を**ブロックしない**ことを確認します。デフォルトの設定では、このポートを使用して**vl.ripple.com**から最新の推奨バリデータリストをダウンロードします。バリデータリストがないと、サーバーはどのバリデータを信頼してよいかわからず、ネットワークが、いつコンセンサスに至ったかを認識できません。
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [コンセンサス](consensus.html)
- [並列ネットワーク](parallel-networks.html)
- **チュートリアル:**
- [ピアクローラーの設定](configure-the-peer-crawler.html)
- **リファレンス:**
- [peersメソッド][]
- [connectメソッド][]
- [fetch_infoメソッド][]
- [ピアクローラー](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

100
content/infrastructure/rippled/configure-peering/configure-a-private-server.md Normal file
View File

@@ -0,0 +1,100 @@
---
html: configure-a-private-server.html
parent: configure-peering.html
blurb: Set up a server to connect only to specific, trusted peers.
labels:
- Core Server
- Security
---
# 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
**Note:** If you omit the port number, the server uses port 2459, the IANA-assigned port for the XRP Ledger protocol.
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' %}

14
content/infrastructure/rippled/configure-peering/configure-peering.ja.md Normal file
View File

@@ -0,0 +1,14 @@
---
html: configure-peering.html
name: Peering
parent: infrastructure.html
template: pagetype-category.html.jinja
blurb: サーバーをピアツーピアネットワークに接続する方法を設定します。
labels:
- コアサーバー
---
# ピアリングの設定
XRP Ledgerのピアツーピアプロトコルは、ほとんどの場合、ピア接続を自動的に管理します。場合によっては、サーバーが接続するピアを手動で調整して、サーバーの可用性とネットワークの他の部分との接続性を最大限に高めたいというケースがあります。
同じデータセンター内で複数のサーバーを稼動させている場合は、[クラスター化](cluster-rippled-servers.html)して効率を向上させたいケースがあります。ピアツーピアネットワークのトポロジー内の重要なハブなど、稼動していないが接続を維持したいサーバー用の予約済みピアスロットを使うことができます。他のピアについては、サーバーはピアを自動検出し、その接続を管理しますが、望ましくない動作をするピアをブロックするように手動で介入することもできます。

14
content/infrastructure/rippled/configure-peering/configure-peering.md Normal file
View File

@@ -0,0 +1,14 @@
---
html: configure-peering.html
name: Peering
parent: infrastructure.html
template: pagetype-category.html.jinja
blurb: Configure how your server connects to the peer-to-peer network.
labels:
- Core Server
---
# 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.

79
content/infrastructure/rippled/configure-peering/configure-the-peer-crawler.md Normal file
View File

@@ -0,0 +1,79 @@
---
html: configure-the-peer-crawler.html
parent: configure-peering.html
blurb: Configure how much information your rippled server reports publicly about its status and peers.
labels:
- Core Server
- Security
---
# Configure the Peer Crawler
By default, [`rippled` servers](xrpl-servers.html) 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](peer-protocol.html). You can configure your server to provide more or less information, or to reject peer crawler requests entirely.
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
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- **Tutorials:**
- [Manage the rippled Server](manage-the-rippled-server.html)
- **References:**
- [server_info method][]
- [peers 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' %}

51
content/infrastructure/rippled/configure-peering/enable-link-compression.md Normal file
View File

@@ -0,0 +1,51 @@
---
html: enable-link-compression.html
parent: configure-peering.html
blurb: Save bandwidth by compressing peer-to-peer communications.
labels:
- Core Server
---
# Enable Link Compression
The `rippled` server can save bandwidth by compressing its [peer-to-peer communications](peer-protocol.html), at a cost of greater CPU usage. If you enable link compression, the server automatically compresses communications with peer servers that also have link compression enabled.
## Steps
To enable link compression on your server, complete the following steps:
### 1. Edit your `rippled` server's config file.
```sh
$ vim /etc/opt/ripple/rippled.cfg
```
{% include '_snippets/conf-file-location.md' %}<!--_ -->
### 2. In the config file, add or uncomment the `[compression]` stanza.
To enable compression:
```text
[compression]
true
```
Use `false` to disable compression (the default).
### 3. Restart the `rippled` server
```sh
$ sudo systemctl restart rippled.service
```
After the restart, your server automatically uses link compression with other peers that also have link compression enabled.
## See Also
- [Capacity Planning](capacity-planning.html)
- [Peer Protocol](peer-protocol.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

66
content/infrastructure/rippled/configure-peering/forward-ports-for-peering.ja.md Normal file
View File

@@ -0,0 +1,66 @@
---
html: forward-ports-for-peering.html
parent: configure-peering.html
blurb: 受信ピアがrippledサーバーに接続できるようにファイアウォールを設定します。
labels:
- コアサーバー
---
# ピアリングのポート転送
XRP Ledgerのピアツーピアネットワーク内にあるサーバーは、[ピアプロトコル](peer-protocol.html)を介して通信します。セキュリティとネットワークの他の部分との接続を両立させるために、ファイアウォールを使用して、サーバーをほとんどのポートから保護し、ピアプロトコルポートだけを開放するか転送するようにする必要があります。
`rippled`サーバーの稼動中に、[server_infoメソッド][]を実行すると、いくつのピアがあるか確認することができます。`info`オブジェクトの`peers`フィールドは、サーバーに現在接続しているピアの数を示します。この数が10または11の場合、通常はファイアウォールが着信接続をブロックしていることを示します。
ファイアウォールが着信ピア接続をブロックしていると思われるためピアが10個しかないことを示している`server_info`の結果の例（一部省略）は次のとおりです。
```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" : {
...（省略）...
"load_factor" : 1,
"peer_disconnects" : "0",
"peer_disconnects_resources" : "0",
"peers" : 10,
"pubkey_node" : "n9KUjqxCr5FKThSNXdzb7oqN8rYwScB2dUnNqxQxbEA17JkaWy5x",
"pubkey_validator" : "n9KM73uq5BM3Fc6cxG3k5TruvbLc8Ffq17JZBmWC4uP4csL4rFST",
"published_ledger" : "none",
"server_state" : "connected",
...（省略）...
},
"status" : "success"
}
}
```
着信接続を許可するために、ピアプロトコルポートを転送するようにファイアウォールを設定します。ピアプロトコルポートは、デフォルトの構成ファイルでは**ポート51235**で提供されます。ポートの転送の手順はファイアウォールによって異なります。例えば、Red Hat Enterprise Linuxで`firewalld`ソフトウェアファイアウォールを使用している場合は、[`firewall-cmd`ツールを使用](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-port_forwarding)して、TCPトラフィックを次のように転送します。
```sh
$ sudo firewall-cmd --add-forward-port=port=51235:proto=tcp:toport=51235
```
その他のソフトウェアファイアウォールとハードウェアファイアウォールについては、メーカー公式のドキュメントを参照してください。
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [`rippled`サーバー](xrpl-servers.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [connectメソッド][]
- [peersメソッド][]
- [printメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

84
content/infrastructure/rippled/configure-peering/forward-ports-for-peering.md Normal file
View File

@@ -0,0 +1,84 @@
---
html: forward-ports-for-peering.html
parent: configure-peering.html
blurb: Configure your firewall to allow incoming peers to your rippled server.
labels:
- Core Server
---
# 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 allow incoming traffic on the peer protocol port, which is served on **port 51235** in the default config file. The instructions to open a port depend on your firewall. If your server is behind a router that performs Network Address Translation (NAT), you must configure your router to forward the port to your server.
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-using_zones_to_manage_incoming_traffic_depending_on_source) to open **port 51235** to all incoming traffic.
_Assuming `--zone=public` is your public [zone](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-working_with_zones#sec-Listing_Zones)._
```sh
$ sudo firewall-cmd --zone=public --add-port=51235/tcp
```
Then, restart the `rippled` server:
```sh
$ sudo systemctl restart rippled.service
```
To make it permanent:
```sh
$ sudo firewall-cmd --zone=public --permanent --add-port=51235/tcp
```
For other software and hardware firewalls, see the manufacturer's official documentation.
If you are using a hosting service with a virtual firewall (for example, [AWS Security Groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)), you do not need to use `firewalld`, but you still need to allow inbound traffic from the open internet on the peer port. Make sure you apply the relevant rules to your host or virtual machine.
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [The `rippled` Server](xrpl-servers.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' %}

79
content/infrastructure/rippled/configure-peering/manually-connect-to-a-specific-peer.ja.md Normal file
View File

@@ -0,0 +1,79 @@
---
html: manually-connect-to-a-specific-peer.html
parent: configure-peering.html
blurb: rippledサーバーを特定のピアに接続します。
labels:
- コアサーバー
---
# 特定のピアへの手動接続
サーバーをXRP Ledgerネットワーク内の特定の[ピア](peer-protocol.html)に手動で接続するには、次の手順を実行します。
**ヒント:** サーバーが起動時にこのサーバーに自動的に接続して、以降も接続を維持するようにするには、そのピアに対して[ピアリザベーション](use-a-peer-reservation.html)を設定することができます。
## 前提条件
- 接続先のピアのIPアドレスを把握しておく必要があります。
- 接続先のピアがXRP Ledger[ピアプロトコル](peer-protocol.html)に使用するポートを把握しておく必要があります。デフォルトでは、ポート51235です。
- サーバーからピアへのネットワーク接続を用意する必要があります。例えば、ピアサーバーは[ファイアウォールを通じて適切なポートを転送する](forward-ports-for-peering.html)必要があります。
- ピアサーバーに使用可能なピアスロットがある必要があります。ピアがすでにピアの最大数に達している場合、ピアサーバーのオペレーターに依頼して、サーバーの[ピアリザベーション](use-a-peer-reservation.html)を追加してもらいます。
## 手順
接続するには、[connectメソッド][]を使用します。例:
<!-- 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
}
]
}
```
*コマンドライン*
```
rippled connect 169.54.2.151 51235
```
<!-- MULTICODE_BLOCK_END -->
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [`rippled`サーバー](xrpl-servers.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [connectメソッド][]
- [peersメソッド][]
- [printメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

79
content/infrastructure/rippled/configure-peering/manually-connect-to-a-specific-peer.md Normal file
View File

@@ -0,0 +1,79 @@
---
html: manually-connect-to-a-specific-peer.html
parent: configure-peering.html
blurb: Connect your rippled server to a specific peer.
labels:
- Core Server
---
# 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). The default config file uses port 51235.
- You must have a network connection from your server to the peer. For example, the peer server must [forward the appropriate 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](xrpl-servers.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' %}

55
content/infrastructure/rippled/configure-peering/set-max-number-of-peers.ja.md Normal file
View File

@@ -0,0 +1,55 @@
---
html: set-max-number-of-peers.html
parent: configure-peering.html
blurb: rippledサーバーが接続するピアの最大数を設定します。
labels:
- コアサーバー
---
# ピアの最大数の設定
`rippled`サーバーには、接続先の[ピア](peer-protocol.html)の数を定める設定可能なソフト最大数があります。ピアのデフォルトの最大数は**21**です。
**注記:** 内部的に、サーバーは受信ピアと送信ピアのおおよそのクォータを生成します。[固定ピアやピアリザベーション](peer-protocol.html#固定ピアとピアリザベーション)を使用している場合、あるいは[connectメソッド][]を使用して追加のピアに手動で接続している場合は、このソフト最大数を超える可能性があります。
サーバーが許可するピアの最大数を変更するには、以下の手順を実行します。
1. `rippled`の構成ファイルを編集します。
$ vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. 構成ファイルで、`[peers_max]`スタンザのコメントを解除して編集するか、まだない場合は追加します。
[peers_max]
30
スタンザの内容は、許可するピアの合計数を示す整数のみである必要があります。デフォルトでは、サーバーは受信ピアが約85%、送信ピアが約15%という比率を維持するように試みますが、送信ピアの最小数が10であるため、68未満の値にしても、サーバーが行う送信ピア接続の数は増えません。
`[peers_max]`値を10未満にした場合でも、サーバーはハードコーディングされた最小数である10台の送信ピアを許可するため、ネットワークとの接続を維持できます。すべての送信ピア接続をブロックするには、[サーバーをプライベートピアとして設定](run-rippled-as-a-validator.html#プロキシを使用した接続)します。
**注意:** 接続先のピアサーバーが増えると、`rippled`サーバーが使用するネットワーク帯域幅も増えます。`rippled`サーバーに良好なネットワーク接続があり、使用する帯域幅のコストを許容できる場合にのみ、ピアサーバーの数に大きな値を設定してください。
3. `rippled`サーバーを再起動します。
$ sudo systemctl restart rippled.service
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [`rippled`サーバー](xrpl-servers.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [connectメソッド][]
- [peersメソッド][]
- [printメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

55
content/infrastructure/rippled/configure-peering/set-max-number-of-peers.md Normal file
View File

@@ -0,0 +1,55 @@
---
html: set-max-number-of-peers.html
parent: configure-peering.html
blurb: Set the maximum number of peers your rippled server connects to.
labels:
- Core Server
---
# 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](xrpl-servers.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' %}

185
content/infrastructure/rippled/configure-peering/use-a-peer-reservation.ja.md Normal file
View File

@@ -0,0 +1,185 @@
---
html: use-a-peer-reservation.html
parent: configure-peering.html
blurb: ピアリザベーションを使用して特定のピアへのより信頼できる接続を設定します。
lables:
- コアサーバー
---
# ピアリザベーションの使用
[ピアリザベーション][]を使用すると、`rippled`サーバーが予約とマッチしたピアからの通信を常に受け入れるように設定できます。このページでは、ピアリザベーションを使用して2台のサーバー間のピアツーピア通信を、各サーバーの管理者の協力のもと一貫して維持する方法について説明します。
ピアリザベーションは、2台のサーバーが異なる組織によって運用されていて、着信接続を受信するサーバーが、多くのピアを持つ[ハブサーバー](rippled-server-modes.html#公開ハブ)である場合に特に便利です。分かりやすいように、これらの手順では次の用語を使用します。
- **ストックサーバー**は発信接続を行うサーバーです。このサーバーは、ハブサーバー上のピアリザベーションを _使用_ します。
- **ハブサーバー**は着信接続を受信するサーバーです。管理者は、このサーバーにピアリザベーションを _追加_ します。
ただし、一方または両方のサーバーがハブ、バリデータ、ストックサーバーのいずれあっても、これらの手順を使用してピアリザベーションを設定できます。また、よりビジーな状態にあるサーバーから発信接続をする場合にもピアリザベーションを使用できますが、以下のプロセスではそのような構成については説明しません。
## 前提条件
これらの手順を実行するには、次の前提条件を満たしている必要があります。
- 両方のサーバーの管理者が`rippled`を[インストール](install-rippled.html)して実行している。
- 両方のサーバーの管理者が協力することに合意し、連絡が取り合える。秘密情報を共有する必要はないため、パブリックな通信チャネルを使用してもかまいません。
- ハブサーバーが着信ピア接続を受信できる。ファイアウォールをそのように設定する手順については、[ピアリングのポート転送](forward-ports-for-peering.html)を参照してください。
- 両方のサーバーが、同じ[XRP Ledgerネットワーク](parallel-networks.html)（本番XRP Ledger、Testnet、Devnetなど）と同期するように設定されている。
## 手順
ピアリザベーションを使用するには、以下の手順に従います。
### 1.（ストックサーバー）永続ノードキーペアを設定する
ストックサーバーの管理者が、以下の手順を実行します。
永続ノードキーペア値をすでにサーバーに設定している場合は、[ステップ2: ノード公開鍵をピアの管理者に連絡する](#2ストックサーバーのノード公開鍵を連絡する)に進んでください。（例えば、各サーバーの永続ノードキーペアは[サーバークラスターの設定](cluster-rippled-servers.html)の一環として設定します。）
**ヒント:** 永続ノードキーペアの設定は省略可能ですが、この設定をしておけば、サーバーのデータベースの消去や新規マシンへの移行が必要となった場合にピア接続の設定を容易に維持することができます。永続ノードキーペアを設定しない場合は、[server_infoメソッド][]の応答の`pubkey_node`フィールドに表示される、サーバーが自動生成したノード公開鍵を使用できます。
1. [validation_createメソッド][]を使用して新しいランダムキーペアを生成します。（`secret`値を省略します。）
例:
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"
}
}
`validation_seed`（ノードシード値）と`validation_public_key`値（ノード公開鍵）を保存します。
2. `rippled`の構成ファイルを編集します。
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
3. 前のステップで生成した`validation_seed`値を使用して、`[node_seed]`スタンザを追加します。
例:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
**警告:** すべてのサーバーの`[node_seed]`値が一意である必要があります。構成ファイルを別のサーバーにコピーする場合は、`[node_seed]`値を削除するか、変更してください。`[node_seed]`は公開しないようにします。不正使用者がこの値にアクセスできた場合、それを使用してサーバーを偽装し、XRP Ledgerのピアツーピア通信を行う可能性があります。
4. `rippled`サーバーを再起動します。
systemctl restart rippled
### 2.ストックサーバーのノード公開鍵を連絡する
ストックサーバーの管理者が、ハブサーバーの管理者にストックサーバーのノード公開鍵を伝えます。（ステップ1の`validation_public_key`を使用します。）ハブサーバーの管理者はこの値を以降のステップで使用する必要があります。
### 3.（ハブサーバー）ピアリザベーションを追加する
ハブサーバーの管理者が、以下の手順を実行します。
[peer_reservations_addメソッド][]を使用し、前のステップで入手したノード公開鍵を使用して予約を追加します。例:
```sh
$ rippled peer_reservations_add n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG "Description here"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result": {
"status": "success"
}
}
```
**ヒント:** 説明はオプションのフィールドです。この予約は誰のためにしたものかを人間が読み取れる形式のメモを追加できます。
### 4.ハブサーバーの現在のIPアドレスとピアポートを連絡する
ハブサーバーの管理者は、サーバーの現在のIPアドレスとピアポートをストックサーバーの管理者に伝える必要があります。ハブサーバーが、ネットワークアドレス変換（NAT）を行なうファイアウォールの内側にある場合は、サーバーの _外部_ IPアドレスを使用します。デフォルトの構成ファイルは、ピアプロトコルにポート51235を使用します。
### 5.（ストックサーバー）ピアサーバーに接続する
ストックサーバーの管理者が、以下の手順を実行します。
[connectメソッド][]を使用して、サーバーをハブサーバーに接続します。例:
<!-- 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
}
]
}
```
*コマンドライン*
```
rippled connect 169.54.2.151 51235
```
<!-- MULTICODE_BLOCK_END -->
ハブサーバーの管理者が上記の手順に従ってピアリザベーションを設定した場合、自動的に接続され、可能な限り接続が維持されます。
## 次のステップ
サーバーの管理者は、サーバーに設定された他のピアへの予約を管理できます。（他のサーバーからの予約は確認できません。）次のことを実行できます。
- [peer_reservations_addメソッド][]を使用して、ピアリザベーションの追加や説明の更新を行う。
- [peer_reservations_listメソッド][]を使用して、予約先のサーバーを確認する。
- [peer_reservations_delメソッド][]を使用して、予約を削除する。
- [peersメソッド][]を使用して、現在接続しているピアと使用している帯域幅の量を確認する。
**ヒント:** 不正なピアからの接続を即座に切断するAPIメソッドはありませんが、`firewalld`などのソフトウェアファイアウォールを使用すれば、不正なピアからのサーバーへの接続をブロックできます。例については、コミュニティーによって作成された[rbhスクリプト](https://github.com/gnanderson/rbh)を参照してください。
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [コンセンサス](consensus.html)
- [並列ネットワーク](parallel-networks.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [peersメソッド][]
- [peer_reservations_addメソッド][]
- [peer_reservations_delメソッド][]
- [peer_reservations_listメソッド][]
- [connectメソッド][]
- [fetch_infoメソッド][]
- [ピアクローラー](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

185
content/infrastructure/rippled/configure-peering/use-a-peer-reservation.md Normal file
View File

@@ -0,0 +1,185 @@
---
html: use-a-peer-reservation.html
parent: configure-peering.html
blurb: Set up a more reliable connection to a specific peer using a peer reservation.
labels:
- Core Server
---
# 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). <!-- SPELLING_IGNORE: 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' %}