Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gl-client unrecoverable after network change #521

Open
JssDWt opened this issue Sep 30, 2024 · 5 comments
Open

gl-client unrecoverable after network change #521

JssDWt opened this issue Sep 30, 2024 · 5 comments

Comments

@JssDWt
Copy link
Collaborator

JssDWt commented Sep 30, 2024

Whenever there's a network change, like switching from wifi to mobile data, gl-client is unable to reconnect to greenlight using the same grpc channel. This means an app using gl-client would have to be killed and restarted to recover.

Related Breez SDK issue here breez/breez-sdk-greenlight#1090

Unfortunately it seems that tonic's Channel doesn't handle reconnection at all: hyperium/tonic#1254
Meaning reconnection logic should be implemented manually in every client package.

@cdecker
Copy link
Collaborator

cdecker commented Sep 30, 2024

Thanks @JssDWt I was unaware that tonic does not handle reconnections well. Do you have an idea we could use to detect and remedy such a system? I guess you have more experience dealing with flaky connections on the mobile side than we do.

@JssDWt
Copy link
Collaborator Author

JssDWt commented Sep 30, 2024

Do you have an idea we could use to detect and remedy such a system? I guess you have more experience dealing with flaky connections on the mobile side than we do.

We've been using golang grpc bindings in breezmobile, where reconnection is handled automatically by the grpc library. I'm looking into possible solutions.

@JssDWt
Copy link
Collaborator Author

JssDWt commented Sep 30, 2024

An idea is to use the timeout to detect hanging network connections. Problem is that it may be very slow, currently 10 minutes. We could use a lower timeout like this: https://github.com/hyperium/tonic/pull/662/files#diff-2dc4a5ebbcd9a8a198e55baa6958f271c1df257a9e3d6ae9c70295a4df7773deR133

And then manually reconnect whenever that timeout is hit.

@cdecker
Copy link
Collaborator

cdecker commented Oct 18, 2024

So I think this is a fundamental tradeoff between traffic on what would otherwise be a quiescent connection and the time to discover a disconnection. It seems quite natural to me that in order to speed up recovery we'd need to increase the frequency of pings (wherever they may be implemented TCP, GRPC, or app level). That's where additional information, e.g., being told by the OS that we were asleep and we should check the connection, could help immensely: by sending a single ping after being notified by the OS that our connection may not be alive anymore would save us a lot of background pings (which also keep the mobile phone from saving battery by going to sleep).

Is there any API on iOS and Android to get such wake-up signals? And how hard would it be to integrate? We could also just mark the connection as no longer usable upon receiving the signal, keeping old connections alive just in case (can't reconnect and resume anyway), but all future calls go through newly established connections.

@JssDWt
Copy link
Collaborator Author

JssDWt commented Oct 21, 2024

Is there any API on iOS and Android to get such wake-up signals? And how hard would it be to integrate? We could also just mark the connection as no longer usable upon receiving the signal, keeping old connections alive just in case (can't reconnect and resume anyway), but all future calls go through newly established connections.

LDK has a mechanism to check whether the runtime has been in hibernation, with a doc comment here.

I think it should probably be something similar to that. In LDK they then disconnect all peers in that code and reconnect again. The same could be done for the signer and any grpc clients I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants