You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a use case where I need to bind my gRPC client channel socket to a specific loopback address on my local device. This is useful during testing of a gRPC Server which identifies incoming connections through the IP address of the connecting gRPC clients. Without this feature, locally running virtual gRPC clients all bind to localhost (127.0.0.1) and cannot be distinguished. This can also be useful outside of testing when communicating over gRPC for inter process communication on a single host device.
Implementation overview
Since grpc-dart makes use of the dart Socket class to create client sockets, implementing this functionality is as trivial as passing the option sourceAddress to the Socket constructor in the SocketTransportConnector.initSocket method (http2_connection.dart). A good place to put the sourceAddress option would be in the ChannelOptions class, which already passes the connectTimeout attribute to the aforementioned Socket constructor.
Since it's so low effort to change this, it may be worthwhile to implement. In fact I locally edited this repository and got the functionality I'm looking for to work by only changing 3 lines of code. Note that at least one other gRPC implementation (grpc-java) already supports this functionality: grpc/grpc-java#4900. In the linked issue they also discuss the fact that grpc-go supports this via some mechanism to which I don't know any of the details.
If desirable I could open a PR for this myself.
PS: Optionally it could also be possible to pass the binding port via this method, however, when two gRPC calls are made from the same client channel they might compete for the same port. I'm not sure about this and haven't tested this as I didn't need to be this specific for my use case. Might be interesting to see though.
The text was updated successfully, but these errors were encountered:
ljbkusters
changed the title
Feature Request: Allow an option to set socket sourceAddress via ChannelOptions
Feature Request: Allow an option to set client socket sourceAddress via ChannelOptions
Feb 5, 2025
Feature Request
I have a use case where I need to bind my gRPC client channel socket to a specific loopback address on my local device. This is useful during testing of a gRPC Server which identifies incoming connections through the IP address of the connecting gRPC clients. Without this feature, locally running virtual gRPC clients all bind to localhost (
127.0.0.1
) and cannot be distinguished. This can also be useful outside of testing when communicating over gRPC for inter process communication on a single host device.Implementation overview
Since
grpc-dart
makes use of the dartSocket
class to create client sockets, implementing this functionality is as trivial as passing the optionsourceAddress
to theSocket
constructor in theSocketTransportConnector.initSocket
method (http2_connection.dart
). A good place to put thesourceAddress
option would be in theChannelOptions
class, which already passes theconnectTimeout
attribute to the aforementionedSocket
constructor.Since it's so low effort to change this, it may be worthwhile to implement. In fact I locally edited this repository and got the functionality I'm looking for to work by only changing 3 lines of code. Note that at least one other gRPC implementation (
grpc-java
) already supports this functionality: grpc/grpc-java#4900. In the linked issue they also discuss the fact that grpc-go supports this via some mechanism to which I don't know any of the details.If desirable I could open a PR for this myself.
PS: Optionally it could also be possible to pass the binding port via this method, however, when two gRPC calls are made from the same client channel they might compete for the same port. I'm not sure about this and haven't tested this as I didn't need to be this specific for my use case. Might be interesting to see though.
The text was updated successfully, but these errors were encountered: