You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Probably not what you want to hear, but before branching to set socket2's SO_REUSEADDR, check whether your limitation isn't caused by a resource not being freed.
Thank you guys for your great suggestions. I'm gonna fork and (at least try to) implement socket2 in rust-mavlink.
I will send a pull request if it goes well.
@joaoantoniocardoso It's actually the case but that'ss my desired outcome. here is a bit of context:
The code I'm working on is written as guide in a workshop/competition for underwater vehicles, is undoubtedly complicated.
It consist of three parts:
a custom autopilot written in python using pymavlink to control different ROVs, mainly written by Mech. Eng. and Elect. Eng. students
another python code to command these ROVs written in python using pymavlink, mainly CS students
a ground station (Bluerobotic's Cockpit) that connect to the ROV using mavlink2rest
Right now process (1) runs on a raspberry pi and broadcasts udp packets to the network on port 14550 the other two processes (2) and (3) run on another machine (students' laptop) but students can't run them simultaneously because they're listening on the same udp port.
SO_REUSEADDR is enabled on python code, I'm sure of that but the mavlink2rest code do not enable this socket option.
Any suggestion would be highly appreciated. Thanks in advance :)
Well, you don't need to use this approach. UDP broadcasting is not trivial.
IMHO, a simpler approach would be to write a custom piece of software that connects to the autopilot and sends the packets to many other UDP ports, giving each one of the students a different UDP port.
Simpler than that, you can just use mavlink-server to have all those endpoints available for your students. It acts as a dumb switch, sending MAVLink packages from anyone to everyone.
If you prefer to keep your current approach, if you know the IP:PORT mavlink2rest will use, you can bind to it by yourself with a Python script before the mavlink2rest uses it. Note that the script needs to keep the socket alive throughout mavlink2rest's life, and you can do it by calling mavlink2rest from this same script. This is kinda hacky, but might be easier than modifying the lib and rebuilding mavlink2rest with a rust-mavlink fork.
Although mavlink-server was a great suggestion, I ended up forking this repository and patching in socket2 support. This change could be helpful for users coming from a pymavlink background who expect similar socket behavior.
I’d like to contribute this to the main branch and would appreciate your guidance on how to do that. Currently, I've added a heavy dependency just to support this small fix, which isn’t ideal. I can think of two ways to add this feature to the main branch:
Reimplement the set_reuseaddr behavior from socket2 internally, avoiding the dependency altogether. (Not ideal.)
Add socket2 as an optional dependency behind a Cargo feature flag that users can enable if needed.
I’d appreciate your thoughts and feedback. Thanks in advance!
Activity
pv42 commentedon Jul 24, 2025
Rust's
stdnetwork implementation does not seem to support SO_REUSEADDR right now, therefore there is no easy way to do that right now.Your best current option seems to be using
socket2and manually handle the connection only usingmavlinkfor message parsing/building.joaoantoniocardoso commentedon Jul 24, 2025
Probably not what you want to hear, but before branching to set socket2's SO_REUSEADDR, check whether your limitation isn't caused by a resource not being freed.
amir-hossein-zarei commentedon Jul 24, 2025
Thank you guys for your great suggestions. I'm gonna fork and (at least try to) implement
socket2inrust-mavlink.I will send a pull request if it goes well.
@joaoantoniocardoso It's actually the case but that'ss my desired outcome. here is a bit of context:
The code I'm working on is written as guide in a workshop/competition for underwater vehicles, is undoubtedly complicated.
It consist of three parts:
pymavlinkto control different ROVs, mainly written by Mech. Eng. and Elect. Eng. studentspymavlink, mainly CS studentsmavlink2restRight now process (1) runs on a raspberry pi and broadcasts udp packets to the network on port 14550 the other two processes (2) and (3) run on another machine (students' laptop) but students can't run them simultaneously because they're listening on the same udp port.
SO_REUSEADDR is enabled on python code, I'm sure of that but the
mavlink2restcode do not enable this socket option.Any suggestion would be highly appreciated. Thanks in advance :)
joaoantoniocardoso commentedon Jul 25, 2025
Oh, I see..
Well, you don't need to use this approach. UDP broadcasting is not trivial.
IMHO, a simpler approach would be to write a custom piece of software that connects to the autopilot and sends the packets to many other UDP ports, giving each one of the students a different UDP port.
Simpler than that, you can just use mavlink-server to have all those endpoints available for your students. It acts as a dumb switch, sending MAVLink packages from anyone to everyone.
If you prefer to keep your current approach, if you know the IP:PORT mavlink2rest will use, you can bind to it by yourself with a Python script before the mavlink2rest uses it. Note that the script needs to keep the socket alive throughout mavlink2rest's life, and you can do it by calling mavlink2rest from this same script. This is kinda hacky, but might be easier than modifying the lib and rebuilding mavlink2rest with a rust-mavlink fork.
amir-hossein-zarei commentedon Jul 29, 2025
Although mavlink-server was a great suggestion, I ended up forking this repository and patching in socket2 support. This change could be helpful for users coming from a pymavlink background who expect similar socket behavior.
I’d like to contribute this to the main branch and would appreciate your guidance on how to do that. Currently, I've added a heavy dependency just to support this small fix, which isn’t ideal. I can think of two ways to add this feature to the main branch:
I’d appreciate your thoughts and feedback. Thanks in advance!