Tx history chaining: done with 1st draft of code

This commit is contained in:
mDuo13
2019-05-15 19:39:59 -07:00
parent 513d8fe8ec
commit d19c8ffdf8
2 changed files with 45 additions and 11 deletions

View File

@@ -2,7 +2,7 @@
This tutorial shows how to monitor for incoming payments using the [WebSocket `rippled` API](rippled-api.html). Since all XRP Ledger transactions are public, anyone can monitor incoming payments to any address.
WebSocket follows a model where the client and server establish one connection, then send messages both ways through the same connection, which remains open until explicitly closed (or until the connection fails). This is in contrast to the HTTP-based API model (including JSON-RPC and RESTful APIs), where the client opens and closes a new connection for each request[¹](#footnote-1)<a id="from-footnote-1"></a>.
WebSocket follows a model where the client and server establish one connection, then send messages both ways through the same connection, which remains open until explicitly closed (or until the connection fails). This is in contrast to the HTTP-based API model (including JSON-RPC and RESTful APIs), where the client opens and closes a new connection for each request.[¹](#footnote-1)<a id="from-footnote-1"></a>
**Tip:** The examples in this page use JavaScript so that the examples can run natively in a web browser. If you are developing in JavaScript, you can also use the [RippleAPI library for JavaScript](https://developers.ripple.com/rippleapi-reference.html) to simplify some tasks. This tutorial shows how to monitor for transactions _without_ using RippleAPI so that you can translate the steps to other programming languages that don't have RippleAPI.
@@ -459,7 +459,7 @@ To look for gaps that might affect a transaction's XRP balance, you can use this
1. When you first connect, establish a starting point by calling the [account_info method][] to look up the latest `PreviousTxnID` value and save it.
2. Whenever you get a new transaction, look through the modified ledger objects to see if the account in question was modified. This is the same as how you read the account's balance changes. Specifically, you should look in the `meta.AffectedNodes` array for a `ModifiedNode` object of ledger entry type `AccountRoot`, where the `FinalFields.Account` value matches the address of the account.
- If no such object exists, the account was not directly modified by the transaction. Since the XRP Ledger tracks XRP balances in this object, you know that the account's XRP balance did not change[²](#footnote-2) <a id="from-footnote-2"></a>. (The `accounts` stream also reports several types of transactions that _indirectly_ affect an account without modifying the `AccountRoot` object itself.)
- If no such object exists, the account was not directly modified by the transaction. Since the XRP Ledger tracks XRP balances in this object, you know that the account's XRP balance did not change.[²](#footnote-2) <a id="from-footnote-2"></a> (The `accounts` stream also reports several types of transactions that _indirectly_ affect an account without modifying the `AccountRoot` object itself.)
3. If the account _was_ modified, compare the `ModifiedNode` object's `PreviousTxnID` field to the value you have saved.
- If they match, you did not miss any changes to that account's XRP balance. Update your saved `PreviousTxnID` to the identifying hash of the new transaction (the `transaction.hash` field in `transaction`-type subscription messages). **Continue processing transactions normally.**
4. If the account was modified _and_ the `PreviousTxnID` value did not match the hash you were expecting, use the [tx method][] to look up the missing transaction, using the `PreviousTxnID` value from the new transaction to identify the missing transaction. We'll call this the "gap" transaction.