This repository was archived by the owner on Jan 23, 2023. It is now read-only.
use dual mode sockets in cases when address family is not set explicitly #30036
Conversation
This file contains 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
|
@dotnet-bot help |
|
Welcome to the dotnet/corefx Repository The following is a list of valid commands on this PR. To invoke a command, comment the indicated phrase on the PR The following commands are valid for all PRs and repositories. Click to expand
The following jobs are launched by default for each PR against dotnet/corefx:master. Click to expand
The following optional jobs are available in PRs against dotnet/corefx:master. Click to expand
Have a nice day! |
|
seems like failures are infrastructure: null pointer java exception. |
|
@dotnet-bot test Outerloop Windows x64 Debug Build |
Changing UDPClient should be a separate issue/PR.
I think this is a good approach and unlikely to break existing customers using TcpClient(). |
|
most failures are caused by infrastructure. However new test is failing on NETFX/Windows 10. |
This new test needs a SkipOnTargetFramework for NETFX since .NET Framework will still have the original behavior. |
|
How about updating test to check what socket was created? In that case we could test both possibilities instead of disabling the test. |
stephentoub
approved these changes
Jun 4, 2018
OK |
…t case it will simply verify that TcpClient without explicit AF can be created without exception.
|
Windows failures in System.Net.Security seems unrelated to this PR. |
|
@dotnet-bot test Outerloop Windows x64 Debug Build |
|
System.Net.Security failure is known issue: #30028 cc: @stephentoub |
caesar-chen
approved these changes
Jun 4, 2018
picenka21
pushed a commit
to picenka21/runtime
that referenced
this pull request
Feb 18, 2022
…tly (dotnet/corefx#30036) * use dual mode sockets in cases when address family is not set explicitly * update test so it does not fail on platforms without DualMode. In that case it will simply verify that TcpClient without explicit AF can be created without exception. Commit migrated from dotnet/corefx@4c86e8f
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
fixes dotnet/runtime#26036 Classes inheriting TcpClient or Sockets don't function using correct IP by default.
in essence, this change allows to connect either to IPv4 or IPv6 when instantiated without specific address family. This is done by using dual mode socket if possible or falling back to IPv4 to match existing behavior.
Note that UDPClient has same problem. I can add it to this PR if we agree on approach or I can open new issue far that.
Aside from added unit test, I also tried to run sample test code from the issue.