Make it possible to access the port a GRPC server is listening on #3107
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
It used to be the case (prior to some
grpcio
version bump) that it was easy to get the addresses a GRPC server is listening on after the server is created. That was useful when asked to listen on port 0, which causes the system to bind some random free port number. This is a functionality we often use in tests to avoid hard-coding port numbers.I'd like to make it possible to reuse the TLS credentials setup code while still making it possible to get the chosen port. The scenario that makes me want it is the following:
ServerCredentials
creation code that takes aUri
and figured out what to do with it.Another thing I ran into, is if the URIs are passed using our Uri object, I have no way to change the port. This is useful when for example I pass
"insecure-service://127.0.0.1:0/"
as the listening uri to this app server object mentioned above. It would then be nice to have a method such as.get_listen_uri()
that will then return"insecure-service://127.0.0.1:12345"
, where 12345 is the port that was randomly chosen. This is useful, since this can then be easily passed into a Client objects (e.g. https://github.com/mobilecoinfoundation/mobilecoin/blob/master/fog/view/connection/src/lib.rs#L48, a pattern repeats itself in pretty much all of our GRPC client objects).