fix SendTo with SocketAsyncEventArgs by wfurt · Pull Request #98134 · dotnet/runtime

wfurt · 2024-02-07T22:47:28Z

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 sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

ghost · 2024-02-07T22:47:37Z

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

Issue Details

this fixes regression from #90086 and fixes #97965.

With the new SocketAddress changes the task based IO worked because SendToAsync explicitly sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

Author:	wfurt
Assignees:	wfurt
Labels:	`area-System.Net.Sockets`
Milestone:	9.0.0

…syncEventArgs

stephentoub · 2024-02-13T03:09:08Z

+ finally
+ {
+ // detach user provided SA so we do not accidentally stomp on it later.
+ saea._socketAddress = null;


It's ok to null it here because it's only used synchronously as part of the send operation and not asynchronously?

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.

stephentoub · 2024-02-13T03:15:06Z

+ if (_remoteEndPoint == null)
+ {
+ // detach user provided SA as it was updated in place.
+ _socketAddress = null;


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?

yes. For SendTo we clear it when operation starts, for ReceiveFrom we do it when the operation is finished.

…syncEventArgs

wfurt · 2024-03-13T16:26:13Z

/backport to release/8.0-staging

github-actions · 2024-03-13T16:26:29Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8268148999

wfurt · 2024-02-07T22:47:28Z

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 sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

ghost · 2024-02-07T22:47:37Z

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

Issue Details

this fixes regression from #90086 and fixes #97965.

With the new SocketAddress changes the task based IO worked because SendToAsync explicitly sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

Author:	wfurt
Assignees:	wfurt
Labels:	`area-System.Net.Sockets`
Milestone:	9.0.0

…syncEventArgs

stephentoub · 2024-02-13T03:09:08Z

+ finally
+ {
+ // detach user provided SA so we do not accidentally stomp on it later.
+ saea._socketAddress = null;


It's ok to null it here because it's only used synchronously as part of the send operation and not asynchronously?

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.

stephentoub · 2024-02-13T03:15:06Z

+ if (_remoteEndPoint == null)
+ {
+ // detach user provided SA as it was updated in place.
+ _socketAddress = null;


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?

yes. For SendTo we clear it when operation starts, for ReceiveFrom we do it when the operation is finished.

…syncEventArgs

wfurt · 2024-03-13T16:26:13Z

/backport to release/8.0-staging

github-actions · 2024-03-13T16:26:29Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8268148999

wfurt · 2024-02-07T22:47:28Z

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 sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

ghost · 2024-02-07T22:47:37Z

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

Issue Details

this fixes regression from #90086 and fixes #97965.

With the new SocketAddress changes the task based IO worked because SendToAsync explicitly sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

Author:	wfurt
Assignees:	wfurt
Labels:	`area-System.Net.Sockets`
Milestone:	9.0.0

…syncEventArgs

stephentoub · 2024-02-13T03:09:08Z

+ finally
+ {
+ // detach user provided SA so we do not accidentally stomp on it later.
+ saea._socketAddress = null;


It's ok to null it here because it's only used synchronously as part of the send operation and not asynchronously?

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.

stephentoub · 2024-02-13T03:15:06Z

+ if (_remoteEndPoint == null)
+ {
+ // detach user provided SA as it was updated in place.
+ _socketAddress = null;


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?

yes. For SendTo we clear it when operation starts, for ReceiveFrom we do it when the operation is finished.

…syncEventArgs

wfurt · 2024-03-13T16:26:13Z

/backport to release/8.0-staging

github-actions · 2024-03-13T16:26:29Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8268148999

wfurt · 2024-02-07T22:47:28Z

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 sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

ghost · 2024-02-07T22:47:37Z

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

Issue Details

this fixes regression from #90086 and fixes #97965.

With the new SocketAddress changes the task based IO worked because SendToAsync explicitly sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

Author:	wfurt
Assignees:	wfurt
Labels:	`area-System.Net.Sockets`
Milestone:	9.0.0

…syncEventArgs

stephentoub · 2024-02-13T03:09:08Z

+ finally
+ {
+ // detach user provided SA so we do not accidentally stomp on it later.
+ saea._socketAddress = null;


It's ok to null it here because it's only used synchronously as part of the send operation and not asynchronously?

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.

stephentoub · 2024-02-13T03:15:06Z

+ if (_remoteEndPoint == null)
+ {
+ // detach user provided SA as it was updated in place.
+ _socketAddress = null;


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?

yes. For SendTo we clear it when operation starts, for ReceiveFrom we do it when the operation is finished.

…syncEventArgs

wfurt · 2024-03-13T16:26:13Z

/backport to release/8.0-staging

github-actions · 2024-03-13T16:26:29Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8268148999

wfurt · 2024-02-07T22:47:28Z

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 sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

ghost · 2024-02-07T22:47:37Z

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

Issue Details

this fixes regression from #90086 and fixes #97965.

With the new SocketAddress changes the task based IO worked because SendToAsync explicitly sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

Author:	wfurt
Assignees:	wfurt
Labels:	`area-System.Net.Sockets`
Milestone:	9.0.0

…syncEventArgs

stephentoub · 2024-02-13T03:09:08Z

+ finally
+ {
+ // detach user provided SA so we do not accidentally stomp on it later.
+ saea._socketAddress = null;


It's ok to null it here because it's only used synchronously as part of the send operation and not asynchronously?

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.

stephentoub · 2024-02-13T03:15:06Z

+ if (_remoteEndPoint == null)
+ {
+ // detach user provided SA as it was updated in place.
+ _socketAddress = null;


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?

yes. For SendTo we clear it when operation starts, for ReceiveFrom we do it when the operation is finished.

…syncEventArgs

wfurt · 2024-03-13T16:26:13Z

/backport to release/8.0-staging

github-actions · 2024-03-13T16:26:29Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8268148999

wfurt · 2024-02-07T22:47:28Z

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 sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

ghost · 2024-02-07T22:47:37Z

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

Issue Details

this fixes regression from #90086 and fixes #97965.

With the new SocketAddress changes the task based IO worked because SendToAsync explicitly sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

Author:	wfurt
Assignees:	wfurt
Labels:	`area-System.Net.Sockets`
Milestone:	9.0.0

…syncEventArgs

stephentoub · 2024-02-13T03:09:08Z

+ finally
+ {
+ // detach user provided SA so we do not accidentally stomp on it later.
+ saea._socketAddress = null;


It's ok to null it here because it's only used synchronously as part of the send operation and not asynchronously?

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.

stephentoub · 2024-02-13T03:15:06Z

+ if (_remoteEndPoint == null)
+ {
+ // detach user provided SA as it was updated in place.
+ _socketAddress = null;


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?

yes. For SendTo we clear it when operation starts, for ReceiveFrom we do it when the operation is finished.

…syncEventArgs

wfurt · 2024-03-13T16:26:13Z

/backport to release/8.0-staging

github-actions · 2024-03-13T16:26:29Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8268148999

wfurt · 2024-02-07T22:47:28Z

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 sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

ghost · 2024-02-07T22:47:37Z

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

Issue Details

this fixes regression from #90086 and fixes #97965.

With the new SocketAddress changes the task based IO worked because SendToAsync explicitly sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

Author:	wfurt
Assignees:	wfurt
Labels:	`area-System.Net.Sockets`
Milestone:	9.0.0

…syncEventArgs

stephentoub · 2024-02-13T03:09:08Z

+ finally
+ {
+ // detach user provided SA so we do not accidentally stomp on it later.
+ saea._socketAddress = null;


It's ok to null it here because it's only used synchronously as part of the send operation and not asynchronously?

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.

stephentoub · 2024-02-13T03:15:06Z

+ if (_remoteEndPoint == null)
+ {
+ // detach user provided SA as it was updated in place.
+ _socketAddress = null;


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?

yes. For SendTo we clear it when operation starts, for ReceiveFrom we do it when the operation is finished.

…syncEventArgs

wfurt · 2024-03-13T16:26:13Z

/backport to release/8.0-staging

github-actions · 2024-03-13T16:26:29Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8268148999

wfurt · 2024-02-07T22:47:28Z

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 sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

ghost · 2024-02-07T22:47:37Z

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

Issue Details

this fixes regression from #90086 and fixes #97965.

With the new SocketAddress changes the task based IO worked because SendToAsync explicitly sets saea._socketAddress to null. But there is no access to it for anybody using SocketAsyncEventArgs directly.

In the past, RemoteEndPoint was only user accessible variable and _socketAddress was always managed internally. With the new API SendTo and ReceiveFrom can use SocketAddress directly and reference would be also set on SocketAsyncEventArgs. 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 to null to indicate that SendTo and ReceiveFrom was invoked with user provided SocketAddress. We will also detach it from SocketAsyncEventArgs 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.

Author:	wfurt
Assignees:	wfurt
Labels:	`area-System.Net.Sockets`
Milestone:	9.0.0

…syncEventArgs

stephentoub · 2024-02-13T03:09:08Z

+ finally
+ {
+ // detach user provided SA so we do not accidentally stomp on it later.
+ saea._socketAddress = null;


It's ok to null it here because it's only used synchronously as part of the send operation and not asynchronously?

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.

stephentoub · 2024-02-13T03:15:06Z

+ if (_remoteEndPoint == null)
+ {
+ // detach user provided SA as it was updated in place.
+ _socketAddress = null;


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?

yes. For SendTo we clear it when operation starts, for ReceiveFrom we do it when the operation is finished.

…syncEventArgs

wfurt · 2024-03-13T16:26:13Z

/backport to release/8.0-staging

github-actions · 2024-03-13T16:26:29Z

Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/8268148999

fix SendTo with SocketAsyncEventArgs
50ac1c6

wfurt added the area-System.Net.Sockets label Feb 7, 2024

wfurt added this to the 9.0.0 milestone Feb 7, 2024

wfurt requested a review from a teamFebruary 7, 2024 22:47

wfurt self-assigned this Feb 7, 2024

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
9b1a4a9
…syncEventArgs

wfurt requested a review from stephentoub February 12, 2024 18:10

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

stephentoub approved these changes Feb 13, 2024
View reviewed changes

wfurt added 4 commits February 16, 2024 10:06

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
dc1453e
…syncEventArgs

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
e95b2fb
…syncEventArgs

feedback
412b66f

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
27ce02f
…syncEventArgs

build-analysisBot mentioned this pull request Feb 27, 2024
[browser][MT] Assert failed: Cannot find Promise for JSHandle -2 #98406
Closed

wfurt merged commit f9637f1 into dotnet:mainFeb 27, 2024

wfurt deleted the SocketAsyncEventArgs branch February 27, 2024 16:50

github-actionsBot mentioned this pull request Mar 13, 2024
[release/8.0-staging] fix SendTo with SocketAsyncEventArgs #99695
Merged

wfurt mentioned this pull request Mar 19, 2024
.net core 8 UDP Socket gets stuck on the first endpoint it sends to #99863
Closed

github-actionsBot locked and limited conversation to collaborators Apr 26, 2024

fix SendTo with SocketAsyncEventArgs
50ac1c6

wfurt added the area-System.Net.Sockets label Feb 7, 2024

wfurt added this to the 9.0.0 milestone Feb 7, 2024

wfurt requested a review from a teamFebruary 7, 2024 22:47

wfurt self-assigned this Feb 7, 2024

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
9b1a4a9
…syncEventArgs

wfurt requested a review from stephentoub February 12, 2024 18:10

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

stephentoub approved these changes Feb 13, 2024
View reviewed changes

wfurt added 4 commits February 16, 2024 10:06

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
dc1453e
…syncEventArgs

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
e95b2fb
…syncEventArgs

feedback
412b66f

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
27ce02f
…syncEventArgs

build-analysisBot mentioned this pull request Feb 27, 2024
[browser][MT] Assert failed: Cannot find Promise for JSHandle -2 #98406
Closed

wfurt merged commit f9637f1 into dotnet:mainFeb 27, 2024

wfurt deleted the SocketAsyncEventArgs branch February 27, 2024 16:50

github-actionsBot mentioned this pull request Mar 13, 2024
[release/8.0-staging] fix SendTo with SocketAsyncEventArgs #99695
Merged

wfurt mentioned this pull request Mar 19, 2024
.net core 8 UDP Socket gets stuck on the first endpoint it sends to #99863
Closed

github-actionsBot locked and limited conversation to collaborators Apr 26, 2024

fix SendTo with SocketAsyncEventArgs
50ac1c6

wfurt added the area-System.Net.Sockets label Feb 7, 2024

wfurt added this to the 9.0.0 milestone Feb 7, 2024

wfurt requested a review from a teamFebruary 7, 2024 22:47

wfurt self-assigned this Feb 7, 2024

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
9b1a4a9
…syncEventArgs

wfurt requested a review from stephentoub February 12, 2024 18:10

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

stephentoub approved these changes Feb 13, 2024
View reviewed changes

wfurt added 4 commits February 16, 2024 10:06

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
dc1453e
…syncEventArgs

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
e95b2fb
…syncEventArgs

feedback
412b66f

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
27ce02f
…syncEventArgs

build-analysisBot mentioned this pull request Feb 27, 2024
[browser][MT] Assert failed: Cannot find Promise for JSHandle -2 #98406
Closed

wfurt merged commit f9637f1 into dotnet:mainFeb 27, 2024

wfurt deleted the SocketAsyncEventArgs branch February 27, 2024 16:50

github-actionsBot mentioned this pull request Mar 13, 2024
[release/8.0-staging] fix SendTo with SocketAsyncEventArgs #99695
Merged

wfurt mentioned this pull request Mar 19, 2024
.net core 8 UDP Socket gets stuck on the first endpoint it sends to #99863
Closed

github-actionsBot locked and limited conversation to collaborators Apr 26, 2024

fix SendTo with SocketAsyncEventArgs
50ac1c6

wfurt added the area-System.Net.Sockets label Feb 7, 2024

wfurt added this to the 9.0.0 milestone Feb 7, 2024

wfurt requested a review from a teamFebruary 7, 2024 22:47

wfurt self-assigned this Feb 7, 2024

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
9b1a4a9
…syncEventArgs

wfurt requested a review from stephentoub February 12, 2024 18:10

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

stephentoub approved these changes Feb 13, 2024
View reviewed changes

wfurt added 4 commits February 16, 2024 10:06

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
dc1453e
…syncEventArgs

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
e95b2fb
…syncEventArgs

feedback
412b66f

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
27ce02f
…syncEventArgs

build-analysisBot mentioned this pull request Feb 27, 2024
[browser][MT] Assert failed: Cannot find Promise for JSHandle -2 #98406
Closed

wfurt merged commit f9637f1 into dotnet:mainFeb 27, 2024

wfurt deleted the SocketAsyncEventArgs branch February 27, 2024 16:50

github-actionsBot mentioned this pull request Mar 13, 2024
[release/8.0-staging] fix SendTo with SocketAsyncEventArgs #99695
Merged

wfurt mentioned this pull request Mar 19, 2024
.net core 8 UDP Socket gets stuck on the first endpoint it sends to #99863
Closed

github-actionsBot locked and limited conversation to collaborators Apr 26, 2024

fix SendTo with SocketAsyncEventArgs
50ac1c6

wfurt added the area-System.Net.Sockets label Feb 7, 2024

wfurt added this to the 9.0.0 milestone Feb 7, 2024

wfurt requested a review from a teamFebruary 7, 2024 22:47

wfurt self-assigned this Feb 7, 2024

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
9b1a4a9
…syncEventArgs

wfurt requested a review from stephentoub February 12, 2024 18:10

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

stephentoub approved these changes Feb 13, 2024
View reviewed changes

wfurt added 4 commits February 16, 2024 10:06

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
dc1453e
…syncEventArgs

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
e95b2fb
…syncEventArgs

feedback
412b66f

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
27ce02f
…syncEventArgs

build-analysisBot mentioned this pull request Feb 27, 2024
[browser][MT] Assert failed: Cannot find Promise for JSHandle -2 #98406
Closed

wfurt merged commit f9637f1 into dotnet:mainFeb 27, 2024

wfurt deleted the SocketAsyncEventArgs branch February 27, 2024 16:50

github-actionsBot mentioned this pull request Mar 13, 2024
[release/8.0-staging] fix SendTo with SocketAsyncEventArgs #99695
Merged

wfurt mentioned this pull request Mar 19, 2024
.net core 8 UDP Socket gets stuck on the first endpoint it sends to #99863
Closed

github-actionsBot locked and limited conversation to collaborators Apr 26, 2024

fix SendTo with SocketAsyncEventArgs
50ac1c6

wfurt added the area-System.Net.Sockets label Feb 7, 2024

wfurt added this to the 9.0.0 milestone Feb 7, 2024

wfurt requested a review from a teamFebruary 7, 2024 22:47

wfurt self-assigned this Feb 7, 2024

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
9b1a4a9
…syncEventArgs

wfurt requested a review from stephentoub February 12, 2024 18:10

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

stephentoub approved these changes Feb 13, 2024
View reviewed changes

wfurt added 4 commits February 16, 2024 10:06

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
dc1453e
…syncEventArgs

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
e95b2fb
…syncEventArgs

feedback
412b66f

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
27ce02f
…syncEventArgs

build-analysisBot mentioned this pull request Feb 27, 2024
[browser][MT] Assert failed: Cannot find Promise for JSHandle -2 #98406
Closed

wfurt merged commit f9637f1 into dotnet:mainFeb 27, 2024

wfurt deleted the SocketAsyncEventArgs branch February 27, 2024 16:50

github-actionsBot mentioned this pull request Mar 13, 2024
[release/8.0-staging] fix SendTo with SocketAsyncEventArgs #99695
Merged

wfurt mentioned this pull request Mar 19, 2024
.net core 8 UDP Socket gets stuck on the first endpoint it sends to #99863
Closed

github-actionsBot locked and limited conversation to collaborators Apr 26, 2024

fix SendTo with SocketAsyncEventArgs
50ac1c6

wfurt added the area-System.Net.Sockets label Feb 7, 2024

wfurt added this to the 9.0.0 milestone Feb 7, 2024

wfurt requested a review from a teamFebruary 7, 2024 22:47

wfurt self-assigned this Feb 7, 2024

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
9b1a4a9
…syncEventArgs

wfurt requested a review from stephentoub February 12, 2024 18:10

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

stephentoub approved these changes Feb 13, 2024
View reviewed changes

wfurt added 4 commits February 16, 2024 10:06

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
dc1453e
…syncEventArgs

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
e95b2fb
…syncEventArgs

feedback
412b66f

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
27ce02f
…syncEventArgs

build-analysisBot mentioned this pull request Feb 27, 2024
[browser][MT] Assert failed: Cannot find Promise for JSHandle -2 #98406
Closed

wfurt merged commit f9637f1 into dotnet:mainFeb 27, 2024

wfurt deleted the SocketAsyncEventArgs branch February 27, 2024 16:50

github-actionsBot mentioned this pull request Mar 13, 2024
[release/8.0-staging] fix SendTo with SocketAsyncEventArgs #99695
Merged

wfurt mentioned this pull request Mar 19, 2024
.net core 8 UDP Socket gets stuck on the first endpoint it sends to #99863
Closed

github-actionsBot locked and limited conversation to collaborators Apr 26, 2024

fix SendTo with SocketAsyncEventArgs
50ac1c6

wfurt added the area-System.Net.Sockets label Feb 7, 2024

wfurt added this to the 9.0.0 milestone Feb 7, 2024

wfurt requested a review from a teamFebruary 7, 2024 22:47

wfurt self-assigned this Feb 7, 2024

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
9b1a4a9
…syncEventArgs

wfurt requested a review from stephentoub February 12, 2024 18:10

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

Comment threadsrc/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs Outdated

stephentoub reviewed Feb 13, 2024
View reviewed changes

stephentoub approved these changes Feb 13, 2024
View reviewed changes

wfurt added 4 commits February 16, 2024 10:06

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
dc1453e
…syncEventArgs

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
e95b2fb
…syncEventArgs

feedback
412b66f

Merge branch 'main' ofhttps://github.com/dotnet/runtimeinto SocketA…
27ce02f
…syncEventArgs

build-analysisBot mentioned this pull request Feb 27, 2024
[browser][MT] Assert failed: Cannot find Promise for JSHandle -2 #98406
Closed

wfurt merged commit f9637f1 into dotnet:mainFeb 27, 2024

wfurt deleted the SocketAsyncEventArgs branch February 27, 2024 16:50

github-actionsBot mentioned this pull request Mar 13, 2024
[release/8.0-staging] fix SendTo with SocketAsyncEventArgs #99695
Merged

wfurt mentioned this pull request Mar 19, 2024
.net core 8 UDP Socket gets stuck on the first endpoint it sends to #99863
Closed

github-actionsBot locked and limited conversation to collaborators Apr 26, 2024

Uh oh!

Conversation

wfurt commented Feb 7, 2024• edited by karelz Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Feb 7, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wfurt commented Mar 13, 2024

Uh oh!

github-actionsBot commented Mar 13, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

wfurt commented Feb 7, 2024• edited by karelz Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Feb 7, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wfurt commented Mar 13, 2024

Uh oh!

github-actionsBot commented Mar 13, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

wfurt commented Feb 7, 2024• edited by karelz Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Feb 7, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wfurt commented Mar 13, 2024

Uh oh!

wfurt commented Feb 7, 2024•
edited by karelz
Loading

wfurt commented Feb 7, 2024•
edited by karelz
Loading

wfurt commented Feb 7, 2024•
edited by karelz
Loading

wfurt commented Feb 7, 2024•
edited by karelz
Loading