ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-12-06 17:27:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #269 from mDuo13/fixafuture

Browse Source 
tx cost: fix 'in a future.' typo
This commit is contained in:
Rome Reginelli
2017-09-01 15:26:56 -07:00
committed by GitHub
parent 296c7e9174 bd7ca6b1a5
commit e0a79f7c14
2 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
concept-transaction-cost.html
View File

@@ -234,7 +234,7 @@
<h3 id="queued-transactions">Queued Transactions</h3>
<p>When <code>rippled</code> receives a transaction that meet the server's local load cost but not the <a href="#open-ledger-cost">open ledger cost</a>, the server estimates whether the transaction is "likely to be included" in a later ledger. If so, the server adds the transaction to the transaction queue and relays the transaction to other members of the network. Otherwise, the server discards the transaction. The server tries to minimize the amount of network load caused by transactions that would not pay a transaction cost, since <a href="#transaction-costs-and-failed-transactions">the transaction cost only applies when a transaction is included in a validated ledger</a>.</p>
<p>When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first, proportional to the <a href="#reference-transaction-cost">reference cost</a> of those transactions. Transactions that pay the same transaction cost are queued in the order the server receives them.</p>
<p class="devportal-callout note"><strong>Note:</strong> When <code>rippled</code> queues a transaction, the provisional <a href="reference-transaction-format.html#transaction-results">transaction response code</a> is <code>terQUEUED</code>. This means that the transaction is likely to succeed in a future. As with all provisional response codes, the outcome of the transaction is not final until the transaction is either included in a validated ledger, or <a href="reference-transaction-format.html#finality-of-results">rendered permanently invalid</a>.</p>
<p class="devportal-callout note"><strong>Note:</strong> When <code>rippled</code> queues a transaction, the provisional <a href="reference-transaction-format.html#transaction-results">transaction response code</a> is <code>terQUEUED</code>. This means that the transaction is likely to succeed in a future ledger version. As with all provisional response codes, the outcome of the transaction is not final until the transaction is either included in a validated ledger, or <a href="reference-transaction-format.html#finality-of-results">rendered permanently invalid</a>.</p>
<h4 id="queuing-restrictions">Queuing Restrictions</h4>
<p>The <code>rippled</code> server uses a variety of heuristics to estimate which transactions are "likely to be included in a ledger." The current implementation uses the following rules to decide which transactions to queue:</p>
<ul>

2
content/concept-transaction-cost.md
View File

@@ -62,7 +62,7 @@ When `rippled` receives a transaction that meet the server's local load cost but
When the current open ledger closes and the server starts a new open ledger, the server starts taking transactions from the queue to include in the new open ledger. The transaction queue is sorted with the transactions that would pay the highest transaction cost first, proportional to the [reference cost](#reference-transaction-cost) of those transactions. Transactions that pay the same transaction cost are queued in the order the server receives them.
**Note:** When `rippled` queues a transaction, the provisional [transaction response code](reference-transaction-format.html#transaction-results) is `terQUEUED`. This means that the transaction is likely to succeed in a future. As with all provisional response codes, the outcome of the transaction is not final until the transaction is either included in a validated ledger, or [rendered permanently invalid](reference-transaction-format.html#finality-of-results).
**Note:** When `rippled` queues a transaction, the provisional [transaction response code](reference-transaction-format.html#transaction-results) is `terQUEUED`. This means that the transaction is likely to succeed in a future ledger version. As with all provisional response codes, the outcome of the transaction is not final until the transaction is either included in a validated ledger, or [rendered permanently invalid](reference-transaction-format.html#finality-of-results).
#### Queuing Restrictions ####