Skip to content

Session config: set scouting/multicast/autoconnect_strategy/peer/to_peer=always #604

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

Closed

Conversation

JEnoch
Copy link
Contributor

@JEnoch JEnoch commented Apr 7, 2025

As explained in eclipse-zenoh/zenoh#1890, the combination of multicast scouting and autoconnect_strategy=greater_zid can lead to peer-to-peer connection establishment to take up to 8 seconds.

This causes issues in tests when configured with multicast, but could also cause timeout issues at launch time for users who want to use multicast scouting. Waiting for eclipse-zenoh/zenoh#1890 to be fixed, I think it's preferable to set scouting/multicast/autoconnect_strategy/peer/to_peer=always in DEFAULT_RMW_ZENOH_SESSION_CONFIG.json5.

This will fix #596 and possibly other tests when running with multicast scouting enabled.
But it won't change the current default behaviour for users relying on a router and gossip scouting.

@ahcorde
Copy link
Contributor

ahcorde commented Apr 7, 2025

Pulls: #604
Gist: https://gist.githubusercontent.com/ahcorde/8b24ac1110170a0c67b6f12438056c15/raw/7d3efb25e1c9bfd8fc89f162e7dae0026ee1a6ea/ros2.repos
BUILD args: --packages-above-and-dependencies rmw_zenoh_cpp
TEST args: --packages-above rmw_zenoh_cpp
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/15620

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

@Yadunund Yadunund marked this pull request as draft April 7, 2025 17:50
@Yadunund
Copy link
Member

Yadunund commented Apr 7, 2025

Converting to draft as this PR seems to address an issue with multicast scouting which we plan to move away from in our CI jobs.

Given that the RMW freeze is today, i'm inclined to pause on merging this in.

If we get reports of "bugs" caused by this behavior, we can always merge it in after the feeze as a bug fix but I'm hoping the router will be running in our CI jobs by then.

Unless it's preferable to set scouting/multicast/autoconnect_strategy/peer/to_peer=always even with the router?

@JEnoch
Copy link
Contributor Author

JEnoch commented Apr 8, 2025

Unless it's preferable to set scouting/multicast/autoconnect_strategy/peer/to_peer=always even with the router?

I think it's pointless since the peers are configured to connect at startup to the router on tcp/localhost:7447, without scouting and thus without delay.

@Yadunund
Copy link
Member

Yadunund commented May 9, 2025

Closing this one out for reasons described above.

@Yadunund Yadunund closed this May 9, 2025
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.

ros2topic.ros2topic.test.test_bw_delay_hz.test_bw_delay_hz test failure in nightly CI
3 participants