Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove bind-to-device support where unavailable #773

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

EriComic
Copy link

@EriComic EriComic commented Oct 3, 2024

On freeBSD-like network stacks, the SO_BINDTODEVICE socket option is not available. Since there is no suitable replacement for this socket option, we ignore the 'device' configuration option on systems missing the option and emit a warning instead.

This makes vsomeip compatible with the new io-sock network stack on QNX 7.1+.

Co-author: Daniel Freiermuth danielfr@haleytek.com @danielfr-haleytek

EriComic and others added 2 commits October 3, 2024 10:33
On freeBSD-like network stacks, the SO_BINDTODEVICE socket option is
not available. Since there is no suitable replacement for this socket
option, we ignore the 'device' configuration option on systems missing
the option and emit a warning instead.

This makes vsomeip compatible with the new io-sock network stack on
QNX 7.1+.

Co-author: Daniel Freiermuth danielfr@haleytek.com @danielfr-haleytek
@danielfr-haleytek danielfr-haleytek mentioned this pull request Oct 7, 2024
@duartenfonseca
Copy link
Collaborator

@EriComic does this mean that without the SO_BINDTODEVICE, you aren't able to bind and connect to another device?

@EriComic
Copy link
Author

EriComic commented Oct 8, 2024

@duartenfonseca Specifically it is to bind to the interface instead of just binding to the IP like we normally do. After a lot of exhaustive research in trying to find a freeBSD alternative, we found that there sadly isn't a proper replacement for this. The functionality could be brought back but the implementation would be very use-case specific and would not belong here. It is worth noting is that QNX's port of vsomeip also deprecates the feature.

So we moved on to evaluating if the functionality is truly needed. As mentioned, this functionality allows binding to the interface instead of just the IP. This allows for things like:

  • Filtering traffic to a single interface in multi-interface systems where the interfaces share the same IP
  • Listen to traffic from an interface instead in cases where IPs have been changed/don't have an IP

These use cases (and ones like it) are so specialized that traditional IP binding wouldn't work. Therefore, we decided to deprecate the feature and leave re-implementation of it as an option for any party that needs it.

TL;DR No, this won't prevent binding and connecting to another device. The option for interface binding is removed which won't affect the more common IP binding. Interface binding is a very niche feature which we decided to drop due to it rarely being needed.

if (setsockopt(socket_->native_handle(),
SOL_SOCKET, SO_BINDTODEVICE, its_device.c_str(), static_cast<socklen_t>(its_device.size())) == -1) {
VSOMEIP_WARNING << "TCP Client: Could not bind to device \"" << its_device << "\"";
}
#else
VSOMEIP_WARNING << "TCP Client: Could not bind to device \"" << its_device << "\""
Copy link
Contributor

@goncaloalmeida goncaloalmeida Oct 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the changes seem ok, but why not use the normal logging? VSOMEIP_WARNING << "tcp_client_endpoint::connect:.." or VSOMEIP_WARNING <<"tcp_client_endpoint::" << func ""..

cc @duartenfonseca

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point and I had a few ideas on how to make this better as well, but I decided against it for the following reasons:

  1. The warning log that was already present in the code uses the same formatting I have currently, I believe it makes sense to adhere to what's already there. I believe best practice is to keep logging style/formatting changes in separate commits in order to maintain a "prettier git log".
  2. Having function signatures in logs is very useful for developers working on the library but it's too noisy for the user using the library. Your proposed log would make more sense for a DEBUG or TRACE level log. Perhaps in addition to the currently proposed WARNING log.

TL;DR I think your suggestion is good but only useful for the developer and not-so-much the user. If you would like the addition of this log as a DEBUG or TRACE, then please add it, but I believe our proposed WARNING should be there as it is.

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.

3 participants