stack_wallet icon indicating copy to clipboard operation
stack_wallet copied to clipboard

Reuse sockets

Open sneurlax opened this issue 2 years ago • 3 comments

Sometimes stack wallet users can't sync (usually can't rescan or restore) for electrum (possibly particularly fulcrum) and get a ssl handshake exception on the client stack wallet device side this often corresponds to the server blocking additional connections to our server default for some is 12 ususally it works after increasing the connection limit, for example to 20 some users continue to get the handshake error even though our server no longer blocks them most other servers will not have changed the default limits and users won't be able to use non-stackwallet servers in some situations (particularly rescan and restore) other electrum clients don't make additional connections for each command, as we at least sometimes seem to do electrum protocol is a TCP socket and you can send commands asynchronously and match the responses up by id It looks like sometimes we make a connection and close it and make another connection and send the next command, and do this rapidly One guess is that sometimes (this often happens on mobile networks) there is some equipment in the path that is throttling or blocking one of the rapid connections Advantages to looking at our electrum client usage and making it more efficient are 1.) users can use non-stack servers without getting banned 2.) very likely less client resource usage 3.) very likely less server load 4.) possibly improves this sort of mystery situation where users get handshake error on rescan or restore. A related issue is the fact that stack wallet sync just seems goes red disconnected after this handshake error, when perhaps a retry without manual intervention would succeed. Alexa has frequently gotten this issue with BCH, and we currently have a user getting it with LTC The LTC connection limit was just updated from 12 to 20

Possibly related:

  • https://github.com/cypherstack/stack_wallet/issues/523
  • https://github.com/cypherstack/stack_wallet/issues/405
  • https://github.com/cypherstack/stack_wallet/issues/542

sneurlax avatar May 23 '23 17:05 sneurlax

IIRC, for this we talked about not creating a new socket connection for every rpc call. https://github.com/cypherstack/stack_wallet/blob/b41d31fd32738879f7fe52dc769faa82c60f377b/lib/electrumx_rpc/rpc.dart is what we currently use the change to using a persistent connection will be a bit of work as we need to make sure if the connection gets interrupted that we attempt to reconnect or pass on the error. Updating the connection when changing nodes will also need to be handled

sneurlax avatar May 23 '23 17:05 sneurlax

we have https://github.com/cypherstack/stack_wallet/blob/b41d31fd32738879f7fe52dc769faa82c60f377b/lib/electrumx_rpc/subscribable_electrumx.dart which is not used. This class would allow a persistent connection and subscribe to events such as watching for incoming transactions withou having to refresh everything you can prob grab the persistent connection code from that while ignoring the event stuff for now. Listening for transaction events will add a whole new pile of changes so I think we ignore that for now and just get a persistent electrumx client that does not kill its socket after every call

sneurlax avatar May 23 '23 18:05 sneurlax

Work in #persistence hasn't completed yet; overall goal is to reuse sockets over multiple requests

sneurlax avatar May 24 '23 22:05 sneurlax