Advanced node selection logic for transaction submission

[anvabr]

Problem

All Dapps need a reliable and fast interface to sumbit transactions into Hedera network (like official testnet, or mainnet). For PROD deployments these Dapp teams would probably deploy their own node or may be even set of RPC nodes. The most appropriate logic for node selections thus would be:

• use 'our own' node or nodes (in some preference sequence)
• if none of the above work properly (failed to sumbit txs, or slow responses) switch to 'other' - may be external - nodes in some sequence.

See for example a practical requirement hashgraph/guardian#1266.

Solution

Hedera SDK seems to allow two modes: to pick the most suitable node to submit transactions through, or 'any' of the selection of nodes. This works for most of the use-cases, however as per above in many situations a more advanced logic is required, e.g. at least the ability to specify a desired node (for commercial, performance, or SLAs reasons).

This logic can be implemented in the upper layers of the stack (in the application), however since it's generic - many Dapps are likely to require it - it seems a more appropriate place for it is in the SDK (as it is currently, but needs to be more advanced).

Alternatives

No response

[ochikov]

Thank you for the proposed enhancement. We are going to think about a possible solution and to put it in some of our incoming planning sessions.

[anvabr]

Hi @ochikov, just reaching out to see if there's been any progress on this? Any ideas on the possible approaches, fixes, improvements please?

[ochikov]

Hello @anvabr, there is a slight change in version 2.20.0 of the SDK. We've improved the node selection algorithm as well as added new Proxies for WEB usage. How the algorithm was working:

• Get a node and tried the first IP (of many). If failed, marked it as unhealthy
  Now we are trying all the IPs of the node, and then switching to another node. Also, the trying times are smaller.
  Right now we are happy with the results. You can provide your own list of networks using Client.forNetwork(nodes) where you can specify nodes like:

let nodes = {
            "0.testnet.hedera.com:50211": "0.0.3",
            "34.94.106.61:50211": "0.0.3",
            "50.18.132.211:50211": "0.0.3",
            "138.91.142.219:50211": "0.0.3",
        };

However, it would be the user side to handle the execution of the nodes.
We can think of logic, if nodes are passed and they all fail, to switch back to the default ones, but it might take additional time for research/implementation.

[ochikov]

Hello @anvabr, what do you think about the last changes explained above?

[anvabr]

@ochikov apologies I should've mentioned this earlier. Thank you for the change and the notification, we are evaluating the new functionality - will come back to you this week.

[anvabr]

Hi @ochikov, we have tested the new implementation - unfortunately not with the expected results. It appears that nodes are selected randomly, and our inspection of the code here confirm this. Why would you not implement round-robin selection? This way a user would be able to prioritise the nodes by just putting them in the correct order in the list.

[anvabr]

Also @ochikov there appears to be a serious bug in the current implementation. If we configure several IPs for a single node and the number of nodes less than 9 the SDK gets into infinite loop - our app freezes as a result. This is also the case when the configuration contains different IPs of single node as in this example below:
let nodes = {
"0.testnet.hedera.com:50211": "0.0.3",
"34.94.106.61:50211": "0.0.3",
"50.18.132.211:50211": "0.0.3",
"138.91.142.219:50211": "0.0.3",
};

relevant code areas:
https://github.com/hashgraph/hedera-sdk-js/blob/e442263ccfc40914d827a48c1e5b2a4e9eb00f50/src/client/Network.js#L255
https://github.com/hashgraph/hedera-sdk-js/blob/1a73f3f1329a48702f2a5170260bd05f186e0ca3/src/client/ManagedNetwork.js#L297

[ochikov]

Hi @ochikov, we have tested the new implementation - unfortunately not with the expected results. It appears that nodes are selected randomly, and our inspection of the code here confirm this. Why would you not implement round-robin selection? This way a user would be able to prioritise the nodes by just putting them in the correct order in the list.

We are getting them randomly because if the list is not populated from the user, but from the addressbook query, we are going to use everytime a similar node and we are going to load the same nodes.

I will review the other issues raised by you.

[anvabr]

We are getting them randomly because if the list is not populated from the user, but from the addressbook query, we are going to use everytime a similar node and we are going to load the same nodes.

This does not work for us, as explained we need an option to apply deterministic logic please. Perhaps a config setting or a parameter into the call that would trigger deterministic behaviour.

[anvabr]

Upon detailed discussion about this request it was discovered that the premise upon which the functionality was requested was inaccurate as apparently in Hedera currently all nodes are run by Hedera council and all of them are essentially equal in power and other qualities. I.e. they currently can't differ in reliability/load etc. Thus the only potential benefit from deterministically selecting nodes would be to differentiate them on the basis of their geographic location / proximity, at the expense of the risk of the risk of overrunning some node[s] with requests. On the balance the random node selection seems like the right option.

[gregscullard]

@anvabr you can also implement your own deterministic node selection and specify which node(s) you want the SDK to use on a per transaction basis by invoking .setNodeAccountIds on the transaction in question.
The SDK attempts to make node selection entirely transparent to the end user/developer, but allows full user/developer control if desired.