Multicast: udp_server_endpoint_impl::on_multicast_received and udp_server_endpoint_impl::is_same_subnet

[nachtfuchs]

I observed the following line in "udp_server_endpoint_impl::on_multicast_received" if (multicastremote.address() != local_.address()...

I am not sure whether the logic is correct concerning multicast so I raise this topic for discussion. What I observed is the following:

• two nodes (ip addresses 4242::1 and 4343::1)
• multicast for service discovery is ff14::4242. I applied the patch in #462, so service discovery "works" with IPv6 on my machines.
• multicastremote.address() is set to the "partner's" unicast (!) address, which is 4242::1 for the node that has 4343::1 configured as the ethernet device address. Exactly the other way round for "the other node". So "multicastremote.address()" is NOT a multicast-address but a unicast address! This naming does NOT make sense to me.
• Problem: the mentioned line returns false for "is_same_subnet". The reason is that the "prefix" is set by VSOMEIP_PREFIX ( in internal.hpp) to 24

I think that this does NOT make sense. Service discovery is used so that nodes can "discover" their partners. Creating a "prefix"-condition on networks is working against the concept of service discovery! The current implementation requires manual work to identify the communication partners and align the networks of the communication partners so that their "prefix" fit. This could be sometimes impossible.

Is it possible to set "VSOMEIP_PREFIX" to zero? Would this allow all networks to communicate with "my" node? What do you guys think? Is the current implementation of the "multicast logic" transparent for the user? (software quality "usability")

[pomforandroid]

I encountered an issue where if (multicastremote.address() != local_.address()) returns false, indicating that both multicastremote and local have the same address, which is 192.168.1.3.

However, in my setup, 192.168.1.3 is the unicast address for my Android client, while the server on QNX has a unicast address of 192.168.1.1. I have spent a considerable amount of time examining the code but am still unable to understand this issue. As you seem to be an expert in this area, I was hoping you could assist me in resolving this issue.

I have included the configuration file for the client below for reference. Thank you for your help!

{ "unicast": "192.168.1.3", "netmask": "255.255.255.0", "logging": { "level": "verbose", "console": "true", "file": {"enable": "true", "path": "/data/local/tmp/vsomeip.log"}, "dlt": "true" }, "tracing": { "enable": "true", "sd_enable": "true" }, "applications": [ { "name": "client-dvr", "id": "0x1343" } ], "clients": [ { "service": "0x0004", "instance": "0x0002", "unreliable": "30504", "multicast": { "address": "224.224.224.240", "port": "30513" } } ], "routing": "routingmanagerd", "service-discovery": { "enable": "true", "multicast": "239.127.3.1", "port": "30490", "protocol": "udp", "initial_delay_min": "10", "initial_delay_max": "50", "repetitions_base_delay": "50", "repetitions_max": "3", "ttl": "3", "cyclic_offer_delay": "2000", "request_response_delay": "1500" } }