New prs 3.5.7 2 #930
Merged
New prs 3.5.7 2 #930
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary Fix vsomeip unit-tests failing on Windows Details Unit tests updated to resolve incompatibilities between Linux and Windows
Summary Updated utility::is_routing_manager and documentation for Windows Details When a process is interrupted midway (e.g. kill -9), the Host file is not deleted and when attempting to launch a new host, since the file already exists, it's not possible for the Host to be created, never being able to have a new Host again. A handler was created for Windows to, in case it cannot create the file, verify if it's still valid and if not, delete the file and create a new one. In the case of Linux, it can already verify if the file is locked or not, and if it's not, it assigns the new host to the file. Additionally, documentation was updated for Windows: README.md examples/hello_world/readme examples/readme.txt changed to readme.md and updated
Summary Use current boost.asio API Details Some deprecated operations have been removed with boost v1.87.0 Issue #853
Details If an endpoint is no longer reachable, it is possible that a TCP connection takes an absurd amount of time to timeout if it happens to have unacknowledged sent data, as the TCP retransmission retries kick in, instead of TCP keepalive Some requirements refer that TCP connections should close after ~3s of unresponsiveness, so use TCP_USER_TIMEOUT to handle the retransmission scenario Refer also to commit 1f99939, where the same change was already done for the local TCP communication This effectively solves situations where a misbehaving ECU takes dozens of seconds to acknowledge TCP data, leading to a lot of TCP retransmission, and a massive amount of accumulated data in the daemon
Details With TCP communication, netlink is also used by every vsomeip application in order to determine when the "local" interface is ready That unfortunately means that an ECU with a few hundreds of vsomeip applications has a few hundreds of netlink sockets, all racing at startup to collect network state. Not ideal! Instead of using netlink (which is Linux-specific), use IP_FREEBIND (also Linux-specific) in order to bind the local TCP ports regardless of network state. It is much simpler, and bypasses the problem of waiting for the local interface There are also plenty of small other advantages: routing client logic becomes similar in TCP/UDS ton less code
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.