Network:
PartyA, PartyB, PartyC, Notary
Scenario:
PartyB’s node is put into draining mode.
PartyA performs a transaction where PartyB and PartyC are
participants (not signers)
Outcome:
PartyA completes the transaction, gets the notary’s signature and
saves the state in its vault.
PartyB will not be informed of transaction (expected)
PartyC will not be informed of the transaction (surprise!)
Learning:
I assume because PartyC is listed after PartyB in getParticipants() it has to wait until PartyB is back online before it will receive the transaction. This is unfortunate because PartyC gets punished because PartyB’s node is down.
Question:
Is this just a limitation of the open source version of Corda? Would Corda Enterprise behave the same way?
Thoughts:
It may be necessary to clearly inform the users of your CorDapp about this phenomenon because it creates a condition of asymmetric information that is caused by some other node on the network.
It is a limitation of Corda Open Source. The FinalityFlow of Corda Enterprise (up until 4.x) sends the transaction - after notarisation - to all the peers and resolution is performed in parallel for increased performance. In Corda Open Source it is done in sequence.
Related
Does Corda node send messages to only the participant nodes or to all nodes of the network/zone?
Transactions are shared only between participants (and external observers who are added to the transaction on purpose). From the Corda whitepaper (downloadable from here):
A transaction between a group of parties is visible only to them, and
to those whose own view of the ledger in the future may depend on verifying
the validity of this transaction. [...] The foundational object in our concept is a state object, which is a digital document which records the existence, content and current state of an agreement between two or more parties. It is intended to be shared only with those who have a legitimate reason to see it.
And from Corda training doc:
According to R3, "On the grounds of confidentiality, we reject the notion that data should be broadcast to all participants or cumbersome pre-defined groups." Corda communications are peer-to-peer on a "need-to-know" basis without broadcast. Need-to-know is quite different from Ethereum's public broadcast, Quorum's private transactions or Hyperledger Fabric's network "channels" approach. In a Corda network, if Alice transacts with Bob, then only Alice and Bob need to know about it, and possibly a regulator.
In our Corda network we work with Accounts. We have a network with well-defined nodes.
To show the problem, imagine 3 nodes, PartyA, PartyB and Notary.
We created the accounts (AccountA for example) on PartyA. We have flows that can be executed at PartyB that has AccountA as a participant in the transaction.
Now imagine that PartyA is down for any reason, or communication between nodes is not available.
When I request a new AccountA key for PartyA, the flow gets stuck trying to communicate and does not return any exception. This happens in any situation that tries to communicate with another node, when running a CollectSignaturesFlow or ShareStateAndSyncAccounts to share account states for example.
The question is, is there any configuration or mechanism to return an exception in those cases where it is unable to communicate with another node?
Timeouts can be handled differently depending on where you need to manage it.
There is the flowTimeout:
When a flow implementing the TimedFlow interface and setting the
isTimeoutEnabled flag does not complete within a defined elapsed time,
it is restarted from the initial checkpoint.
Currently only used for notarisation requests with clustered notaries
Or otherwise it can be done programmatically in your flow. I suggest you to take a look to this part of the Corda documentation (Concurrency, Locking and Waiting) where there are many suggestions that you could try to implement.
I am trying to run Example Cordapp in two different VMs. With Notary and PartyC in 1st server and PartyA and PartyB in 2nd server.
I followed the steps here, Corda nodes: how to connect two independent pc as two nodes
In the conf file of,
Notary and PartyC - I have edited the P2P address
PartyA and PartyB - I have edited the P2P address
With the above conf files, I ran the Network Bootstrapper jar in server 1 and copied the folders PartyA and PartyB in another cordapp example to server 2 and started the Notary and Parties 1 by 1 respectively in the corresponding VMs.
All nodes started succesfully and when I try to execute a IOU flow from PartyC(in server 1) to PartyB(in server2), it is pausing at Collecting counterparties signature step without proceeding further. Below is what I see in PartyC's Console,
enter image description here
The flow getting stuck in CollectSignatureFlow means the initiating node is not able to get a response from the counterparty node.
The CollectSignatureFlow internally establishes a session with the counterparty node and shares the transaction data to get the signature.
Since you have nodes in separate machines, they are probably not able to see each other. Generally, if nodes are hosted in a separate VM, the VM's must have public IPs or must be in a network where they are able to see each other.
If input states are consumed in a transaction then a notary is required. As per the documentation, the same notary that signed the original unconsumed inputs should sign the transaction which will consume these states to create an output state.
If there is a pool of notaries then how to search for the original notary to sign the new transaction?
Available docs/api explain how to get a new notary which is usually getFirstNotary/getAvailableNotary.
Cheers
There are two aspects for notaries to keep in mind:
High Availability: the notary pool provides replicated instances of the notary to ensure that its notary services are consistently available.
Notary Identity: the X500 identity of the notary that is registered onto the Corda Network.
When speaking about a notary on a Corda Network we generally refer to its identity. The way in which a notary is deployed (aka the notary pool) is an implementation detail. Each notary identity that can be used on the Corda Network generally represents a different consensus protocol and/or a different business organization which operates the notary.
When you're using the notary selection API you're selecting which notary identity to use (aka consensus/organization) as opposed to any implementation detail of how the notary is deployed.
Notary selection comes from the network map and you can choose from the list of whitelisted notaries that exist on the Corda Network. Here's a primitive selection that simply gets the first notary: final Party notary = getServiceHub().getNetworkMapCache().getNotaryIdentities().get(0) You can customize this as you see fit to choose a notary on a transaction by transaction basis.
I set up a network with 2 normal Node (NodeA and NodeB) and 1 Notary. If NodeA has shut down and lose apart of its database (about current states), how can We ensure that the network may run as well. And how does NodeA restore this data that loss? (Can Enterprise Corda Version help me in this case?)
When a database admin deletes your data, Corda will not be able to help you. You are responsible for your own database. You need to ensure that only authorized parties have permissions to access the database.
Let's say that PartyA now does not have latest states/ data for your custom tables. In this scenario, PartyA can request PartyB for this missing state if PartyB was also a participant to the state. It depends on PartyB whether to share this state to PartyA.
There is a built in flow to send the state from one party to other
SendStateAndRefFlow(otherSideSession: FlowSession, stateAndRefs: List<StateAndRef<*>>)