Skip to content

Conversation

@joeyoravec
Copy link

fixes #690

When resuming from suspend-to-ram it's likely that UDP SOME-IP works but the TCP socket got broken. Until a new TCP socket gets established, the remote end responds SubscribeNak. The handler will call restart()

restart() will early terminate 5 times total. Thereafter it will call shutdown_and_close_socket_unlocked. This is really expensive if the node sends thousands of total requests before a TCP socket gets established.

Options include:

  1. do not call restart() at all on SubscribeNak. seems safe?
  2. fix restart() to early-terminate better in this state, more than 5x
  3. ensure that SOMEIP-SD is inhibited in this state (suspend routing?)

This commit implements 1 but the others might be alternatives

When resuming from suspend-to-ram it's likely that UDP SOME-IP works but
the TCP socket got broken. Until a new TCP socket gets established, the
remote end responds SubscribeNak. The handler will call restart()

restart() will early terminate 5 times total. Thereafter it will call
shutdown_and_close_socket_unlocked. This is really expensive if the node
sends thousands of total requests before a TCP socket gets established.

Options include:
1. do not call restart() at all on SubscribeNak. seems safe?
2. fix restart() to early-terminate better in this state, more than 5x
3. ensure that SOMEIP-SD is inhibited in this state (suspend routing?)

This commit implements COVESA#1 but the others might be alternatives
@FishPickBeans
Copy link

FishPickBeans commented May 27, 2025

Hello, will this modification cause any problems?

#690. I explained our problem; we found vsomeip3.5.5 not this modify code!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG]: vsomeip slow to restart with lots of EventGroup

2 participants