[5.5][sschiessl-bcp] Node Latency and reconnect strategy

[abitmore]

Quoted from Telegram channel:

when I run a "latency test" I use the same calculation; handshake. Typically a 1-3 seconds per node; but upon connecting to a low latency node each subsequent call is about 0.125 seconds, which is what I report as latency in microDEX
In the absence of statistical approaches, I think it would be helpful in the very least, for the reference UI to update the latency number in the lower right, upon each orderbook update, with the time it took to make that orderbook call. It would also be of use to have a "last update" live ascending second counter, for time since last successful ping. Also, a blocktime latency to show if the data being displayed is in fact not stale. In the absence of such, any time the orderbook is not moving the user is left not knowing... is it 30 seconds old? 30 minutes old? 3 hours? ???!?
A combination of these ascending metrics would at least give an overall user experience of an application which is "alive"
this, though... is useless

disconnected since when? should I wait for it to reconnect on its own? should I fiddle with buttons until better?
what is the correct block number?
there is no real information provided by that metric; no real reason for common user to even know the block number.
my point being, that even a stale blocktime there would be much more useful than a stale block number
at least I could quickly compare the stale blocktime to my computers clock
stale block number could mean anything and until it changes again I'm left watching it and losing confidence

[wmbutler]

When in disconnected state, we should know this and should run a function capable of reconnecting to the socket.

I have another piece of software that can lose the socket. When it does, and the widow is hidden in a tab, the socket does not attempt to reconnect, but when the user makes the browser tab active, it triggers a reconnect function. This is a pretty nice feature for relieving sockets and only connecting when a user is observing the page.

[sschiessl-bcp]

Sounds like a cool feature, I would be interested in implementing that together with a reconnect strategy.

Is it on github somewhere?

[wmbutler]

Let me see if I can capture the output from a session on reconnect. It's zube.io if you can get a trial account. You can create a few issues on a sprint and then leave the tab for a few hours. Come back and observe the behavior. It's very consistent in it's sleep and reconnect.

[wmbutler]

Interesting. It's not actually a websocket on zube.io so I guess that doesn't apply. So the approach will need to be different.

[sschiessl-bcp]

I will do a PR for this when #1394 is merged.

The goal is to reconnect when "Auto select" is on, and the node goes out of sync (with safety delay) or is disconnected. Also I would be in favor of displaying some kind of indicator in the bottom right that tells the user directly the connection state (we cant expect the user to know the current block number to compare to the one displayed)

[litepresence]

I am currently using this to reconnect:

https://pastebin.com/MtcDE6nR

I test ping, blocktime, chain id, and zero price to confirm good handshake

and I use this to test latency:

https://pastebin.com/efGgkb7w

latency test runs 24/7 every 10 minutes

reconnect occurs on every buy/sell/cancel request, anytime any requests throws exception, and every ten minutes.

[startailcoon]

@sschiessl-bcp will you work on this as mentioned here before?