ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-28 07:35:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Server modes: rewrite to add reporting mode

Browse Source
This commit is contained in:
mDuo13
2021-02-09 17:14:07 -08:00
parent 56163c7f52
commit cd673acb6e
13 changed files with 88 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/concepts/payment-system-basics/transaction-basics/finality-of-results.md
View File

@@ -40,7 +40,7 @@ When you initially submit a transaction, the `rippled` server tentatively applie
- A [Payment transaction][] that tentatively failed because the sender did not have enough funds may later succeed because another transaction delivering the necessary funds came first in the canonical order. The reverse is also possible: a transaction that tentatively succeeded may fail because a transaction delivering the necessary funds did not come first after being put into canonical order.
**Tip:** For this reason, when running tests against the XRP Ledger, be sure to wait for a ledger close in between transactions if you have several accounts affecting the same data. If you are testing against a server in [stand-alone-mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode), you must [manually close the ledger](advance-the-ledger-in-stand-alone-mode.html) in such cases.
**Tip:** For this reason, when running tests against the XRP Ledger, be sure to wait for a ledger close in between transactions if you have several accounts affecting the same data. If you are testing against a server in [stand-alone mode][], you must [manually close the ledger](advance-the-ledger-in-stand-alone-mode.html) in such cases.
## See Also

2
content/concepts/payment-system-basics/transaction-basics/transaction-basics.md
View File

@@ -54,7 +54,7 @@ Sending a transaction to the XRP Ledger involves several steps:
3. Submit a transaction to a `rippled` server. If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network.
4. The [consensus process](consensus.html) determines which provisional transactions get included in the next validated ledger.
5. The `rippled` servers apply those transactions to the previous ledger in a canonical order and share their results.
6. If enough [trusted validators](rippled-server-modes.html#reasons-to-run-a-validator) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](transaction-results.html) in that ledger are immutable.
6. If enough [trusted validators](rippled-server-modes.html#validators) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](transaction-results.html) in that ledger are immutable.
See [Send XRP](send-xrp.html) for an interactive tutorial in sending XRP payments.