Open 0pcom opened 2 months ago
I attempted to test a local instance of the route-finder with a visor running locally - however, it did not return any routes at all.
Apparently the route-finder does not look at the transport discovery? it's also apparent that any visors that one desires to establish a route to needs to use the same route finder as the local visor. This makes testing quite difficult.
Erson pointed out that the route finder is supposed to use the same database as transport-discovery. So that explains why it wasn't working on it's own.
It's also wrongly documented that it uses it's own database in the deployment documentation
Testing with the 9 visor public keys which have updated to v1.3.21 and which provide proxy servers in the US (according to SD which is known to use an outdated ip geo-location database)
Transports were established using the transport setup-node between adjacent keys in the above list
Transports were established using the transport setup-node between even-even and odd-odd keys by their array index
Result:
Transports were established from my local visor to each key in the list
Confirmation of the transports which exist via transport discovery
The local visor's transports
There are 9 keys here, not including my own, for a total of 10 keys.
A route cannot go through the same visor twice
Hence, the maximum number of hops should be half the number of keys.
10 / 2 = 5
A route with up to 5 hops should be possible.
If the first key and the last key of the route remain the same, it should be possible to have 2 2 2 2 2 = 32 routes from my key to any other key in that list.
It should further be possible to have 16 possible 4-hop routes, 8 possible 3-hop routes, and 4 possible 2-hop routes.
tests of
skywire cli route find
- first with the default 1 hopmin, max hops = 2
min, max hops = 3
min, max hops = 4
min, max hops = 5
This is very likely to be an issue with the route finder itself.