genivi-ipc@lists.genivi.org

Development list for inter process communication (IPC) related topics

View all threads

Re: [Genivi-ipc] Selective broadcast issue with vsomeip

LB
Lutz.Bichler@bmw.de
Fri, Nov 10, 2017 3:02 PM

Hi,

this looks as if you are not setting the "supports_selective_broadcasts" - Parameter in your configuration files?

If you want to use selective broadcasts between nodes A (192.168.0.1) and B (192.168.0.3), the configuration
on A must contain "supports_selective_broadcasts" : "192.168.0.3" and the configuration on B must contain
contain "supports_selective_broadcasts" : "192.168.0.1".

Regards,
Lutz

-----Original Message-----
From: genivi-ipc [mailto:genivi-ipc-bounces@lists.genivi.org] On Behalf Of Fabien HERNANDEZ
Sent: Tuesday, October 10, 2017 4:32 PM
To: genivi-ipc@lists.genivi.org
Cc: Tomas BABIAK tomas.babiak.ext@valeo.com
Subject: [Genivi-ipc] Selective broadcast issue with vsomeip

Hello,

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
same id):

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
http://www.autosar.org/fileadmin/files/standards/classic/4-3/software-architecture/communication-stack/standard/AUTOSAR_SWS_ServiceDiscovery.pdf
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
implementation follows.
2.

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
https://github.com/GENIVI/vsomeip/blob/master/implementation/routing/src/routing_manager_impl.cpp#L2380.
The udp_server_endpoint_impl gets the correct cliendID exactly here
https://github.com/GENIVI/vsomeip/blob/master/implementation/endpoints/src/udp_server_endpoint_impl.cpp#L312.
However, routing_manager_impl receives this ID only when processing a
following SUBSCRIBE request.
3.

Therefore, udp_server_endpoint_impl is returning 0 until it receives
some standard SOME/IP message which contains the real clientID.
4.

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.

--

Best regards

Fabien HERNANDEZ
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

http://www.valeo.com/en/

--

*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. *


genivi-ipc mailing list
genivi-ipc@lists.genivi.org
https://lists.genivi.org/mailman/listinfo/genivi-ipc

Hi, this looks as if you are not setting the "supports_selective_broadcasts" - Parameter in your configuration files? If you want to use selective broadcasts between nodes A (192.168.0.1) and B (192.168.0.3), the configuration on A must contain "supports_selective_broadcasts" : "192.168.0.3" and the configuration on B must contain contain "supports_selective_broadcasts" : "192.168.0.1". Regards, Lutz -----Original Message----- From: genivi-ipc [mailto:genivi-ipc-bounces@lists.genivi.org] On Behalf Of Fabien HERNANDEZ Sent: Tuesday, October 10, 2017 4:32 PM To: genivi-ipc@lists.genivi.org Cc: Tomas BABIAK <tomas.babiak.ext@valeo.com> Subject: [Genivi-ipc] Selective broadcast issue with vsomeip Hello, 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 same id): 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: 1. 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 <http://www.autosar.org/fileadmin/files/standards/classic/4-3/software-architecture/communication-stack/standard/AUTOSAR_SWS_ServiceDiscovery.pdf> 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 implementation follows. 2. 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 <https://github.com/GENIVI/vsomeip/blob/master/implementation/routing/src/routing_manager_impl.cpp#L2380>. The udp_server_endpoint_impl gets the correct cliendID exactly here <https://github.com/GENIVI/vsomeip/blob/master/implementation/endpoints/src/udp_server_endpoint_impl.cpp#L312>. However, routing_manager_impl receives this ID only when processing a following SUBSCRIBE request. 3. Therefore, udp_server_endpoint_impl is returning 0 until it receives some standard SOME/IP message which contains the real clientID. 4. 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. -- Best regards *Fabien HERNANDEZ* 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 <http://www.valeo.com/en/> -- *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. * _______________________________________________ genivi-ipc mailing list genivi-ipc@lists.genivi.org https://lists.genivi.org/mailman/listinfo/genivi-ipc