blocknetdx
[feature] Service node affinity
Add new Affinities setting to the xbridge.conf that allows to specify a list of service nodes ("snode") that should be selected first when creating orders. Affinities are only considered, if the snode supports are least one of the requested assets. Snodes are selected according to the order used in the list. A snode is identified by the public key.
Example:
Affinities=03f79d629c5c501aa87c71f885da8edfdbdaddf2cb502dc13be4519918101954c2,03f06b832f05c6ff04efe977bf7b562e94e92acc51d201e69c6733ac8db04e4539
This feature would be useful for both debugging purposes and node operators that want to use their own nodes for trading.
Will the same config line influence servicenode selection for XR and XC service calls or can we have an
[X]Affinities=....
for that in the xrouter.conf?
I assumed it would be limited to xbridge only. Most XR and XC services will be requested from exr nodes, which already allow to easily select a specific node.
Any ETA or indication of how far down your todo list this is, @rikublock?
Any ETA or indication of how far down your todo list this is, @rikublock?
No ETA on this atm @walkjivefly due to the ongoing ETH code review work.
This should definitely apply to XR/XC services too.
Consider the scenario where someone wants to know the current SYS block height. They can run xrservice getblockcount SYS and they might or might not get the correct answer (see #606 ). After some experimentation they might learn which nodes are more likely to be reliable and would like to direct their query to a specific node.
Not everyone wants to run EXR. Simply because a node is running EXR doesn't make it inherently more reliable than any other node.
In addition to a config parameter it would be nice to add a command line switch and even an RPC to be able to override the configured value.
I'm thinking about a servicenode "health" monitoring service. It needs to be able to route a request to a particular node to assess it's correctness/reliability. Simply firing off a query for the current known maximum set size might or might not produce a result set which includes the wanted node. As the size of the service node network grows the scattergun approach becomes less practical due to the hardcoded limit on the number of nodes which can be included in a query (see #608 ).