-
Notifications
You must be signed in to change notification settings - Fork 69
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
[rmw] Improve handling of dynamic discovery #338
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
I have some minor comments/suggestions.
rmw/include/rmw/discovery_params.h
Outdated
/// Uses ROS_LOCALHOST_ONLY environment variable. | ||
RMW_AUTOMATIC_DISCOVERY_RANGE_DEFAULT = 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that if ROS_LOCALHOST_ONLY
is not set, it is just up to rmw implementation? that means, changing rmw implementation via environmental variable changes application behavior pretty much? i think it would be nice to define the default in ROS 2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The behavior in rcl is to use RMW_AUTOMATIC_DISCOVERY_RANGE_LOCALHOST
if no value is given for the environment variable.
I think it's worth considering removing the RMW_AUTOMATIC_DISCOVERY_RANGE_DEFAULT
value entirely since it currently will never get passed to rmw
from rcl
, and furthermore we're expecting the RMW implementations to implement ..._DEFAULT
the same as ..._LOCALHOST
anyway. Having this redundancy is probably just creating confusion and not accomplishing anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The QoS enums have a *_SYSTEM_DEFAULT value. I forget what this was for. Was it to allow setting QoS via a middleware specific configuration?
If so, RMW_AUTOMATIC_DISCOVERY_RANGE_SYSTEM_DEFAULT
might be useful to say "don't mess with discovery settings, they're already configured with middleware specific APIs".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right @sloretz.
I think @mxgrey is also right, it's weird if we're never sending the value down to rmw, so we should either not have it as an rmw option or we should handle it in the rmw layer. It might make sense to have ROS/RCL version that has system default but not have one in RMW if that one doesn't make sense. I know we only have RMW enums atm, however.
However, it might just be that we shouldn't be automatically be converting the DEFAULT into LOCALHOST as we are now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, it might just be that we shouldn't be automatically be converting the
DEFAULT
intoLOCALHOST
as we are now.
If we are just converting DEFAULT
to LOCALHOST
( I see that happening in the rmw_cyclonedds_cpp PR) then I agree it doesn't seem like an option at the RMW layer is necessary.
If someone wants to use an XML config, and doesn't want the rmw_*
layer to mess with discovery settings, and the default discovery range is localhost, what option should they provide for the range? SUBNET
since the default behavior seems to be to do nothing, at least for cyclonedds?
rmw/include/rmw/discovery_params.h
Outdated
/// Allows multicast on the reachable network | ||
RMW_AUTOMATIC_DISCOVERY_RANGE_SUBNET = 3, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if system has multiple network interface? that is also rmw implementation dependent as it is now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. That is out of scope of this PR.
rmw/src/discovery_params.c
Outdated
if (strncmp( | ||
left->static_peers[ii], | ||
right->static_peers[ii], | ||
RMW_DISCOVERY_PARAMS_PEER_MAX_LENGTH) != 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about the one is with hostname which can be DNSed to IP, and the other with the same IP address? that is not supported here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main use case for this is testing and configuration. So yes, this means that discovery_params which has a hostname that can be DNSed to some other host name is considered a different configuration.
This pull request has been mentioned on ROS Discourse. There might be relevant details there: https://discourse.ros.org/t/ros-2-tsc-meeting-minutes-2023-02-16/29927/1 |
Signed-off-by: Geoffrey Biggs <gbiggs@killbots.net>
Signed-off-by: Geoffrey Biggs <gbiggs@killbots.net>
Signed-off-by: Geoffrey Biggs <gbiggs@killbots.net>
Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
ee413aa
to
a493020
Compare
Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Michael X. Grey <grey@openrobotics.org>
Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
API and functions that are implemented here lgtm, but we should have some tests for those new functions that live here. I think @sloretz and I can help with that tomorrow.
I also think we need to address @fujitatomoya's comments, as I think they're still relevant even after the changes. |
I don't have push access to this repo. Would you like me to open yet another PR? |
@arjo129 I invited you to have push access. Once you accept, you should be able to continue here. |
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
@wjwwood FYI 2cf62e3 is a sizeable change. It:
|
Signed-off-by: Shane Loretz <sloretz@google.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one small necessary (imo) change, otherwise lgtm
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: Shane Loretz <sloretz@google.com>
Signed-off-by: William Woodall <william@osrfoundation.org>
Signed-off-by: Shane Loretz <sloretz@google.com>
This PR adds to
rmw
functionality necessary to support the improved handling of dynamic discovery.It adds handling of the new discovery-related configuration parameters to
rmw
so they can be used byrcl
to control the behaviour of RMW implementations.