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

Support smooth network changes #3688

Closed
bubenheimer opened this issue Nov 8, 2017 · 7 comments
Closed

Support smooth network changes #3688

bubenheimer opened this issue Nov 8, 2017 · 7 comments
Assignees
Milestone

Comments

@bubenheimer
Copy link

Please answer these questions before submitting your issue.

What version of gRPC are you using?

1.7.0

What JVM are you using (java -version)?

1.8

What did you do?

On Android, create channel with non-streaming and streaming calls. Change data network from cellular to WiFi. (standard mobile use case)

What did you expect to see?

New calls are started over WiFi. Existing calls receive an advisory notification, enabling them to finish up while the cellular network is still available and smoothly start a new call over WiFi, possibly concurrently to the existing call.

What did you see instead?

All call activity continues on cellular data network until the OS yanks it (30 seconds on Nexus 6, Nougat). Communication is disrupted until channel transport is reestablished over WiFi.

@bubenheimer
Copy link
Author

I imagine that the brunt of this can be addressed via a mobile-specific load balancer with subchannels for cellular & WiFi. As this is a standard mobile use case, it would seem appropriate for the grpc-java framework to provide a standard load balancer with a hook for the application to indicate a network change. Or maybe it's trivial enough to custom-implement in the application, based on a standard example? I have not worked with the grpc-java load balancing mechanism yet.

The advisory notification would be triggered at the application level, and could be propagated at that level, too, but it somewhat feels like a general mechanism that the grpc framework might provide; not sure if there is something for this already.

@ericgribkoff ericgribkoff self-assigned this Nov 8, 2017
@ejona86
Copy link
Member

ejona86 commented Nov 8, 2017

This can be done in the ManagedChannel; no need to involve the load balancer. Although there will be a race where RPCs may be assigned to a shutdown transport, as mentioned in #2562. The workaround we did for LBs was to delay the shutdown for a fixed amount of time, hiding the race. That wouldn't work here.

@ericgribkoff
Copy link
Contributor

Spoke with @ejona86 about this. We can offer some kind of #connectToNewNetwork() (or #networkDropped()?) method on ManagedChannel that will invoke #shutdown() on the channel's existing client transports. This will allow existing RPCs to continue on the cell connection, but new RPCs will trigger creation of a new transport which will connect over wifi.

Re: an advisory notification that existing calls are going to be shut down - gRPC as a whole lacks this type of mechanism, e.g., we also cannot notify applications when we know the server is shutting down.

@ejona86
Copy link
Member

ejona86 commented Nov 8, 2017

gRPC as a whole lacks this type of mechanism, e.g., we also cannot notify applications when we know the server is shutting down.

We don't have it today, but it is possible for us to add. It's probably a separate feature request; I've created #3689 for it.

@ericgribkoff
Copy link
Contributor

There's now an experimental prepareToLoseNetwork() API (#3904) on ManagedChannel that switches the channel to IDLE state. Existing RPCs will continue on the current network, but the LB and name resolver are torn down and new RPCs will trigger a new connection.

@ejona86
Copy link
Member

ejona86 commented Mar 30, 2018

@ericgribkoff, should this be closed, or do you want to leave it open for the AndroidChannel convenience?

@ericgribkoff
Copy link
Contributor

We can close this - the necessary APIs are implemented and available for use.

@ejona86 ejona86 modified the milestones: Unscheduled, 1.11 Mar 31, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Sep 28, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants