-
Notifications
You must be signed in to change notification settings - Fork 700
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
[INFO]: Supporting multiple versions of the same service (PRS_SOMEIPSD_00512). #797
Comments
Hi @KareemLMR, Yes, I have tested request_service() API for the same service-instances with different major versions, it works without any errors from the log. But I am not able to verify it using vsomeip server API since the offer_service() API doesn't support offering the same service-instances with different major versions within the same VLAN network which I mentioned in #809. Due to the limitation I have to ask our customer to verify it. It seems like our customer is using a 3rd party SOME/IP stack to deloy the services on different ECUs, which can support PRS_SOMEIPSD_00512. |
Hi @KareemLMR , Even we can specify the versions in some client side APIs like request_service(), subscribe() and register_availability_handler()/unregister_availability_handler(), there are still some APIs don't support passing the versions, which means the serviceID-instanceID-majVersion is not fully manageable independently. Thus I think we need to have below changes to fully support PRS_SOMEIPSD_00512 on client side to make sure the version is present in pair.
And request_event()/release_event() shall all add the major version as input parameter as below:
|
I tested the request_service() for the same instance but with different major versions, and it return error message as below: In my test I have two devices (A and B) in the network. First device B offers service 0x1234/5678 with majorVersion 0x12. Next device B request service 0x1234/5678 with majorVersion 0x12 and it works. Then device B request service 0x1234/5678 with majorVersion 0x22, it reported such error. From the source code, it seems like the majorVersion is not taken into consideration when maintaining the service instances available in the network. See void routing_manager_base::request_service() in routing_manager_base.cpp |
Hi @KareemLMR, From my investigation, It seems like the PRS_SOMEIPSD_00512 in SOME/IP SD Spec is totally not supported in vsomeip library, can you confirm ? |
Hello @zhaoxin39913 |
Hi @KareemLMR, I have made below changes per as your request:
And after change I have triggered "notify-sample" to offer the second service instance 0x1234/0x5678 with version 0xA (There is already a service instance 0x1234/0x5678 with version 0x12 offered by another device within the same network). And from the wireshark we can see that the first time notify-sample was successful to offer the service 0x1234/0x5678 version 0xA, but after call stop_offer() and then start_offer() in "notify-sample", it failed to offer the service again. Below are full log messages from notify-sample:
|
Ok, I see the log you added appeared. That's good. I saw what I wanted to see. Let me try a change at my side and send it to you to try when it is successful. |
vSomeip Version
v3.4.10
Boost Version
1.7.6
Environment
Ubuntu 20.04
Describe the bug
Hi vsomeip experts,
One issue I would like to check with you guys.
In order to support multiple versions of the same service (defined in SOME/IP SD spec PRS_SOMEIPSD_00512), there could be multiple services offered with the same serviceID and instanceID but different major versions within a network. Using API request_service(serviceId, instanceId, ANY_MAJOR) should be able to find all services with different major versions for a given serviceID/instanceID pair. Next are_available() API should be able to retrieve all those major versions.
The problem is how does availability_handler() get triggered when those services with different major versions are detected, since only the serviceID and instanceID is passing to the handler without major version.
This is one of our customer user case, what's the solution do you suggest to handle it in our application?
Reproduction Steps
N/A
Expected behaviour
N/A
Logs and Screenshots
N/A
The text was updated successfully, but these errors were encountered: