Serialization: Add PathSet diagram, fix typos

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

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>

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):
| Type Name | Type Code | Variable-Length? | Description |
|:--------------|:----------|:-----------------|:------------------------------|
| 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). |
| 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). |
| [UInt64][] | 3 | No | A 64-bit unsigned integer. This type does not appear in transaction instructions, but several 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. |
| Type Name | Type Code | Variable-Length? | Description |
|:------------|:----------|:-----------------|:--------------------------------|
| 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). |
| 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). |
| [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. |
### 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).
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
- `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:
@@ -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).
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
[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.
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' %}

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB