ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 19:55:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix server states/info, common fields, etc. links

Browse Source
This commit is contained in:
mDuo13
2018-05-11 16:32:54 -07:00
parent 4921fc25ca
commit 6596451809
18 changed files with 26 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -377,7 +377,7 @@ The response follows the [standard format][], with a successful result containin
| `cluster` | Object | Summary of other `rippled` servers in the same cluster, if [configured as a cluster](clustering.html). [New in: rippled 0.30.1][] |
| `peers` | Array | Array of peer objects. |
Each field of the `cluster` object is the public key of that `rippled` server's identifying keypair. (This is the same value that that server returns as `pubkey_node` in the [`server_info` command](#server-info).) The contents of that field are an object with the following fields:
Each field of the `cluster` object is the public key of that `rippled` server's identifying keypair. (This is the same value that that server returns as `pubkey_node` in the [server_info method][].) The contents of that field are an object with the following fields:
| `Field` | Type | Description |
|:--------|:-------|:----------------------------------------------------------|

7
content/references/rippled-api/api-conventions/rippled-server-states.md
View File

@@ -1,6 +1,6 @@
# rippled Server States
Depending on how the `rippled` server is configured, how long it has been running, and other factors, a server may be participating in the global XRP Ledger peer-to-peer network to different degrees. This is represented as the `server_state` field in the responses to the [`server_info`](#server-info) and [`server_state`](#server-state) commands. The possible responses follow a range of ascending interaction, with each later value superseding the previous one. Their definitions are as follows (in order of increasing priority):
Depending on how the `rippled` server is configured, how long it has been running, and other factors, a server may be participating in the global XRP Ledger peer-to-peer network to different degrees. This is represented as the `server_state` field in the responses to the [server_info method][] and [server_state method][]. The possible responses follow a range of ascending interaction, with each later value superseding the previous one. Their definitions are as follows (in order of increasing priority):
| `Value` | Description |
|:---------------|:------------------------------------------------------------|
@@ -13,3 +13,8 @@ Depending on how the `rippled` server is configured, how long it has been runnin
| `proposing` | The server is participating in validation of the ledger and currently proposing its own version. |
**Note:** The distinction between `full`, `validating`, and `proposing` is based on synchronization with the rest of the global network, and it is normal for a server to fluctuate between these states as a course of general operation.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/references/rippled-api/ledger-data-formats/ledger-object-types/directorynode.md
View File

@@ -1,7 +1,7 @@
# DirectoryNode
[[Source]<br>](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L44 "Source")
The `DirectoryNode` object type provides a list of links to other objects in the ledger's state tree. A single conceptual _Directory_　takes the form of a doubly linked list, with one or more DirectoryNode objects each containing up to 32 [IDs](#tree-format) of other objects. The first object is called the root of the directory, and all objects other than the root object can be added or deleted as necessary.
The `DirectoryNode` object type provides a list of links to other objects in the ledger's state tree. A single conceptual _Directory_　takes the form of a doubly linked list, with one or more DirectoryNode objects each containing up to 32 [IDs](ledger-data-formats.html#tree-format) of other objects. The first object is called the root of the directory, and all objects other than the root object can be added or deleted as necessary.
There are two kinds of Directories:

2
content/references/rippled-api/public-rippled-methods/account-methods/gateway_balances.md
View File

@@ -195,7 +195,7 @@ An example of a successful response:
<!-- MULTICODE_BLOCK_END -->
**Note:** There is no command-line syntax for this method. Use the [`json` command](#json) to access this from the command line.
**Note:** There is no command-line syntax for this method. Use the [json method][] to access this from the command line.
The response follows the [standard format][], with a successful result containing the following fields:

2
content/references/rippled-api/public-rippled-methods/account-methods/noripple_check.md
View File

@@ -41,7 +41,7 @@ An example of the request format:
<!-- MULTICODE_BLOCK_END -->
**Note:** There is no command-line syntax for this method. Use the [`json` command](#json) to access this from the command line.
**Note:** There is no command-line syntax for this method. Use the [json method][] to access this from the command line.
The request includes the following parameters:

2
content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_data.md
View File

@@ -37,7 +37,7 @@ An example of the request format:
<!-- MULTICODE_BLOCK_END -->
**Note:** There is no commandline syntax for `ledger_data`. You can use the [`json` command](#json) to access this method from the commandline instead.
**Note:** There is no commandline syntax for `ledger_data`. You can use the [json method][] to access this method from the commandline instead.
A request can include the following fields:

2
content/references/rippled-api/public-rippled-methods/ledger-methods/ledger_entry.md
View File

@@ -3,7 +3,7 @@
The `ledger_entry` method returns a single ledger object from the XRP Ledger in its raw format. See [ledger format][] for information on the different types of objects you can retrieve.
**Note:** There is no commandline version of this method. You can use the [`json` command](#json) to access this method from the commandline instead.
**Note:** There is no commandline version of this method. You can use the [json method][] to access this method from the commandline instead.
## Request Format

2
content/references/rippled-api/public-rippled-methods/server-info-methods/server_state.md
View File

@@ -1,7 +1,7 @@
# server_state
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/ServerState.cpp "Source")
The `server_state` command asks the server for various machine-readable information about the `rippled` server's current state. The results are almost the same as [`server_info`](#server-info), but using units that are easier to process instead of easier to read. (For example, XRP values are given in integer drops instead of scientific notation or decimal values, and time is given in milliseconds instead of seconds.)
The `server_state` command asks the server for various machine-readable information about the `rippled` server's current state. The response is almost the same as the [server_info method][], but uses units that are easier to process instead of easier to read. (For example, XRP values are given in integer drops instead of scientific notation or decimal values, and time is given in milliseconds instead of seconds.)
## Request Format
An example of the request format:

2
content/references/rippled-api/transaction-formats/transaction-format-old-monolith.md
View File

@@ -16,7 +16,7 @@ To have both qualities when submitting a transaction, an application should:
4. Confirm that the transaction was either included in a validated ledger, or that it has expired due to `LastLedgerSequence`.
5. If a transaction fails or expires, you can modify and resubmit it.
Main article: [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html)
Main article: [Reliable Transaction Submission](reliable-transaction-submission.html)

2
content/references/rippled-api/transaction-formats/transaction-results/tec-codes.md
View File

@@ -4,7 +4,7 @@ These codes indicate that the transaction failed, but it was applied to a ledger
For the most part, transactions with `tec` codes take no action other than to destroy the XRP paid as a [transaction cost](transaction-cost.html), but there are some exceptions. As an exception, a transaction that results in `tecOVERSIZE` still cleans up some [unfunded offers](#lifecycle-of-an-offer). Always look at the [transaction metadata](#understanding-transaction-metadata) to see precisely what a transaction did.
**Caution:** A transaction that provisionally failed with a `tec` code may still succeed or fail with a different code after being reapplied. The result is final when it appears in a validated ledger version. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
**Caution:** A transaction that provisionally failed with a `tec` code may still succeed or fail with a different code after being reapplied. The result is final when it appears in a validated ledger version. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](reliable-transaction-submission.html).
| Code | Value | Explanation |
|:---------------------------|:------|:----------------------------------------|

2
content/references/rippled-api/transaction-formats/transaction-results/tef-codes.md
View File

@@ -2,7 +2,7 @@
These codes indicate that the transaction failed and was not included in a ledger, but the transaction could have succeeded in some theoretical ledger. Typically this means that the transaction can no longer succeed in any future ledger. They have numerical values in the range -199 to -100. The exact code for any given error is subject to change, so don't rely on it.
**Caution:** Transactions with `tef` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
**Caution:** Transactions with `tef` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](reliable-transaction-submission.html).
| Code | Explanation |
|:-----------------------|:----------------------------------------------------|

4
content/references/rippled-api/transaction-formats/transaction-results/tel-codes.md
View File

@@ -2,7 +2,7 @@
These codes indicate an error in the local server processing the transaction; it is possible that another server with a different configuration or load level could process the transaction successfully. They have numerical values in the range -399 to -300. The exact code for any given error is subject to change, so don't rely on it.
**Caution:** Transactions with `tel` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
**Caution:** Transactions with `tel` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](reliable-transaction-submission.html).
| Code | Explanation |
|:----------------------|:-----------------------------------------------------|
@@ -18,7 +18,7 @@ These codes indicate an error in the local server processing the transaction; it
| `telFAILED_PROCESSING` | An unspecified error occurred when processing the transaction. |
| `telINSUF_FEE_P` | The `Fee` from the transaction is not high enough to meet the server's current [transaction cost](transaction-cost.html) requirement, which is derived from its load level. |
| `telLOCAL_ERROR` | Unspecified local error. |
| `telNO_DST`_`PARTIAL` | The transaction is an XRP payment that would fund a new account, but the [tfPartialPayment flag](#partial-payments) was enabled. This is disallowed. |
| `telNO_DST`_`PARTIAL` | The transaction is an XRP payment that would fund a new account, but the [tfPartialPayment flag](partial-payments.html) was enabled. This is disallowed. |
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

2
content/references/rippled-api/transaction-formats/transaction-results/tem-codes.md
View File

@@ -19,7 +19,7 @@ These codes indicate that the transaction was malformed, and cannot succeed acco
| `temBAD_SEND_XRP_LIMIT` | The [Payment transaction][] used the [tfLimitQuality](payment.html#limit-quality) flag in a direct XRP-to-XRP payment, even though XRP-to-XRP payments do not involve any conversions. |
| `temBAD_SEND_XRP_MAX` | The [Payment transaction][] included a `SendMax` field in a direct XRP-to-XRP payment, even though sending XRP should never require SendMax. (XRP is only valid in SendMax if the destination `Amount` is not XRP.) |
| `temBAD_SEND_XRP_NO_DIRECT` | The [Payment transaction][] used the [tfNoDirectRipple](payment.html#payment-flags) flag for a direct XRP-to-XRP payment, even though XRP-to-XRP payments are always direct. |
| `temBAD_SEND_XRP_PARTIAL` | The [Payment transaction][] used the [tfPartialPayment](#partial-payments) flag for a direct XRP-to-XRP payment, even though XRP-to-XRP payments should always deliver the full amount. |
| `temBAD_SEND_XRP_PARTIAL` | The [Payment transaction][] used the [tfPartialPayment](partial-payments.html) flag for a direct XRP-to-XRP payment, even though XRP-to-XRP payments should always deliver the full amount. |
| `temBAD_SEND_XRP_PATHS` | The [Payment transaction][] included `Paths` while sending XRP, even though XRP-to-XRP payments should always be direct. |
| `temBAD_SEQUENCE` | The transaction is references a sequence number that is higher than its own `Sequence` number, for example trying to cancel an offer that would have to be placed after the transaction that cancels it. |
| `temBAD_SIGNATURE` | The signature to authorize this transaction is either missing, or formed in a way that is not a properly-formed signature. (See [tecNO_PERMISSION](#tec-codes) for the case where the signature is properly formed, but not authorized for this account.) |

2
content/references/rippled-api/transaction-formats/transaction-results/ter-codes.md
View File

@@ -2,7 +2,7 @@
These codes indicate that the transaction failed, but it could apply successfully in the future, usually if some other hypothetical transaction applies first. They have numerical values in the range -99 to -1. The exact code for any given error is subject to change, so don't rely on it.
**Caution:** Transactions with `ter` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](tutorial-reliable-transaction-submission.html).
**Caution:** Transactions with `ter` codes are not applied to ledgers and cannot cause any changes to the XRP Ledger state. However, a transaction that provisionally failed may still succeed or fail with a different code after being reapplied. For more information, see [Finality of Results](finality-of-results.html) and [Reliable Transaction Submission](reliable-transaction-submission.html).
| Code | Explanation |
|:-----------------|:----------------------------------------------------------|

2
content/references/rippled-api/transaction-formats/transaction-types/checkcancel.md
View File

@@ -20,7 +20,7 @@ Cancels an unredeemed Check, removing it from the ledger without sending any mon
<!--{# fix md highlighting_ #}-->
In addition to the [common fields](#common-fields), a CheckCancel transaction has the following:
In addition to the [common fields](transaction-common-fields.html), a CheckCancel transaction has the following:
| Field | JSON Type | [Internal Type][] | Description |
|:------------|:----------|:------------------|:-------------------------------|

2
content/references/rippled-api/transaction-formats/transaction-types/checkcash.md
View File

@@ -23,7 +23,7 @@ Since the funds for a check are not guaranteed, redeeming a Check can fail becau
<!--{# fix md highlighting_ #}-->
In addition to the [common fields](#common-fields), a CheckCash transaction has the following:
In addition to the [common fields](transaction-common-fields.html), a CheckCash transaction has the following:
| Field | JSON Type | [Internal Type][] | Description |
|:------------|:----------|:------------------|:-------------------------------|

2
content/references/rippled-api/transaction-formats/transaction-types/checkcreate.md
View File

@@ -24,7 +24,7 @@ Create a Check object in the ledger, which is a deferred payment that can be cas
<!--{# fix md highlighting_ #}-->
In addition to the [common fields](#common-fields), a CheckCreate transaction has the following:
In addition to the [common fields](transaction-common-fields.html), a CheckCreate transaction has the following:
| Field | JSON Type | [Internal Type][] | Description |
|:-----------------|:--------------------|:------------------|:----------------|

6
content/references/rippled-api/transaction-formats/transaction-types/payment.md
View File

@@ -35,7 +35,7 @@ Payments are also the only way to [create accounts](#creating-accounts).
| InvoiceID | String | Hash256 | _(Optional)_ Arbitrary 256-bit hash representing a specific reason or identifier for this payment. |
| Paths | Array of path arrays | PathSet | (Optional, auto-fillable) Array of [payment paths](paths.html) to be used for this transaction. Must be omitted for XRP-to-XRP transactions. |
| SendMax | [Currency Amount][] | Amount | _(Optional)_ Highest amount of source currency this transaction is allowed to cost, including [transfer fees](transfer-fees.html), exchange rates, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). Does not include the [XRP destroyed as a cost for submitting the transaction](#transaction-cost). For non-XRP amounts, the nested field names MUST be lower-case. Must be supplied for cross-currency/cross-issue payments. Must be omitted for XRP-to-XRP payments. |
| DeliverMin | [Currency Amount][] | Amount | _(Optional)_ Minimum amount of destination currency this transaction should deliver. Only valid if this is a [partial payment](#partial-payments). For non-XRP amounts, the nested field names are lower-case. |
| DeliverMin | [Currency Amount][] | Amount | _(Optional)_ Minimum amount of destination currency this transaction should deliver. Only valid if this is a [partial payment](partial-payments.html). For non-XRP amounts, the nested field names are lower-case. |
## Special issuer Values for SendMax and Amount
@@ -73,7 +73,7 @@ Transactions of the Payment type support additional values in the [`Flags` field
| Flag Name | Hex Value | Decimal Value | Description |
|:-----------------|:-----------|:--------------|:-----------------------------|
| tfNoDirectRipple | 0x00010000 | 65536 | Do not use the default path; only use paths included in the `Paths` field. This is intended to force the transaction to take arbitrage opportunities. Most clients do not need this. |
| tfPartialPayment | 0x00020000 | 131072 | If the specified `Amount` cannot be sent without spending more than `SendMax`, reduce the received amount instead of failing outright. See [Partial Payments](#partial-payments) for more details. |
| tfPartialPayment | 0x00020000 | 131072 | If the specified `Amount` cannot be sent without spending more than `SendMax`, reduce the received amount instead of failing outright. See [Partial Payments](partial-payments.html) for more details. |
| tfLimitQuality | 0x00040000 | 262144 | Only take paths where all the conversions have an input:output ratio that is equal or better than the ratio of `Amount`:`SendMax`. See [Limit Quality](#limit-quality) for details. |
## Partial Payments
@@ -99,7 +99,7 @@ Consider the following example. If I am trying to send you 100 Chinese Yuan (`Am
Without the tfLimitQuality flag set, this transaction would succeed, because the $17 it costs me is within my specified `SendMax`. However, with the tfLimitQuality flag enabled, the transaction would fail instead, because the path to take the second offer has a quality of `2.5`, which is worse than the limit quality of `5`.
The tfLimitQuality flag is most useful when combined with [partial payments](#partial-payments). When both *tfPartialPayment* and *tfLimitQuality* are set on a transaction, then the transaction delivers as much of the destination `Amount` as it can, without using any conversions that are worse than the limit quality.
The tfLimitQuality flag is most useful when combined with [partial payments](partial-payments.html). When both *tfPartialPayment* and *tfLimitQuality* are set on a transaction, then the transaction delivers as much of the destination `Amount` as it can, without using any conversions that are worse than the limit quality.
In the above example with a ¥95/$15 offer and a ¥5/$2 offer, the situation is different if my transaction has both tfPartialPayment and tfLimitQuality enabled. If we keep my `SendMax` of 20 USD and a destination `Amount` of 100 CNY, then the limit quality is still `5`. However, because I am doing a partial payment, the transaction sends as much as it can instead of failing if the full destination amount cannot be sent. This means that my transaction consumes the ¥95/$15 offer, whose quality is about `6.3`, but it rejects the ¥5/$2 offer because that offer's quality of `2.5` is worse than the quality limit of `5`. In the end, my transaction only delivers ¥95 instead of the full ¥100, but it avoids wasting money on poor exchange rates.