You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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..
People move!
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
The text was updated successfully, but these errors were encountered:
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
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
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..
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...
Describe alternatives you've considered
No alternatives come to mind but happy to discuss
Additional context
No response
The text was updated successfully, but these errors were encountered: