Elide SocketFlags in Socket API

[i3arnon]

Fix #43934

[dotnet-issue-labeler]

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, to 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]

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

Issue Details

---

Fix #43934

Author:	i3arnon
Assignees:	-
Labels:	area-System.Net.Sockets, new-api-needs-documentation
Milestone:	-

[i3arnon]

I've left out ReceiveMessageFrom as the SocketFlags does return data from the operation:

runtime/src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketAsyncContext.Unix.cs

Line 1810 in 69de57b

flags = operation.ReceivedFlags;

[antonfirsov]

Thank you for the contribution! The implementation looks good.

What's worrying me that the overloads that elide SocketFlags are missing test coverage (both old and new ones). I think we should fix this as part of the current PR.

I believe it would be an overkill to address this by duplicating our tests a couple of more times by adding more SocketHelperBase subclasses, unnecessarily penalizing our test execution time. My recommendation would be to change the existing SocketHelperTask and SocketHelperSpanSync to elide SocketFlags in their calls to Socket. We aren't really testing the effect of SocketFlags in those tests anyways. @geoffkizer do you agree?

I've left out ReceiveMessageFrom as the SocketFlags does return data from the operation:

@geoffkizer do you think it's a useful overload regardless? The approved proposal is also questioning them: #43934 (comment)

[i3arnon]

My recommendation would be to change the existing SocketHelperTask and SocketHelperSpanSync to elide SocketFlags in their calls to Socket

Done.

@geoffkizer do you think it's a useful overload regardless? The approved proposal is also questioning them: #43934 (comment)

I'll add that also in the sync overloads, there's an overload for ReceiveFrom that elides the flags, which are not passed by ref, but there isn't one for ReceiveMessageFrom which passes the flags by ref.

[geoffkizer]

My recommendation would be to change the existing SocketHelperTask and SocketHelperSpanSync to elide SocketFlags in their calls to Socket. We aren't really testing the effect of SocketFlags in those tests anyways. @geoffkizer do you agree?

Just to be clear -- the idea here is that we cover these new overloads by making some of the existing test variations use them, but leave some using the old overloads so we continue to have coverage for those as well?

That seems reasonable to me.

Let's make sure to add comments that explain this, otherwise it will be far from obvious and we'll look at the code in the future and say "why are we using these overloads here but those overloads there??"

[geoffkizer]

I'll add that also in the sync overloads, there's an overload for ReceiveFrom that elides the flags, which are not passed by ref, but there isn't one for ReceiveMessageFrom which passes the flags by ref.

This is a strong argument for not eliding the flags on ReceiveMessageFrom.

[antonfirsov]

Just one thing, and this is good to merge. I think we should leave out the sync ReceiveMessageFrom.

[antonfirsov]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[antonfirsov]

LGTM. Shall be good to merge once outerloop CI completes.

[antonfirsov]

Outerloop failures are unrelated (#32955 and a bunch of ProcessStartInfo tests on Windows 11).

[antonfirsov]

@i3arnon thanks again for the work and your patience!