Udp multicast

[jfint]

The multicast behavior on UDPCL is to send uplink data on the IP and port that is entered, this is generally bad behavior for multicast using the same IP and port for both directions. The behavior on UDP was to send to the address and port that messages are sent from, which amounts too a unicast uplink.

In general I believe this is better behavior. So I believe I used the patterns in UDPCL to produce that behavior by combining them with with the existing UDP behavior.

[AppVeyorBot]

:white_check_mark: Build MissionPlanner 1.0.1639 completed (commit https://github.com/ArduPilot/MissionPlanner/commit/7b8abfdf5a by @)

[meee1]

i dont want to change the existing function this much that it force another prompt. im also failing to see the real benefit to separating the port at this point. the current system emulates a mesh network well, except for seeing its own traffic. which is actualy a good test, as it simulates a possible another GCS on the same network.

[jfint]

If you are doing any computing in between the AP and GCS it isn't possible to tell the source of the messages at the application layer simply by port, you have to parse additional mavlink data to get it. Not impossible, but not desirable.

Additionally, there are some networks that will not allow you to participate on them with bi-directional multicast data on the same port, because the data cannot be firewalled uni-directionally.

[meee1]

The behavior on UDP was to send to the address and port that messages are sent from, which amounts too a unicast uplink.

it isn't possible to tell the source of the messages at the application layer simply by port, you have to parse additional mavlink data to get it. Not impossible, but not desirable.

currently GCS > multicast > MAV's and self MAV's > multicast > GCS and self sending from a different port still see's an echo of any data sent, by itself. having a unicast responce means tracking sysid/compid per ip and port, which doesn't exist at the moment.

you are suggesting MAV's > multicast > GCS and self GCS > unicast > specific MAV this would require more work to do the tracking correctly

[jfint]

That's just the way its working easily. Sending from a different port does allow you differentiation at the application layer, you will not receive data on a port that is not bound too a socket.

I'm suggesting: MAV's > multicast > GCS (multicast should not loopback) GCS > multicast> MAV at address MAV sent to(the same mulitcast) and port MAV sent from (so there is a directional pair)
I realize that is not what is implemented, but this was far more simple than adding the logic to UDPCL None of this dictates a specific MAV, because there is still multicast capability, however in a situation with more than 1 MAV you would never need to parse data from the other MAV system.