SUBSCRIBE ACK is not sent after the first SUBSCRIBE request

[splywaczyk]

Hello

I've observed that during the initialization phase and at the beginning of repetition phase SUBSCRIBE ACK is never sent after first SUBSCRIBE but always after second or third SUBSCRIBE request. Scenario looks like this:

   Time   |          Request          | Service Id
----------|---------------------------|-------------
63.695081 | OFFER SERVICE             | Test_service
63.706893 | SUBSCRIBE                 | Test_service
63.896316 | OFFER SERVICE             | Test_service
63.899086 | STOP SUBSCRIBE, SUBSCRIBE | Test_service
63.947185 | SUBSCRIBE ACK             | Test_service
64.013000 | SUBSCRIBE ACK             | Test_service

I've found that there is a pending subscriptions queue so I assume that it why I receive SUBSCRIBE ACK two times but I don't understand why SUBSCRIBE ACK is never sent after the firs SUBSCRIBE. As I mentioned it happens only during the initialization phase and at the beginning of repetition phase when client is started before the service. When service is started first then SUBSCRIBE ACK is received after the first SUBSCRIBE.

Mentioned scenario is according to SOME-IP specification, but still it seems that the behavior is not correct.

[lutzbichler]

How is SD configured in this scenario? It looks as if processing on service side is slow.

[splywaczyk]

Whole content of 'vsomeip.json'

{
   "unicast" : "192.162.34.1",
   "logging" :
   {
      "level" : "debug",
      "console" : "true",
      "file" : { "enable" : "false" },
      "dlt" : "true"
   },
   "tracing":
   {
      "enable" : "true",
      "sd_enable":"true",
      "channels" :
      [
          {
              "name" : "Priate channel",
              "id" : "PC"
          }
      ],
      "filters" :
      [
          {
              "channel" : "PC",
              "services" : [ "0xABC" ],
              "type" : "negative"
          }
      ]
   },
   "applications" :
   [
      {
         "name" : "vsomeipd",
         "id" : "0x1"
      }
   ],
   "endpoint-queue-limits" : "5120",
   "endpoint-queue-limit-local" : "5120",
   "routing" : "vsomeipd",
   "service-discovery" :
   {
      "enable" : "true",
      "multicast" : "239.30.10.1",
      "port" : "30490",
      "protocol" : "udp",
      "initial_delay_min" : "10",
      "initial_delay_max" : "50",
      "repetitions_base_delay" : "100",
      "repetitions_max" : "5",
      "ttl" : "3",
      "cyclic_offer_delay" : "2000",
      "request_response_delay" : "20"
   }
}

[AnmolShitole]

Hello I am also facing same issue. For first time when I subscribe that time I am able to get the SUBSCRIBE ACK after that I unsubscribed. Then again I try to subscribe that time I am not able to get the SUBSCRIBE ACK in same communication.

[Eternal6149]

Hello I am also facing same issue. For first time when I subscribe that time I am able to get the SUBSCRIBE ACK after that I unsubscribed. Then again I try to subscribe that time I am not able to get the SUBSCRIBE ACK in same communication.

if you sub with ANY event，and unsub with specific event， then sub with ANY envent，you won't receive ack.

[CTWHB]

@splywaczyk we were unable to replicate the situation on my side, but in the case you described when the client is raised before the service, and from the timing in the chart you added, it seems the processing in the beginning of the repetition phase is strained, and the sending of a second offer message is done before the processing of the first subscribe from the client. This situation is not unexpected.

@AnmolShitole and @Eternal6149 please provide logs or traces.

[Eternal6149]

I was wrong. The case mentioned in the previous comments should not occur under normal circumstances.

Hello I am also facing same issue. For first time when I subscribe that time I am able to get the SUBSCRIBE ACK after that I unsubscribed. Then again I try to subscribe that time I am not able to get the SUBSCRIBE ACK in same communication.

if you sub with ANY event，and unsub with specific event， then sub with ANY envent，you won't receive ack.

[pawan-c-t]

what was the conclusion?