binance: Retry keep alive.

[JoeGruffins]

Untested. Attempting to solve a problem with stuck books.

[buck54321]

Let's do something like this so that we can test.

Also, please look into the LIST_SUBSCRIPTIONS websocket message to see if we can leverage that in a periodic check to catch discrepancies.

[JoeGruffins]

Looking into querying the subscriptions.

[JoeGruffins]

Sorry I have not tested this on testnet/mainnet yet, but I should be able to use on testnet correct?

[buck54321]

Sorry I have not tested this on testnet/mainnet yet, but I should be able to use on testnet correct?

Maybe? I haven't found testing mm on testnet very useful.

[martonp]

Maybe a better technique would be if an orderbook has not received an update within a certain period, maybe 30 seconds, then resync the orderbook. Currently we will only know that an orderbook is stale every time checkSubs is run, so it could remain stale for 30 mins.

[buck54321]

Maybe a better technique would be if an orderbook has not received an update within a certain period, maybe 30 seconds, then resync the orderbook. Currently we will only know that an orderbook is stale every time checkSubs is run, so it could remain stale for 30 mins.

This would result in tons of unnecessary reloads on low-volume markets. checkSubs interval can be much shorter though.

[martonp]

I've been using this diff to test on mainnet. I've turned off my internet connection for 20 mins, then turned it back on, and the orderbooks immediately resync without hitting the new code here. The code looks good otherwise and works fine with the simnet test. Would be nice to be able to reproduce the issue though.

[JoeGruffins]

@martonp does the order book desync look ok? https://github.com/decred/dcrdex/compare/1a223db8b8ae83b3e4da70b6ddd1adbf421ef027..e3cf2a8358ff0ac4a6e6e61507439a2b1478f56b