vsomeip icon indicating copy to clipboard operation
vsomeip copied to clipboard

Support for Explicit Initial Data Request flag

Open tjpsantiago16 opened this issue 3 years ago • 7 comments

Hi @lutzbichler ,

does GENIVI vSomeIP support explicit initial data request flag?

according to AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol_1.5.1, updated versions of SOMEIP should support explicit initial data request flag.

when I check packet captures from vsomeip the explicit initial data request flag is always set to 0 and initial data request flag was never set for eventgroup entries.

Below are some snippets regarding initial data request flags from the specification:

image

[PRS_SOMEIPSD_00700] The third flag of the SOME/IP-SD Flags (third highest order bit) shall be called Explicit Initial Data Control Flag and shall mean that the ECU supports explicit initial data control. (RS_SOMEIPSD_00002)

Note: This means that the ECU understands and honors the Initial Data Requested Flag inside of Eventgroup Entries.

[PRS_SOMEIPSD_00701] The Explicit Initial Data Control Flag shall always be set to 1, meaning the ECU supports this feature. (RS_SOMEIPSD_00002)

Note: This flag allows compatibility to older SOME/IP-SD implementations (e.g. AUTOSAR 4.2), which do not support this feature and have set this flag to 0. New versions shall all support the feature, so they have to set this flag always to 1.

image

Under [PRS_SOMEIPSD_00270] it is stated that Initial Data Requested Flag [1 bit] (I Flag): Shall be set to 1, if initial data shall be sent by Server (see [PRS_SOMEIPSD_00703]).

tjpsantiago16 avatar Jul 15 '21 08:07 tjpsantiago16

AFAIK vsomeip just ignores the Initial Data flag and so always sets it to 0. However, it will send the Initial Data on new subscriptions.

Almeida-Oco avatar Jul 16 '21 14:07 Almeida-Oco

not ignored, but it can cover by the sessionid。and when reboot. it will caculate again

ByteXiaoTang avatar Jul 17 '21 07:07 ByteXiaoTang

The on-wire bit itself is ignored, the only flags taken into account are the reboot flag and the unicast flag (You can see it in service_discovery/src/message_impl.cpp).

I believe what you are referring to is vsomeip recognizing that the subscribed client has rebooted and so it should resend the initial data. But this does not take into account the actual on-wire Initial Data flag. That flag is ignored (although, again, initial data is still sent to new/rebooted clients).

Almeida-Oco avatar Jul 17 '21 10:07 Almeida-Oco

@Almeida-Oco ,

That's right currently vsomeip ignores this bit and it looks like they just set it to 0.

However according to the specs this bit should be checked as it should be possible for eventgroup entries to not require the initial data by setting the initial data request flag bit to 0. (See figure 4.5 above)

Also it would be nice if vsomeip could. Put in README.md which AUTOSAR SOMEIP specifications they align with in each of their version.

tjpsantiago16 avatar Jul 17 '21 18:07 tjpsantiago16

In addition to the comment above. I saw also that the "Explicit Initial Data Control Flag" is also used to check how the next SUBSCRIBE EVENTGROUP entry of an previously unacknowledged SUBSCRIBE request is sent.

If it sent with a StopSubscribe/Subscribe method or just a normal Subscribe Eventgroup entry with its "Initial Data Requested flag" set to 1.

This is described on page 63 of 75 of the AUTOSAR PRS SOMEIP Service Discovery 1.5.1 Specification under PRS_SOMEIPSD_00463

tjpsantiago16 avatar Jul 23 '21 06:07 tjpsantiago16

We do not plan to support the "Explicit Initial Data Control Flag".

lutzbichler avatar Aug 04 '21 06:08 lutzbichler

We do not plan to support the "Explicit Initial Data Control Flag".

Is there any special reason for not supporting the “Explicit Initial Data Control Flag”?

mixxer avatar Aug 15 '21 02:08 mixxer

The flag just increases complexity without adding functionality. If somebody is willing to develop a patch, we will accept it, but there are no plans to implement this on our side.

lutzbichler avatar Mar 11 '23 21:03 lutzbichler