feat: Add TTL connection param to multicast#1842
Conversation
|
PR missing one of the required labels: {'breaking-change', 'enhancement', 'new feature', 'documentation', 'dependencies', 'bug', 'internal'} |
6a95955 to
7c4a8e4
Compare
|
PR missing one of the required labels: {'enhancement', 'documentation', 'internal', 'breaking-change', 'new feature', 'bug', 'dependencies'} |
7c4a8e4 to
83bb94c
Compare
|
PR missing one of the required labels: {'bug', 'breaking-change', 'documentation', 'dependencies', 'internal', 'new feature', 'enhancement'} |
83bb94c to
113e3a2
Compare
|
PR missing one of the required labels: {'enhancement', 'breaking-change', 'internal', 'new feature', 'bug', 'dependencies', 'documentation'} |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1842 +/- ##
==========================================
- Coverage 70.99% 70.84% -0.16%
==========================================
Files 360 360
Lines 65175 65186 +11
==========================================
- Hits 46272 46180 -92
- Misses 18903 19006 +103 ☔ View full report in Codecov by Sentry. |
|
|
||
| // If TTL is specified, add set the socket's TTL | ||
| if let Some(ttl_str) = config.get(UDP_MULTICAST_TTL) { | ||
| let ttl = match ttl_str.parse::<u32>() { |
There was a problem hiding this comment.
IPv6 hop limit is not yet supported in the Rust library.
I've opened rust-lang/rust#138744 to address the issue.
In the meanwhile, I suggest to simply log a warning in the case of an IPv6 socket.
// If TTL is specified, add set the socket's TTL
if let Some(ttl_str) = config.get(UDP_MULTICAST_TTL) {
match &local_addr {
IpAddr::V4(_) => {
let ttl = match ttl_str.parse::<u32>() {
Ok(ttl) => ttl,
Err(e) => bail!("Can not parse TTL '{}' to a u32: {}", ttl_str, e),
};
ucast_sock.set_multicast_ttl_v4(ttl).map_err(|e| {
zerror!("Can not set multicast TTL {} on {}: {}", ttl, mcast_addr, e)
})?;
}
IpAddr::V6(_) => {
tracing::warn!(
"UDP multicast hop limit not supported for v6 socket: {}. See https://github.com/rust-lang/rust/pull/138744.",
mcast_addr
);
}
}
}There was a problem hiding this comment.
Wasn't sure how tokio handled this under the hood, I just saw is said it "may not have any effect" and figured it was a shot in the dark to attempt to set the TTL.
Sounds great, I will make this change. Thanks!
There was a problem hiding this comment.
I have taken your changes, feel free to re-review that they were taken correctly.
It passed a local build for me.
3f31068 to
8f2d13e
Compare
Hi, I am using Zenoh for a project and I use a multicast listen endpoint in peer mode.
Using a multicast endpoint for multicast communication works fine on flat networks, but once a router is involved, the multicast traffic is lost, due to the default TTL of 1 in multicast connections in the Tokio library.
See also: https://docs.rs/tokio/latest/tokio/net/struct.UdpSocket.html#method.set_multicast_ttl_v4
Note I have minimal rust programming experience, and used online resources and the code surrounding this addition to help me craft this PR, so feel free to make changes if I did something suboptimally or wrong.
I was able to build zenoh and run the zenoh pub client like so:
I confirmed that the outgoing multicast TTL is set to what I specify it to, and that the traffic is no longer dropped on the other end of the network.
This is a critical feature when handling multicast traffic that is routed.
P.S., very nice library :)