Description of an Audit Correction
A failed audit, in this context, means that the initial hashes did not match. This will trigger further messages to find and correct the mistakes. Once all mistakes are corrected, the final message indicates success for that prefix.
Please Note: If the audit corrections take longer than an hour, client token might get expired. In such an event, the client should refresh the token and continue with the audit processing.
The diagram below shows how the RouteLink® Client's DB is corrected when a failure is detected:Disclaimer: Any images in this article are intended to be used as a guide for educational purposes only and they may differ slightly from the Production Environment.
The following steps help explain the above diagram:
- The audit event that is downloaded to start the prefix audit, is JSON: { "action":"audit_request", "prefix":"800", "id": 10000 }
- The client sends the hash for all CRNs starting with 800 in JSON similar to: { "action":"audit_reply", "prefix":"800", "sha1": "acb2237d0679ca88db6464eac60da96345513964" } The 40 character SHA1 hash above is an example and its algorithm is described later.
- The RouteLink Server performs the same hash algorithm for the 800 prefix on its Audit Snapshot DB.
- The RouteLink Server compares the 2 hashes. If they don't match, then the server begins to traverse the CRN "tree". Each successive digit of a 10-digit CRN is a node in the tree with 10 branches. The RouteLink Server asks the RouteLink Client for hashes like "8000", "8001", … "8009" using more "audit" messages containing more digits. When the server receives each response from the RouteLink Client, it compares the hash to its own hash for that node. If the DBs are nearly the same, but not exact, almost all hashes will match. The RouteLink Server does not pursue any branches that match, so elimination of large portions of the tree happens quickly. The RouteLink Server continues to audit only the failed hashes. Each time the RouteLink Server requests an audit, it provides the starting CRN value to hash. A deeper example of a starting value would be "80055", thus telling the RouteLink Client to calculate the hash using an SQL statement "where" clause similar to "WHERE (crn LIKE '80055%')".
-
If the hash for a fully qualified, 10-digit CRN (a "leaf") fails to match, the server adds a new download event to the event queue for that CRN. The event always contains all the information (crn, ror, sha1, and full cpr). The RouteLink Client downloads the event, as a normal part of its download of CRN data.
- When the RouteLink Server traverses all failed hash branches for the prefix, a success message will be returned: { "result" : "success" }
The RouteLink Server is solely responsible for directing the audit and traversing the CRN tree. The RouteLink Client simply responds to the audit requests with the hash of the requested CRN, which could include any number of digits up to a full 10-digit number. The RouteLink Client need not be aware of the tree traversal process, as it could change.