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

Add call-through function for notifying about network interfaces #344

Open
wants to merge 1 commit into
base: rolling
Choose a base branch
from

Conversation

jakymiws
Copy link

@jakymiws jakymiws commented Jan 19, 2023

@clalancette
Copy link
Contributor

@jakymiws Can you please give us an overview of what you are attempting to accomplish with this series of PRs?

@jakymiws
Copy link
Author

@jakymiws Can you please give us an overview of what you are attempting to accomplish with this series of PRs?

The goal is to be able to call into fast-dds to get it to re-scan network interfaces. The specific feature in question is enabled by calling the set_qos function as documented here:
https://fast-dds.docs.eprosima.com/en/latest/fastdds/use_cases/dynamic_network_interfaces/dynamic_network_interfaces.html#dynamic-network-interfaces

Copy link
Collaborator

@fujitatomoya fujitatomoya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jakymiws @alsora this feature looks nice to me, do you have actual use case for this feature? and it would be probably nice to talk about this in the meeting? maybe MW WG since this is adding RMW feature?

@@ -2787,8 +2787,19 @@ RMW_WARN_UNUSED
rmw_ret_t
rmw_set_log_severity(rmw_log_severity_t severity);

/// Notify fast-dds to re-scan networks
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RMW should be agnostic from implementation details, Fast-DDS should be removed.

@alsora
Copy link
Contributor

alsora commented Jan 20, 2023

@fujitatomoya sure, we can definitely have a discussion during the next middleware WG.

The use-case is the following: all the existing DDS implementations currently scan for available network interfaces only once, i.e. when a DDS participant is created. This usually happens when you call rclcpp::init().
If a network interface is not available at that time it will be ignored.
For example: you start a ROS application, then you bring up WiFi -> the ROS application will not use WiFi.

We had a discussion in the past about how to get around this and it is ultimately problematic for the middlewares to know whether they have to wait for interfaces, keep scanning for them, republish messages on new interfaces etc.
This API is a trigger to tell the middleware to scan for existing interfaces.

The current default RMW implementation (Fast-DDS) supports this feature: https://fast-dds.docs.eprosima.com/en/latest/fastdds/use_cases/dynamic_network_interfaces/dynamic_network_interfaces.html#dynamic-network-interfaces

@fujitatomoya
Copy link
Collaborator

@alsora appreciate the information, thanks for sharing. apparently we almost have the same use cases 😄

I have considered this kind of feature before, so posting my note here. hopefully this could bring more discussion.

Network Detection / Awareness

Overview

I just want to come up with questions and possible requirements in robots, robotics and edge devices.
As described below, nodes could be connected, disconnected or transited the network status based on dynamic physical environment.

image

Possible Situations

  • Participation (OFF -> ON): right after boot the system, there would be no network connection at all. but as robots move around, it eventually find the network interface.
  • Transition (ON -> ON): as robots are moving in long distance, network interface could be changed. (Internally, ON -> OFF -> OF)
  • Leave (ON -> OFF): as robots are moving, they eventually leave from the network range.

Requirements / Capabilities

  • Application should be able to know the network connectivity status and configuration? (set and get network configuration.)
  • Application should be notified with network status or configuration change event? so that it can issue the API to reconfigure the network once it is back online? (event notification)

Consideration / Note

  • AFAIK, ROS 2 / DDS is NOT aware of network. it just relies on network but cannot detect those status or events to restart the application.
  • most devices currently we have in home, we by here end users can physically help to fix the network problems, such as smartphone, tablets and so on to access the system. but this is not likely robots use cases, so that it should be able to self-healing?
  • specific use cases like factory and logistics, we probably want to use specific network interfaces only nothing else. this means that user can configure possible network interfaces as we like.
  • network infrastructure in edge IoT devices could be not stable enough, sometimes network connection is gone.

Currently i was thinking that this is doable with following and restarting ROS 2 node (DDS participants), but happy to discuss.

@ros-discourse
Copy link

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/network-issues-ros-topic-visibility-dependency-to-network-interfaces/29385/2

@fujitatomoya
Copy link
Collaborator

@alsora quick question, i think that @wjwwood mentioned in MW WG today. How we(application or DDS) can get the event that network configuration changed? is there already some APIs or interfaces provided by Fast-DDS?

@mauropasse
Copy link
Contributor

@fujitatomoya there are currently no APIs on Fast-DDS to be notified about a change on the network interfaces.
They did a quick investigation about it, but would only apply for Linux and wouldn't work in an platform agnostic way.

@ros-discourse
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants