Repository navigation
The sdk should auto-detect ipv4 loopback and ipv6 loopback for daprd communication. #218
Description
Activity
Might be better to detect the environment automatically and set the address accordingly. This is a detail the user shouldn't be aware of.
Reacted by Aman Bhardwaj and Artur SouzaWhile reducing the friction because of issues faced by localhost is good. Asking user to provide this ipv4(or ipv6)address is not good solution,
I agree it should be auto discovered for user.Reacted by Artur SouzaA delay on startup is a non-issue.
@yaron2 If it is "small", I agree.
Looks like Java has this built in: https://docs.oracle.com/javase/7/docs/api/java/net/InetAddress.html#getLoopbackAddress%28%29
Reacted by Artur SouzaDoesn't it have to use the one daprd is using? Can't daprd be using the ipv6 loopback, and that api returns the ipv4 loopback?
I thought about it too. If both are present, client must use what dapr is using - which can only be known by trying to connect.
- changed the title
[-]The sdk should let the user choose between ipv4 loopback and ipv6 loopback for daprd communication.[/-][+]The sdk should auto-detect ipv4 loopback and ipv6 loopback for daprd communication.[/+]on Feb 13, 2020 /assign
I have made an investigation pass into this issue and have the following findings:
- A constant called SIDECAR_IP has since been added as a part of Refactoring properties and constants. #333, which is implemented to detect the sidecar's IP address by inspecting the system properties via a call to Properties.SIDECAR_IP.get() that looks for the sidecar's IP using this logic: first try to get system property named "dapr.sidecar.ip", if not available try get environment variable named "DAPR_SIDECAR_IP", and if neither is available fallback to "DEFAULT_SIDECAR_IP" which is hardcoded to "127.0.0.1"
- Given the above, I think that these points that were raised are now already addressed:
-- "Doesn't it have to use the one daprd is using? Can't daprd be using the ipv6 loopback, and that api returns the ipv4 loopback?"
-- "If both are present, client must use what dapr is using - which can only be known by trying to connect."
Thus, I believe the remaining work for this issue would be as follows:
- Refactor the source code and tests to change the currently hardcoded "127.0.0.1" to use the value from Properties.SIDECAR_IP.get() instead.
- Change the DEFAULT_SIDECAR_IP constant's value from the hardcoded "127.0.0.1" to instead use the Java API getLoopbackAddress that @yaron2 suggested instead. This would make the IP default value more dynamic and account for situations where users operate in an exclusively ipv6 environment and the logic ends up falling back to the default value.
@artursouza - thoughts on the above? If you think this is the right approach, I can start working on these changes.
I've just looked at the current code in master for runtime and this is the default behavior of the sidecar:
- Standalone mode: listen to all addresses
- K8s mode: listen to [::1],127.0.0.1
So, this approach is fine as of now. Let's keep it. User can override this setting if he/she decided to override the default listen ports.
@artursouza - awesome, thanks for looking into this. I'd like to confirm here before proceeding:
- Are you saying that the approach of setting DEFAULT_SIDECAR_IP to the loopback address via
InetAddress.getLoopbackAddress()is fine? - Or are you thinking we need to set DEFAULT_SIDECAR_IP to the localhost address via
InetAddress.getLocalHost()?
Given the default behavior of the sidecar you've determined, I believe that Option 1 would be the correct approach given that it listens to the loopback addresses in K8s mode. Please let me know if you also agree with Option 1, thanks!
- Are you saying that the approach of setting DEFAULT_SIDECAR_IP to the loopback address via
@artursouza - awesome, thanks for looking into this. I'd like to confirm here before proceeding:
- Are you saying that the approach of setting DEFAULT_SIDECAR_IP to the loopback address via
InetAddress.getLoopbackAddress()is fine? - Or are you thinking we need to set DEFAULT_SIDECAR_IP to the localhost address via
InetAddress.getLocalHost()?
Given the default behavior of the sidecar you've determined, I believe that Option 1 would be the correct approach given that it listens to the loopback addresses in K8s mode. Please let me know if you also agree with Option 1, thanks!
Update: After reading your feedback again @artursouza I've gone ahead with Option 1 using
InetAddress.getLoopbackAddress()- please see #649 for latest implementation.- Are you saying that the approach of setting DEFAULT_SIDECAR_IP to the loopback address via
Expected Behavior
Today the sdk will choose the ipv4 loopback address to contact darpd: 127.0.0.1 (this was changed from "localhost" today). Some users may prefer ipv6 or may operate in an ipv6 only environment. The sdk should automatically detect which one to use: ipv6 or ipv4.
Actual Behavior
Today the sdk will always use the ipv4 loopback address: 127.0.0.1 to connect to daprd.