Automatic selection of 'best' Socket RV

[cconstab]

Is your feature request related to a problem? Please describe.

Currently we ask the person running sshnp which is the RV closest to them. There are two problems with this approach..

1. People move!
2. Machines crash

Describe the solution you'd like

A much better solution would be to have a single atSign specified like @ rv_earth and having multiple the RV points listening and responding.
However the sshnp only listens to the first response, meaning the closest/fastest for the location of the sshnp would be selected.
This would also allow redundancy of RV's.

This combined with and RV actually responding with a group of RV processes in region/local provides a scalable architecture.

So what is required...

• sshrvd to be able to request another group of sshrvd's for IP/Ports and respond back (provides scale)
• sshnp to collect the 'fastest' response and ignore duplicates from other ssrvd's
• Stretch goal for sshnp if it hits issues with the fist response try the second as a backup
• Stretch stretch goal, to involve sshnpd to see what is closest for it and to find the best middle location - e.g sshnp gets USA and sshnpd gets AP then pick EU

Describe alternatives you've considered

No alternatives come to mind but happy to discuss

Additional context

No response

[gkc]

Given that all notifications go client-atServer-arServer-client for both the request and the response leg, fastest to respond doesn't mean closest - in some cases it could mean farthest away

For example

• imagine sshnpd and sshnp and an rvd are all running in Japan, and that their atServers are all located in the US. Furthermore imagine there is one or more rvd located in the US. The first response the sshnp would get (all other thing being equal) would be from an rvd located in the US.
• if all of the atServers were also in Japan, then the first response (again, all other things being equal) would indeed come from the rvd in Japan. However this breaks down if the sshnpd or sshnp run in a different geographic area, e.g. in the US
• I mentioned "all other things being equal" - the long pole in connections between atServers is the initial pol authentication handshake. If one atServer already has an authenticated connection, that's great; but if it doesn't, it takes several hundred milliseconds to complete the handshake. This additional latency will be several times larger than the speed of light latency

I propose an alternative solution:

• given a range of IP addresses from many RVDs
• and the ability for sshnpd and sshnp to determine latency to each RVD's IP address
• then sshnp and sshnpd could figure out the "best" one

[gkc]

https://pub.dev/packages/dart_ping looks like a good candidate to use for determining latency. Actively maintained, well documented, good code quality. Has support on all platforms (including iOS via the https://pub.dev/packages/dart_ping_ios plugin). On Mac / Linux / Windows platforms it runs the OS's ping command

[gkc]

This will be a very nice feature but is P2/P3 since we currently have the ability for the human to choose an appropriate rvd

[XavierChanth]

Making this a P2, I think it is useful to have a solution for this.