Unnecesary use of GCHandle in Windows Socket code

[wfurt]

This was reported by customer that application can crash with OoMs because memory can become highly fragmented because of small chunks of pinned memory. That generally points to socketAddress in ConnectEx. (used by Socket.ConnectAsync)

At the moment we hold the GCHandle even after the Connect is finished through life of the Socket. That can be fixed easily but furthermore it does not seems to be needed at all.

For ConnextEx and WSASendTo the socket address is documented as [In] and needs to be preserved only through initial call and not through life of the overlapped IO. (confirmed with Windows networking team) We can use simple fixed instead of allocating GCHandle and pinning the memory in heavy way.

The WSAReceiveFrom is different as the SocketAddress isout and sockerAddressLength is [in,out]. We may use NativeMemory for that as the current logic with caching GCHanlde may not work anyway. The ReceiveFrom will likely receive packets from various sources (for simple duplex simple Receive can be used) and we will keep allocating GCHandle for (almost) every packet.

While the first part should be easy to fix (and TCP gets most use) solving the UDP receiving may take some more effort. That would also contribute to #30797.

[ghost]

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

Issue Details

---

This was reported by customer that application can crash with OoMs because memory can become highly fragmented because of small chunks of pinned memory. That generally points to socketAddress in ConnectEx. (used by Socket.ConnectAsync)

At the moment we hold the GCHandle even after the Connect is finished through life of the Socket. That can be fixed easily but furthermore it does not seems to be needed at all.

For ConnextEx and WSASendTo the socket address is documented as [In] and needs to be preserved only through initial call and not through life of the overlapped IO. (confirmed with Windows networking team) We can use simple fixed instead of allocating GCHandle and pinning the memory in heavy way.

The WSAReceiveFrom is different as the SocketAddress isout and sockerAddressLength is [in,out]. We may use NativeMemory for that as the current logic with caching GCHanlde may not work anyway. The ReceiveFrom will likely receive packets from various sources (for simple duplex simple Receive can be used) and we will keep allocating GCHandle for (almost) every packet.

While the first part should be easy to fix (and TCP gets most use) solving the UDP receiving may take some more effort. That would also contribute to #30797.

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Sockets, os-windows
Milestone:	8.0.0