-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
fix SendTo with SocketAsyncEventArgs #98134
Conversation
Tagging subscribers to this area: @dotnet/ncl Issue Detailsthis fixes regression from #90086 and fixes #97965. With the new SocketAddress changes the task based IO worked because In the past, With that I made changes to set
|
finally | ||
{ | ||
// detach user provided SA so we do not accidentally stomp on it later. | ||
saea._socketAddress = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's ok to null it here because it's only used synchronously as part of the send operation and not asynchronously?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes. We will make _socketAddress
before first try. f we do not finish synchronously on Unix, it would be copied to queued *SendOperation
. For Windows, the const sockaddr *lpTo
is IN for WSASendTo
and AFAIK it does not need to be preserved until the overlapped IO is completed.
src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs
Outdated
Show resolved
Hide resolved
if (_remoteEndPoint == null) | ||
{ | ||
// detach user provided SA as it was updated in place. | ||
_socketAddress = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only two operations it would be set for are ReceiveFrom and SendTo, and we already handled the SendTo case on the synchronous start path?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes. For SendTo we clear it when operation starts, for ReceiveFrom we do it when the operation is finished.
/backport to release/8.0-staging |
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8268148999 |
Fixes #97965 and #99863 -- a regression from PR #90086 (in 8.0).
With the new SocketAddress changes the task based IO worked because
SendToAsync
explicitly setssaea._socketAddress
tonull
. But there is no access to it for anybody usingSocketAsyncEventArgs
directly.In the past,
RemoteEndPoint
was only user accessible variable and_socketAddress
was always managed internally. With the new APISendTo
andReceiveFrom
can useSocketAddress
directly and reference would be also set onSocketAsyncEventArgs
. As I realized, 1) we should make no assumption about and and we should not try to use it for anything else than just the particular call and 2)SocketAsyncEventArgs
can be used directly so any related logic really needs to be at the bottom and not in the layers above.With that I made changes to set
RemoteEndPoint
tonull
to indicate thatSendTo
andReceiveFrom
was invoked with user providedSocketAddress
. We will also detach it fromSocketAsyncEventArgs
in that case so it can be re-used for another operations safely.On other cases we can keep it around and simply override
_socketAddress
as we see fit instead of allocating new one every time.