listen to both IPV6 and IPV4 incoming connections: binding to "::" implies using both protocols #1290
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.
Listen to both IPV4 and IPV6 incoming connections
Closes #1068
Why? Up to now the snapcast server only listens for IPV4 connections. This is a problem with clients that try a IPV6 connection first, and then do not quickly fall back to IPV4 (I think it was the Android snapclient app).
[x] This PR has been tested on Linux (Ubuntu).
Testing on Windows is not required - as per CMakeLists.txt the server is not built on Windows anyway.
A note on the code change: one could think of adding "::" to the list of addresses to listen to, like {{"0.0.0.0"}, {"::"}}
But that leads to a runtime error "address already in use", because the second list element, "::", implies binding to IPV4 as well, but that has already been done.
(You see the same when you configure both "0.0.0.0" and "::" as addresses in the config file, btw.)