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

Serialization: Add PathSet diagram, fix typos

Browse Source
This commit is contained in:
mDuo13
2018-11-28 19:35:50 -08:00
parent d5d48d092d
commit a1bfc274d5
3 changed files with 342 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

323
content/_img-sources/serialization-pathset.uxf Normal file
View File

@@ -0,0 +1,323 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.2">
<zoom_level>10</zoom_level>
<element>
<id>UMLPackage</id>
<coordinates>
<x>40</x>
<y>40</y>
<w>650</w>
<h>70</h>
</coordinates>
<panel_attributes>PathSet</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>50</x>
<y>210</y>
<w>40</w>
<h>30</h>
</coordinates>
<panel_attributes>0x30</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>200</x>
<y>70</y>
<w>40</w>
<h>30</h>
</coordinates>
<panel_attributes>0xff</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>50</x>
<y>70</y>
<w>150</w>
<h>30</h>
</coordinates>
<panel_attributes>First path</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>430</x>
<y>230</y>
<w>60</w>
<h>60</h>
</coordinates>
<panel_attributes>lt=&lt;&lt;-</panel_attributes>
<additional_attributes>10.0;10.0;10.0;40.0;40.0;40.0</additional_attributes>
</element>
<element>
<id>Text</id>
<coordinates>
<x>470</x>
<y>260</y>
<w>260</w>
<h>30</h>
</coordinates>
<panel_attributes>Path step's type byte</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>250</x>
<y>70</y>
<w>150</w>
<h>30</h>
</coordinates>
<panel_attributes>Second path</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>400</x>
<y>70</y>
<w>40</w>
<h>30</h>
</coordinates>
<panel_attributes>0xff</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>450</x>
<y>70</y>
<w>40</w>
<h>30</h>
</coordinates>
<panel_attributes>...</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>490</x>
<y>70</y>
<w>150</w>
<h>30</h>
</coordinates>
<panel_attributes>Last path</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>640</x>
<y>70</y>
<w>40</w>
<h>30</h>
</coordinates>
<panel_attributes>0x00</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLPackage</id>
<coordinates>
<x>40</x>
<y>180</y>
<w>650</w>
<h>70</h>
</coordinates>
<panel_attributes>Path</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>30</x>
<y>90</y>
<w>40</w>
<h>110</h>
</coordinates>
<panel_attributes>lt=..</panel_attributes>
<additional_attributes>10.0;90.0;20.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>190</x>
<y>90</y>
<w>520</w>
<h>130</h>
</coordinates>
<panel_attributes>lt=..</panel_attributes>
<additional_attributes>500.0;110.0;10.0;10.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>90</x>
<y>210</y>
<w>160</w>
<h>30</h>
</coordinates>
<panel_attributes>Currency (160 bits)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>250</x>
<y>210</y>
<w>160</w>
<h>30</h>
</coordinates>
<panel_attributes>Issuer (160 bits)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>420</x>
<y>210</y>
<w>40</w>
<h>30</h>
</coordinates>
<panel_attributes>0x01</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>460</x>
<y>210</y>
<w>160</w>
<h>30</h>
</coordinates>
<panel_attributes>Account (160 bits)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>640</x>
<y>210</y>
<w>40</w>
<h>30</h>
</coordinates>
<panel_attributes>...</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>40</x>
<y>250</y>
<w>390</w>
<h>50</h>
</coordinates>
<panel_attributes>lt=.</panel_attributes>
<additional_attributes>10.0;10.0;10.0;30.0;370.0;30.0;370.0;10.0</additional_attributes>
</element>
<element>
<id>Text</id>
<coordinates>
<x>80</x>
<y>290</y>
<w>260</w>
<h>30</h>
</coordinates>
<panel_attributes>Path step</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>450</x>
<y>90</y>
<w>60</w>
<h>60</h>
</coordinates>
<panel_attributes>lt=&lt;&lt;-</panel_attributes>
<additional_attributes>10.0;10.0;10.0;40.0;40.0;40.0</additional_attributes>
</element>
<element>
<id>Text</id>
<coordinates>
<x>490</x>
<y>120</y>
<w>180</w>
<h>30</h>
</coordinates>
<panel_attributes>More paths</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>490</x>
<y>300</y>
<w>130</w>
<h>30</h>
</coordinates>
<panel_attributes>More path steps</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>610</x>
<y>230</y>
<w>60</w>
<h>100</h>
</coordinates>
<panel_attributes>lt=&lt;&lt;-</panel_attributes>
<additional_attributes>40.0;10.0;40.0;80.0;10.0;80.0</additional_attributes>
</element>
<element>
<id>Text</id>
<coordinates>
<x>460</x>
<y>20</y>
<w>180</w>
<h>30</h>
</coordinates>
<panel_attributes>"Continue" byte</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>410</x>
<y>20</y>
<w>60</w>
<h>70</h>
</coordinates>
<panel_attributes>lt=&lt;&lt;-</panel_attributes>
<additional_attributes>10.0;50.0;10.0;10.0;40.0;10.0</additional_attributes>
</element>
<element>
<id>Text</id>
<coordinates>
<x>640</x>
<y>20</y>
<w>100</w>
<h>30</h>
</coordinates>
<panel_attributes>"End" byte</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>670</x>
<y>40</y>
<w>60</w>
<h>60</h>
</coordinates>
<panel_attributes>lt=&lt;&lt;-</panel_attributes>
<additional_attributes>10.0;40.0;40.0;40.0;40.0;10.0</additional_attributes>
</element>
</diagram>

29
content/references/rippled-api/api-conventions/serialization.md
View File

@@ -136,14 +136,14 @@ Transaction instructions may contain fields of any of the following types:
In addition to all of the above field types, the following types may appear in other contexts, such as [ledger objects](ledger-object-types.html) and [transaction metadata](transaction-metadata.html): In addition to all of the above field types, the following types may appear in other contexts, such as [ledger objects](ledger-object-types.html) and [transaction metadata](transaction-metadata.html):
| Type Name | Type Code | Variable-Length? | Description | | Type Name | Type Code | Variable-Length? | Description |
|:--------------|:----------|:-----------------|:------------------------------| |:------------|:----------|:-----------------|:--------------------------------|
| Transaction | 10001 | No | A "high-level" type containing an entire [transaction](transaction-formats.html). | | Transaction | 10001 | No | A "high-level" type containing an entire [transaction](transaction-formats.html). |
| LedgerEntry | 10002 | No | A "high-level" type containing an entire [ledger object](ledger-object-types.html). | | LedgerEntry | 10002 | No | A "high-level" type containing an entire [ledger object](ledger-object-types.html). |
| Validation | 10003 | No | A "high-level" type used in peer-to-peer communications to represent a validation vote in the [consensus process](consensus.html). | | Validation | 10003 | No | A "high-level" type used in peer-to-peer communications to represent a validation vote in the [consensus process](consensus.html). |
| Metadata | 10004 | No | A "high-level" type containing [metadata for one transaction](transaction-metadata.html). | | Metadata | 10004 | No | A "high-level" type containing [metadata for one transaction](transaction-metadata.html). |
| [UInt64][] | 3 | No | A 64-bit unsigned integer. This type does not appear in transaction instructions, but several use fields of this type. | | [UInt64][] | 3 | No | A 64-bit unsigned integer. This type does not appear in transaction instructions, but several ledger objects use fields of this type. |
| [Vector256][] | 19 | Yes | This type does not appear in transaction instructions, but the [Amendments ledger object](amendments-object.html)'s `Amendments` field uses this to represent which [amendments](amendments.html) are currently enabled. | | Vector256 | 19 | Yes | This type does not appear in transaction instructions, but the [Amendments ledger object](amendments-object.html)'s `Amendments` field uses this to represent which [amendments](amendments.html) are currently enabled. |
### AccountID Fields ### AccountID Fields
@@ -219,12 +219,12 @@ The following example shows the serialization format for an object (a single `Me
The `Paths` field of a cross-currency [Payment transaction][] is a "PathSet", represented in JSON as an array of arrays. For more information on what paths are used for, see [Paths](paths.html). The `Paths` field of a cross-currency [Payment transaction][] is a "PathSet", represented in JSON as an array of arrays. For more information on what paths are used for, see [Paths](paths.html).
A PathSet is serialized as each individual path in sequence. Each complete path is followed by a byte that indicates what comes next: A PathSet is serialized as **one or more** individual paths in sequence. Each complete path is followed by a byte that indicates what comes next:
- `0xff` indicates another path follows - `0xff` indicates another path follows
- `0x00` indicates the end of the PathSet - `0x00` indicates the end of the PathSet
Each path consists of a set of path steps in order. Each step starts with a **type** byte, followed by one or more fields describing the path step. The type indicates which fields are present in that path step through bitwise flags. (For example, the value `0x11` indicates changing both currency and issuer.) If more than one field is present, the fields are always placed in a specific order. Each path consists of **one or more** path steps in order. Each step starts with a **type** byte, followed by one or more fields describing the path step. The type indicates which fields are present in that path step through bitwise flags. (For example, the value `0x30` indicates changing both currency and issuer.) If more than one field is present, the fields are always placed in a specific order.
The following table describes the possible fields and the bitwise flags to set in the type byte to indicate them: The following table describes the possible fields and the bitwise flags to set in the type byte to indicate them:
@@ -242,6 +242,10 @@ The AccountIDs in the `account` and `issuer` fields are presented _without_ a va
Each step is followed directly by the next step of the path. As described above, last step of a path is followed by either `0xff` (if another path follows) or `0x00` (if this ends the last path). Each step is followed directly by the next step of the path. As described above, last step of a path is followed by either `0xff` (if another path follows) or `0x00` (if this ends the last path).
The following example shows the serialization format for a PathSet:
![PathSet is several paths each followed by a continue or end byte; each path is several path steps consisting of a type byte and one or more 160-bit fields based on the type byte](img/serialization-pathset.png)
### UInt Fields ### UInt Fields
[UInt8]: #uint-fields [UInt8]: #uint-fields
@@ -254,3 +258,8 @@ The XRP Ledger has several unsigned integer types: UInt8, UInt16, UInt32, and UI
When representing these fields in JSON objects, most are represented as JSON numbers by default. One exception is UInt64, which is represented as a string because some JSON decoders may try to represent these integers as 64-bit "double precision" floating point numbers, which cannot represent all distinct UInt64 values with full precision. When representing these fields in JSON objects, most are represented as JSON numbers by default. One exception is UInt64, which is represented as a string because some JSON decoders may try to represent these integers as 64-bit "double precision" floating point numbers, which cannot represent all distinct UInt64 values with full precision.
Another special case is the `TransactionType` field. In JSON, this field is conventionally represented as a string with the name of the transaction type, but in binary, this field is a UInt16. The `TRANSACTION_TYPES` object in the [definitions file](#definitions-file) maps these strings to specific numeric values. Another special case is the `TransactionType` field. In JSON, this field is conventionally represented as a string with the name of the transaction type, but in binary, this field is a UInt16. The `TRANSACTION_TYPES` object in the [definitions file](#definitions-file) maps these strings to specific numeric values.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

BIN
img/serialization-pathset.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB