Impl req/res delay config for subscribe/offer msg

[thangarajpvaleo]

Description

In the original implementation,

• the existing configuration "request_response_delay" is never used without a way to give a min and a max value.

Motivation for this change:

• Scenario-1:

  • The client node's sd response [Subscribe] for an offer is fast where offer node can't handle the subscription request
    and no SubcribeAck is sent.
  • Due to the difference in SD response speed between the nodes, the client node keep sending StopSubscribe/Subscribe and Negative ACK.
  • To address this, subscriber had to delay it's SD response, so as to match the offer node.

• Scenario-2:

  • When the client node find's the offer node, response delay for the offer node can be configured.

Changes that we have done:

• Added configuration 'request_response_delay_min' and 'request_response_delay_max'

• Added a async_sender class.

• The async_sender class manages a priority queue of packets with associated timeouts,

• using a worker thread to monitor and trigger callbacks for sending when timeouts expire.

• It provides methods for starting and stopping the worker thread, adding packets to the queue, and setting the callback interface. This enables asynchronous packet sending with timeout management, avoiding blocking the main application thread.

• Changes in Service Discovery Impl class :

  • Added handling of service subscriptions, and offers, and sending these messages asynchronously with managed timeouts using an async_sender class.
  • Additionally, it tracks pending messages to prevent redundant transmissions.

• Some assumptions with respect to service discovery configuration values:

  • 'request_response_delay_max' will be less than 'ttl', 'cyclic_offer_delay' and 'repetitions_base_delay'

  references:

  [PRS_SOMEIPSD_00420]
  - REQUEST_RESPONSE_DELAY shall be specified by a minimum and a maximum.

  [PRS_SOMEIPSD_00421]
  - The actual delay shall be randomly chosen between minimum and maximum of REQUEST_RESPONSE_DELAY.

Validation:

• verified on two ubuntu pc's with the sample notify/subscribe application.

[thangarajpvaleo]

Hi Covesa, May i know the status of this pull request. Please update, Thanks.

[duartenfonseca]

hi @thangarajpvaleo could you fix the conflicts?

[thangarajpvaleo]

@duartenfonseca resolved the conflicts, please check. Thanks

[vidz12]

Is this going to be merged? @duartenfonseca

[thangarajpvaleo]

Hi @duartenfonseca/Covesa , May i know the status of this pull request. Please update, Thanks.