[BUG]: Supporting multiple versions of the same service (PRS_SOMEIPSD_00512). #797
Comments
zhaoxin39913
changed the title
zhaoxin39913
changed the title
zhaoxin39913
changed the title
|
Hello, |
|
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. |
|
Hi @KareemLMR , Any updates for your patch ? |
|
Hi @zhaoxin39913 |
|
Thanks @KareemLMR for sharing the update. |
|
You can try this change #829 I was able to offer 2 services with only different major versions through it but I need you to verify it. Here is the code examples: #include <vsomeip/vsomeip.hpp> #define SAMPLE_SERVICE_ID 0x1234 std::shared_ptr< vsomeip::application > app; int main() { service2.cpp: #include <vsomeip/vsomeip.hpp> #define SAMPLE_SERVICE_ID 0x1234 std::shared_ptr< vsomeip::application > app; int main() { Also for the json file, I supported adding "major" : "value" just as instance in your service definition so don't forget that. And in all other APIs you will pass unique instead of instance but also add major and minor if the API require it |
|
Hi @KareemLMR , Thanks for sharing the sample code. One question here, for client API request_service(), Do we still support setting ANY_MAJOR in unique_version_t parameter? Or we must pass a non-0xFF version ? And if ANY_MAYJOR is supported, how does the AvailabilityHandler get triggered if there are different majVersion instances in the network? |
|
Hello @zhaoxin39913 |
|
Hi @KareemLMR , Currently I am only testing the client APIs which request different major versions for the same instance ID. It's working fine so far. I will continue to test those server APIs and keep you updated once my test is done. |
|
Hi @KareemLMR, Update some test results here for the patch(let's call it 3.5.3p). Now I confirmed the server app can offer two major version instances for the same service/instance ID successfully. And the client app can also detect different version instances when registering different major version availability handlers. However the basic request-response and event notification don't work in the patch. Here are my test setup: The server app running on device B offers service 0x238/0x1 with version 4.1 and always sends response with payload data "Version4.1: Reply Cnt=X" for any methods. In the meantime it periodically sends event 0x4465/0x8778 with payload data "Version4.1: Event Cnt=X“ every 5s. Test Case1 (No response and event received): Both client app and server app are running with vsomeip 3.5.3p. The client app log is as below: Test Case 2 (Only response can be received): Client app is running with vsomeip 3.4.10, server app is running with vsomeip 3.5.3p. The client app log is as below: Test Case 3 (Both reponse and event can be received) : Both client app and server app are running with vsomeip 3.4.10. The client app log is as below: |
|
Hi @KareemLMR , Here is the my client app source code: |
|
Hello @zhaoxin39913 |
|
Thank you for the feedback And don't forget to use unique_version_t in APIs that need them in the latest patch I just shared with you. |
Hi @KareemLMR , Thanks for your quick response. However, this is existing way we must support. In other word we need to keep the vsomeip API backward compatible in the patch, otherwise we will encounter regression issue, eg. COMMON API proxy/stub code is still using the existing vsomeip API. If we always introduce new API for existing feature, the COMMON API won't work, all related things need to be considered as well, then it will be a very big impact. |
|
I believe it is backward compatible as I didn't change any API in the last patch I shared. I said that last line just to confirm with you that you correctly used it from the older patch. You can even try it and tell me what you have found |
Thanks @KareemLMR , that's great! What I expect is the old APIs are still working in the network only has single major version instance. And we can use the new APIs to handle multiple major version instances. I will test the new patch and keep you updated. |
|
Hi @KareemLMR, Tested the second patch (3.5.3p2) you shared with client app(server app is still using 3.4.10), still see the same error log on client side: git log : |
|
Hello @zhaoxin39913 |
|
I tried to reproduce that issue of "[error] Routing info for remote service could not be found!". It only happened if I didn't set the major version in request : request_->set_major_version(major). When I set it, everything works fine. So I said you might forgot it as it was not in the old API but unfortunately this change in the API can't be avoided as the old API only takes service and instance but if we have multiple services with same instance but different major version, the send API won't work (how will it differentiate between them). So I believe it is impossible to implement this feature without this change, do you think of something different? We can negotiate about that if you have a different opinion, but can you try setting the major version as I told you just to check everything is fine? In my opinion, I believe this change is inevitable as I told you. However, I think I made some unnecessary changes to the rest of the APIs making the user forced to know the definition of unique_version_t. I think it is better to return the rest of the APIs like offer_service, request_service, ... and so on back to their original form of accepting instance and major and to add major version with a default value of 0 to the APIs that didn't take them originally like release_service, ..etc and then the unique_version to be constructed inside the vsomeip code NOT by the user so it will be 100% compatible with the old API. But I won't be able to do anything regarding the request_->set_major_version(major). It is unavoidable. If you agree with me. I can make these changes in another patchset but after you test the current version by setting major version in the request_ as I told you.
|
|
Hi @KareemLMR, vsomeip already has message API set_interface_version() to do the same thing, which is duplicate with set_major_version(). Can you confirm ? |
Hi @KareemLMR , vsomeip already has message API set_interface_version() to do the same thing, which is duplicate with set_major_version(). Can you confirm ? |
|
I was thinking of that too. However, in the vsomeip code intervace_version was never used as major_version. They even have different types although both are uint8_t (interface_version_t and major_version_t). I tried to check the SOME/IP Specification Document, it is defined as "major version of the service interface" but in some requirments like this one attached below seems diffrent from the fixed service major version. It seems more like session id or protocol version so I am not sure so I didn't use it fearing it might not be known globally by vsomeip users that they are the same. However, anyway this will not affect my change much if we made sure both interface version and major version are the same. I will just replace the call of my newely defined method with this one in the code and it will be fine, if you confirm it works fine with my method set_major_version()
|
|
Hi @KareemLMR, It's very clearly defined in AUTOSAR SOME/IP Spec [PRS_SOMEIP_00053] that the Major version is the interfance version: And the same in ServiceDiscovery messages in AUTOSAR SOME/IP SD Spec: And according to the Spec, the interfaceVer/MajVer is used to track the message format(request/response/event) change while the minor version is used to track the implementation change for the service of same interfaceVer/MajVer. So could you please update the patch to use the set_interface_version() directly? Thanks to set_interface_version() , we can make the changes compatible with old APIs :). |
|
Hi @zhaoxin39913 |
zhaoxin39913
changed the title
|
Hi @KareemLMR , Happy new year! I am just back from vocation. I have tested your new patch 3.5.3p3. However, it still does not work. In my test I see the availabilityHandler is triggered but the msgHandler is always not triggered which means my client app is not able to receive any response/event messages from server (with 3.4.10). I also opened the wireshirk and found the request and response are present, but the event is not present on client system side. Then I switch to use official 3.4.10 with the same client app (already shared before), and it works as expected. all request/response/event communications are working fine. So could you please help to test and confirm your patch and make sure no regression issues ? |
|
Hi @zhaoxin39913 Service.cpp: #include <vsomeip/vsomeip.hpp> #define SAMPLE_SERVICE_ID 0x1234 std::shared_ptrvsomeip::application app; void on_message(const std::shared_ptrvsomeip::message &_request) { } int main() { app = vsomeip::runtime::get()->create_application("World"); Client.cpp: #include <condition_variable> #include <vsomeip/vsomeip.hpp> #define SAMPLE_SERVICE_ID 0x1234 std::shared_ptr< vsomeip::application > app; void run() { std::shared_ptr< vsomeip::message > request; std::shared_ptr< vsomeip::payload > its_payload = vsomeip::runtime::get()->create_payload(); void on_message(const std::shared_ptrvsomeip::message &_response) { std::shared_ptrvsomeip::payload its_payload = _response->get_payload(); // Get payload std::cout << "CLIENT: Received message with Client/Session [" void on_availability(vsomeip::service_t _service, vsomeip::instance_t _instance, bool _is_available) { int main() { } |
|
On running these 2 examples here are the logs:
Client Side:
If I changed the service major version or the number in set_interface_version() of my client, I got the same error you got as expected because client can no longer find that service. So try that and tell me if you have the same test results on your environment. |
|
Hi @KareemLMR , Thanks for sharing your code and test log. I checked your code and found the only difference is both your client app and server app have called vsomeip_v3::get_unique_version() before offer service and request service. However, as we discussed we need to keep backward compatible and no regressing issues for old applications. So please remove "vsomeip_v3::get_unique_version" in both your client app and server app and test again, since in old application and commonapi stub/proxy code get_unique_version() is never used. |
|
Hi @zhaoxin39913 |
|
Hi @KareemLMR , Any updates for the new patch ? |
|
Yes, I have made the change and tested it. You can try it now with the latest patch I just pushed. #include <vsomeip/vsomeip.hpp> #define SAMPLE_SERVICE_ID 0x1234 std::shared_ptrvsomeip::application app; void on_message(const std::shared_ptrvsomeip::message &_request) { } int main() { app = vsomeip::runtime::get()->create_application("World"); #include <condition_variable> #include <vsomeip/vsomeip.hpp> #define SAMPLE_SERVICE_ID 0x1234 std::shared_ptr< vsomeip::application > app; void run() { std::shared_ptr< vsomeip::message > request; std::shared_ptr< vsomeip::payload > its_payload = vsomeip::runtime::get()->create_payload(); void on_message(const std::shared_ptrvsomeip::message &_response) { std::shared_ptrvsomeip::payload its_payload = _response->get_payload(); // Get payload std::cout << "CLIENT: Received message with Client/Session [" void on_availability(vsomeip::service_t _service, vsomeip::instance_t _instance, bool _is_available) { int main() { } |
|
Hi @KareemLMR, Thanks for the new patch. I will test it and share test result. BTW, have you performed any regression tests for the event/field notification with the new patch as well? |
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: