Scenario:
To support the continuation of Go-XRouter development (https://github.com/blocknetdx/go-xrouter/issues/44), we need an analysis of the XRouter C++ code in order to tell whether there is an issue with the way snodelist works.
XRouter is behaving in a manner inconsistent with our understanding of how the snodelist is acquired and used. However, this behaviour was not documented when it was originally implemented.
This issue is in order to analyse and document the actual behaviour of Blocknet Core around the snodelist.
Expected behaviour
Before testing, our understanding was that each service node maintains an snodelist, gossips it to peers upon request, and updates its list as peers on the list drop connections, or become available, or change score.
Observed behaviour
The following behaviours suggest either a misunderstanding of the Blocknet Core code, or that it has bugs.
Upon launch, both Blocknet Core and Go-XRouter will take several minutes to build up their snodelist. This is surprising if the snodelist in its entirety is gossiped.
Go-XRouter loses its connections every ~12-20 runs and then builds its snodelist up in successive runs after that.
Both the above behaviours cause requests to fail either to return any responses, or enough responses to satisfy queryCount. These are critical failures.
Env:
core wallet 4.3.3 (public) console, block cli
To do:
[ ] Prepare a sequence diagram that details how Blocknet Core requests, compiles, updates, and gossips/provides the list of service nodes
[ ] Identify bug(s) or fixes.
Note: in the C++ code, terminology isn’t consistent. snodelist, sfnodelist and NODE_SNODE_LIST are all used.
Scenario: To support the continuation of Go-XRouter development (https://github.com/blocknetdx/go-xrouter/issues/44), we need an analysis of the XRouter C++ code in order to tell whether there is an issue with the way snodelist works.
XRouter is behaving in a manner inconsistent with our understanding of how the
snodelistis acquired and used. However, this behaviour was not documented when it was originally implemented.This issue is in order to analyse and document the actual behaviour of Blocknet Core around the
snodelist.Expected behaviour
Before testing, our understanding was that each service node maintains an
snodelist, gossips it to peers upon request, and updates its list as peers on the list drop connections, or become available, or change score.Observed behaviour
The following behaviours suggest either a misunderstanding of the Blocknet Core code, or that it has bugs.
snodelist. This is surprising if thesnodelistin its entirety is gossiped.snodelistup in successive runs after that.Both the above behaviours cause requests to fail either to return any responses, or enough responses to satisfy
queryCount. These are critical failures.Env:
core wallet 4.3.3 (public) console, block cli
To do:
Note: in the C++ code, terminology isn’t consistent.
snodelist,sfnodelistandNODE_SNODE_LISTare all used.