-
Notifications
You must be signed in to change notification settings - Fork 18.2k
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
Allow multiple UDP clients to connect/disconnect/reconnect #26163
Allow multiple UDP clients to connect/disconnect/reconnect #26163
Conversation
09c079d
to
1f722c0
Compare
4a15a6a
to
d7b9839
Compare
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 is a lot of code. I recently needed the same feature for the same reason and just commented out the locking.
Most of the code is to do things right i.e. use uint32_t instead of string parsing at every packet. |
d7b9839
to
410976b
Compare
410976b
to
947a3a8
Compare
1df9242
to
aba91f6
Compare
607ad24
to
00da51c
Compare
833ad7e
to
86f60c2
Compare
86f60c2
to
39a4095
Compare
last_udp_connect_port != 0) { | ||
ret = sock->sendto(buf, n, last_udp_connect_address, last_udp_connect_port); | ||
} else { | ||
ret = sock->send(buf, n); |
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 send makes no sense without having received a pkt when we are a UDP server
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.
made the condition more tied in with non-UDP_SERVER sends. And added comments for more readability
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.
Add timeout? Would stop the bouncing back-and-forwards between two clients problem.
Maybe a 3 second timeout to then allow bouncing
libraries/AP_HAL/utility/packetise.h
Outdated
#include <AP_HAL/AP_HAL.h> | ||
#include <GCS_MAVLink/GCS_config.h> |
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.
These includes don't look right - don't need GCS_config and probably want AP_HAL_/AP_HAL_Boards.h for the other
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.
It needs to be GCS_Config, the reason is due to the include pattern being:
GCS_Config -- includes --> AP_HAL/AP_HAL_Boards.h
HAL_ENABLE_MAVLINK_PACKETISE
is defined in AP_HAL_Boards.h but relies on the definition of HAL_GCS_ENABLED
which is defined in GCS_Config.h
The solution I think might be to move HAL_GCS_ENABLED one layer up into AP_HAL_Boards.h ?
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.
.... but nothing in this header file is using anything related to either of those headers.
Heck, you could probably just include stdint.h
and add class
in front of bytebuffer
and need no other include.
... actually, now I see the thing.
You're not actually using HAL_ENABLE_MAVLINK_PACKETISE
in the header.
Perhaps rename to AP_MAVLINK_PACKETISE_ENABLED
, move the definition of that into this header inside some infdef
s and include GCS_config.h and whatever else is required to decide on whether to enable the feature...
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.
ok, done. please check
last_udp_connect_port != 0) { | ||
ret = sock->sendto(buf, n, last_udp_connect_address, last_udp_connect_port); | ||
} else { | ||
ret = sock->send(buf, n); |
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.
Work out whether this line is actually sensible; this only makes sense if the socket has been connect()'d somewhere. Perhaps we can't actually cross this line?
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.
made the condition more tied in with non-UDP_SERVER sends. And added comments for more readability
39a4095
to
d458cd3
Compare
d458cd3
to
91de39a
Compare
libraries/AP_HAL/utility/packetise.h
Outdated
#include <AP_HAL/AP_HAL.h> | ||
#include <GCS_MAVLink/GCS_config.h> | ||
|
||
#ifndef AP_MAVLINK_PACKETISE_ENABLE |
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.
#ifndef AP_MAVLINK_PACKETISE_ENABLE | |
#ifndef AP_MAVLINK_PACKETISE_ENABLED |
It's a niggle but also what we're trying to standardise on
... also, do you still need HAL.h
?
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.
Fixed
91de39a
to
c2f7e2a
Compare
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.
Thanks Sid!
Tested on a variant of CubePilot CANMod. The issue was that we were using connected UDP Server socket. Meaning once we connect to an application, then we shutdown that application and then restart the application the listen port on the application can change. But the UDP Server will be stuck with old IP:Port and will not even listen to the new application.
This PR moves to using sendto command with IP:Port from last received packet.
This is the case for example with Mavproxy, or any other client where the data is sent without binding to specific port.