-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Reusing the same SocketAsyncEventArgs for different udp remote endpoints does not work anymore #97965
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsDescriptionIt has been introduced in .NET 8 that the This is what is going on in .NET 8: This is the previous same file in .NET 7: When comparing the two files, it seems that, if one changes the remote endpoint and calls e.g. Reproduction Steps
Expected behaviorIt is expected that consequitive calls to e.g. Actual behaviorAll consequitive calls to e.g. Regression?This worked fine in .NET 7. Known WorkaroundsI made the following PR in NetCoreServer in case the re-use of SocketAsyncEventArgs for different remote endpoints is in fact not legal, see: chronoxor/NetCoreServer#284 ConfigurationNo response Other informationNo response
|
cc: @wfurt |
I'll take a look. |
May I ask whether this was triaged to be a regression in .NET 8 or if the use of |
it is certainly unintended regression @rmja and the linked code looks fine to me. I should have PR up today to fix it. Once fixed and merged to main, we can reopen it for servicing request. I'm not sure what exact timing it would be. |
re-opening for backport |
@wfurt do we know when it will be available in 8.0.x? any approximation |
the fix missed 8.0.5 by day or so ;( |
:( we just updated our services to .NET 8 and found this issue, now in spot. Any workaround? |
use fresh |
@wfurt Is this included in .NET 8.0.6 - May 28, 2024 |
no, my post had wrong version e.g. it missed 8.0.6 and it should be out mid June. |
8.0 fixed by #99695. it should be out in 8.0.7 |
Description
It has been introduced in .NET 8 that the
_socketAddress
inside theSocketAsyncEventArgs
is only serialized if it is null. This means that it is only serialized the first time theSocketAsyncEventArgs
is used for a socket operation. However, e.g. in https://github.com/chronoxor/NetCoreServer/blob/master/source/NetCoreServer/UdpServer.cs#L692-L694 theSocketAsyncEventArgs
is used multiple times for different remote endpoints.This is what is going on in .NET 8:
https://github.com/dotnet/runtime/blob/v8.0.1/src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs#L3098-L3107
This is the previous same file in .NET 7:
https://github.com/dotnet/runtime/blob/v7.0.15/src/libraries/System.Net.Sockets/src/System/Net/Sockets/Socket.cs#L3027
When comparing the two files, it seems that, if one changes the remote endpoint and calls e.g.
Socket.SendToAsync()
then it will not re-serialize the_socketAddress
and the payload will not be transmitted to the socket address of the newly configured remote endpoint - instead they whill be transmitted to the first configured remote endpoint.Reproduction Steps
var ea = SocketAsyncEventArgs
.ea.RemoteEndPoint = firstEndpoint
.socket.SendToAsync(ea)
.firstEndpoint
, now set a different remote endpointea.RemoteEndpoint = secondEndpoint
socket.SendToAsync(ea)
.secondEndpoint
, it is sent to the oldfirstEndpoint
which is clearly not correct.Expected behavior
It is expected that consequitive calls to e.g.
Socket.SendToAsync()
with the same instance ofSocketAsyncEventArgs
but with reconfiguredRemoteEndpoint
, actually transmits to different endpoints.Actual behavior
All consequitive calls to e.g.
Socket.SendToAsync()
are transmitted to the remote endpoint configured whenSocket.SendToAsync()
is first called. This is verified in wireshark.Regression?
This worked fine in .NET 7.
Known Workarounds
I made the following PR in NetCoreServer in case the re-use of SocketAsyncEventArgs for different remote endpoints is in fact not legal, see: chronoxor/NetCoreServer#284
Configuration
No response
Other information
No response
The text was updated successfully, but these errors were encountered: