You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/core-token.md
+10-13Lines changed: 10 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,20 +42,11 @@ token:
42
42
# b) The transaction will reach finality shortly, so we append a listener and wait for a timeout. If the listener reaches timeout, we proceed to step c.
43
43
# c) The transaction reached finality long ago, so we query the whole ledger for this specific transaction. If the query returns no result, we proceed to step d.
44
44
# d) The transaction will reach finality at some point beyond the timeout or never, so we return Unknown. Then it is up to the client to either append another listener or accept that the transaction will never reach finality.
45
-
# committer: The manager subscribes to the commit pipeline and receives all finalized transactions.
46
-
# If we subscribe for a transaction that hasn't been finalized yet, we will get notified once it reaches the commit pipeline.
47
-
# For listeners that haven't been invoked yet, either the transaction hasn't been finalized or it was finalized before we subscribed.
48
-
# For this reason, there is a periodic polling period (1s) that queries all txIDs for which there is a pending listener and invokes the listeners for the ones found.
49
-
# Once we get notified about finality, we try (repeatedly) to fetch the additional tx information needed from the vault (e.g., transactionRequest).
50
-
# If we work without replicas, there is no need to try more than once to fetch the additional tx information, because the finality notification and vault update happen in sync.
51
-
# It is only needed in case we have replicas, where another replica may have updated the vault shortly before.
45
+
# notification: The manager is notified about finality events via a notification service (e.g. for FabricX).
46
+
# When a new notification arrives, an event is added to a queue for asynchronous processing.
47
+
# When a client subscribes to the manager for a specific transaction, we perform an immediate query to check its status.
48
+
# The field can also be left empty. In that case, the default option will be used depending on the network type each TMS refers to.
52
49
type: delivery
53
-
# Only applicable when type = 'committer'
54
-
committer:
55
-
# maxRetries is the number of times we try to fetch the additional tx information from the vault.
56
-
maxRetries: 3
57
-
# retryWaitDuration is the duration to wait before retrying.
58
-
retryWaitDuration: 5s
59
50
# Only applicable when type = 'delivery'
60
51
delivery:
61
52
# mapperParallelism is the number of goroutines that process incoming transactions in parallel. Defaults to 1.
@@ -76,6 +67,12 @@ token:
76
67
# If the timeout is not set, then the listener will never be evicted and we will never proceed to step c.
77
68
# We will wait forever for the transaction to return (as is done for the 'committer' type).
78
69
listenerTimeout: 10s
70
+
# Only applicable when type = 'notification'
71
+
notification:
72
+
# workers is the number of goroutines that process events in parallel. Defaults to 10.
73
+
workers: 10
74
+
# queueSize is the size of the event buffer. Defaults to 1000.
75
+
queueSize: 1000
79
76
tms:
80
77
mytms: # unique name of this token management system
81
78
network: default # the name of the network this TMS refers to (Fabric, etc.)
Copy file name to clipboardExpand all lines: docs/services/network.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
##The Network Service
1
+
# The Network Service
2
2
3
3
The `network` service, located under `token/services/network`, provides other services with a consistent and predictable interface to the backend (e.g., Fabric).
4
4
Internally, the network service mirrors the structure of the Token API, consisting of a `Provider` of network instances and the `Network` instances themselves.
@@ -7,6 +7,8 @@ The network service architecture is depicted below:
The Fabric-based network implementation utilizes the Fabric Smart Client for configuration and operations, including chaincode queries and transaction broadcasting.
11
13
12
14
During bootstrap, the Token SDK processes the TMS defined in the configuration.
// LookupTransferMetadataKey searches for a transfer metadata key containing the passed sub-key starting from the passed transaction id in the given namespace.
85
82
// The operation gets canceled if the passed timeout elapses or, if stopOnLastTx is true, when the last transaction in the vault is reached.
0 commit comments