We are facing a strange behavior with the use of vsomeip nowadays. We are
using the selective broadcast mechanism offered by CommonAPI and FRANCA.
Did you experience the issue presented hereafter or is there an explanation
We’ve noticed that if an application subscribe to a selective broadcast
prior any other method is called then it is being subscribed to the service
with a client ID set to 0 instead of the applications’ real client ID.
Therefore, if the service tries to fire an event to the applications’ real
client ID, the application does not receive the event at all.
This is an example of a correct log (both subscribe and unsubscribe has the
2017-10-05 17:09:31.937989 [info] SUBSCRIBE(0002): [0bb8.0001.0064:ffff:1]
2017-10-05 17:09:31.939555 [info] SUBSCRIBE(0002): [0bb8.0001.00c8:ffff:1]
2017-10-05 17:10:13.126558 [info] UNSUBSCRIBE(0002): [0bb8.0001.00c8.ffff]
2017-10-05 17:10:13.130426 [info] UNSUBSCRIBE(0002): [0bb8.0001.0064.ffff]
This is an example of an incorrect log (subscribe id is 0 and it differs
from unsubscribe id):
2017-10-05 17:10:13.391545 [info] SUBSCRIBE(0000): [0bb8.0001.0064:ffff:1]
2017-10-05 17:10:13.409351 [info] SUBSCRIBE(0000): [0bb8.0001.00c8:ffff:1]
2017-10-05 17:10:56.739520 [info] UNSUBSCRIBE(0003): [0bb8.0001.00c8.ffff]
2017-10-05 17:10:56.759814 [info] UNSUBSCRIBE(0003): [0bb8.0001.0064.ffff]
This issue heavily depends on the actual timing. Therefore, it sometimes
works and sometimes not. While testing it, we observed that it worked fine
only the first time an application connected to service after the system
startup and failed with any following attempt. A potential explanation
could be that some actions are performed slower the first time while it is
much faster later on.
Here is what we found out when trying to investigate the route cause:
A request to register for a selective broadcast is handled by the
service discovery and not the service itself. According to Specification
of Service Discovery
section 7.3.1 (page 22), when making a request then “[SWS_SD_00033] The
Client ID shall be set statically to 0x0000.” This is what vsomeip
When a subscribe request which came via network (not over unix domain
socket) is handled, vsomeip routing_manager_impl requests the cliendID
from the udp_server_endpoint_impl
The udp_server_endpoint_impl gets the correct cliendID exactly here
However, routing_manager_impl receives this ID only when processing a
following SUBSCRIBE request.
Therefore, udp_server_endpoint_impl is returning 0 until it receives
some standard SOME/IP message which contains the real clientID.
Vsomeip developers solved this issue by repeatedly sending SUBSCRIBE.
Therefore, some time after the first standard method is called the clientID
gets updated to the correct value.
Note that it looks similarly also in case tcp is used. There should be no
issue with general broadcast as all endpoints are being notified.
Our current workaround is to call an potentially empty method before
subscribing to any broadcast.
System Architect - Telematic
Valeo Comfort & Driving Assistance Systems
Tel: (+33) 1 48 84 54 94 / Cell: (+33) 7 60 59 66 47
76, rue Auguste Perret - 94046 Créteil cedex - France
*This e-mail message is intended only for the use of the intended recipient(s).
The information contained therein may be confidential or privileged,
and its disclosure or reproduction is strictly prohibited.
If you are not the intended recipient, please return it immediately to its sender
at the above address and destroy it. *