add support for parallel Connect

[wfurt]

this adds API approved in #87932. It seems like this only supports SAEA. We may consider extending it to be also supported with Task.

To limit possible risk, I added new member to existing and transient MultiConnectSocketAsyncEventArgs e.g. there should not be any penalty for Socket. We also originally discussed some split DNS query with @liveans and that can be possibly done separately. This is basic snapshot I crafted when hoping to squeeze this to 9.0.

Testing is tricky as it depends on DNS entries and particular behavior and speed.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[liveans]

I'm not sure about the behavior of Dns.Get* APIs with AddressFamily.Unspecified.
If it blocks until we get a response from both AddressFamily, then this might be problem here.

Because if either IPv6/IPv4 response is late or timeouts somehow, then it means we're delaying connection until we got both of the responses, this can be problematic for some specific cases.

But on the other hand with this approach, OS is implementing Destination Address Selection Algorithm for us, and we don't have code complexity here, if we decide to go to splitting DNS queries we might need to consider implementing Destination Address Selection Algorithm.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.

[liveans]

Mostly nits, otherwise looks fine to me.

[liveans]

/azp run runtime-libraries-coreclr outerloop

[antonfirsov]

I think there is a potential to simplify the code a lot and there may be also some overlooks which could result in bugs.

Given the complexity of the parallel connect logic, IMO it would be important to invest into extensive manual testing with a local DNS server setup. (Similarly to the one in the DnsClient tests.)

Had a offline discussion with Anton, he has some concerns which I agree.

[wfurt]

Based on the feedback and #116943 I decided to change the implementation quite a bit. mostly:

1. simplifies the logic by reusing the whole core method
2. adds split DNS
3. adds interlocked calls to dedicated SetResults method to take care of the racing.

[antonfirsov]

This form looks more maintainable than the previous one, but the failure should be resolved. I'm wondering if it's related to the seemingly premature return in the ParallelMultiConnectSocketState.SetResults success case?

[antonfirsov]

@wfurt I re-ran my test suite and the TestClient.ConnectTests.ConnectAsync_Parallel_FastestServerWins(hostNameVar: "HOST_V6_SINGLE_SLOW", expectedWinnerIpVar: "V6_SLOW") case is still failing. I think it's a pretty pretty basic case (resolver returning only IPv6 address) that should work.

[wfurt]

I'm not going to make it for 10.x. We passed cut of date and some tests from https://github.com/antonfirsov/SocketTest