[API Proposal]: add overloads with SocketAddress to Socket's SendTo and ReceiveFrom

[wfurt]

Background and motivation

This is subset from #30797. There is long discussion about how to make sending and receiving UDP more efficient. Current overloads allocate a lot for each packet and that kills performance and it puts lot of pressure on GC. Garbage collection has significant impact on scenarios that are sensitive to timing - like multiplayer Unity games.

API Proposal

namespace System.Net.Sockets;

public class Socket
{
+  public int ReceiveFrom(Span<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress);
+  public ValueTask<int> ReceiveFromAsync(Memory<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress, CancellationToken cancellationToken = default);

+. public int SendTo(ReadOnlySpan<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress);
+. public ValueTask<int> SendToAsync(ReadOnlyMemory<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress, CancellationToken cancellationToken = default);
}

Instead of allocating and returning EndPoint, we can reuse SocketAddress and we would update it in place. Ideally using API proposed in #86872 but in worst case the SocketAddress is already writable and we can play some internal tricks.

API Usage

example of simple server that would process request - inspired by DNS server linked in #30797

  SocketAddress sa = new SocketAddress(AddressFamily.InterNetworkV6);
  while (doWork)
  {
      int receivedLength = s.ReceiveFrom(buffer, SocketFlags.None, sa);
      response = processRequest(buffer.Slice(0, receivedLength);
      s.SendTo(response, SocketFlags.None, sa);
  }

The async version would be basically same with addition of CancellationToken. Unlike ReceiveFromAsync that used EndPoint and returns SocketReceiveFromResult we would return ValueTask<int> just like the synchronous version and we would update socketAddress in-place.

Alternative Designs

No response

Risks

This is low-level API intended for experienced users. While there is nothing particularly dangerous one should be very careful about life cycle of the socketAddress as it can be overwritten on subsequent use.

[ghost]

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

Issue Details

---

Background and motivation

This is subset from #30797. There is long discussion about how to make sending and receiving UDP more efficient. Current overloads allocate a lot for each packet and that kills performance and it puts lot of pressure on GC. Garbage collection has significant impact on scenarios that are sensitive to timing - like multiplayer Unity games.

API Proposal

namespace System.Net.Sockets;

public class Socket
{
+  public int ReceiveFrom(Span<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress);
+  public ValueTask<int> ReceiveFromAsync(Memory<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress, CancellationToken cancellationToken = default);

+. public int SendTo(ReadOnlySpan<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress);
+. public ValueTask<int> SendToAsync(ReadOnlyMemory<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress, CancellationToken cancellationToken = default);
}

Instead of allocating and returning EndPoint, we can reuse SocketAddress and we would update it in place. Ideally using API proposed in #86872 but in worst case the SocketAddress is already writable and we can play some internal tricks.

API Usage

example of simple server that would process request - inspired by DNS server linked in #30797

  SocketAddress sa = new SocketAddress(AddressFamily.InterNetworkV6);
  while (doWork)
  {
      int receivedLength = s.ReceiveFrom(buffer, SocketFlags.None, sa);
      response = processRequest(buffer.Slice(0, receivedLength);
      s.SendTo(response, SocketFlags.None, sa);
  }

The async version would be basically same with addition of CancellationToken. Unlike ReceiveFromAsync that used EndPoint and returns SocketReceiveFromResult we would return ValueTask<int> just like the synchronous version and we would update socketAddress in-place.

Alternative Designs

No response

Risks

This is low-level API intended for experienced users. While there is nothing particularly dangerous one should be very careful about life cycle of the socketAddress as it can be overwritten on subsequent use.

Author:	wfurt
Assignees:	-
Labels:	api-suggestion, area-System.Net.Sockets
Milestone:	-

[terrajobst]

Video

• We don't like ReceiveFrom because it mutates the socket address

namespace System.Net.Sockets;

public partial class Socket
{
    // public int ReceiveFrom(Span<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress);
    // public ValueTask<int> ReceiveFromAsync(Memory<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress, CancellationToken cancellationToken = default);

    public int SendTo(ReadOnlySpan<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress);
    public ValueTask<int> SendToAsync(ReadOnlyMemory<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress, CancellationToken cancellationToken = default);
}

[fredrikhr]

Thinking about the ergonomics of receiving the SocketAddress I think the following proposal could make ReceiveFrom viable:

This basically adds ref for the SocketAddress parameter.

namespace System.Net.Sockets;

public partial class Socket
{
    public int ReceiveFrom(Span<byte> buffer, SocketFlags socketFlags, ref SocketAddress socketAddress);
    public ValueTask<int> ReceiveFromAsync(Memory<byte> buffer, SocketFlags socketFlags, ref SocketAddress socketAddress, CancellationToken cancellationToken = default);
}

[antonfirsov]

This has been considered, the problem is that ref doesn't play well with async.

[fredrikhr]

@antonfirsov can you elaborate on that? I just tried the signature with this in SharpLab https://sharplab.io/#gist:14ff035d0a0dec97365a6d992b47dfd9. What am I missing?

[antonfirsov]

ReceiveFromAsync would be only able to only mutate it on it's synchronous path. If you mark the method async, the compiler will complain. As a rule of thumb, async methods never take ref.

[fredrikhr]

Thanks for indulging in my ignorance. Makes perfect sense now! I am excited to see Levi's idea that he started to propose during API review.

[stephentoub]

We don't like ReceiveFrom because it mutates the socket address

Why is it a problem to mutate the SocketAddress? The whole point of this was to mutate it, thereby providing a way of achieving an allocation-free receive path. We have other methods that mutate arguments... why can't this one?

SocketAddress is just a strongly-typed buffer. Mutating buffers in read/receive methods is how things work.

[dersia]

We don't like ReceiveFrom because it mutates the socket address

Why is it a problem to mutate the SocketAddress? The whole point of this was to mutate it, thereby providing a way of achieving an allocation-free receive path. We have other methods that mutate arguments... why can't this one?

SocketAddress is just a strongly-typed buffer. Mutating buffers in read/receive methods is how things work.

during the meeting it came up that users might assume that ReceiveFrom would receive an address with the parameter and not expect for it to mutate. I general the problem wasn't that it is mutating, but that the name was misleading and therefor it was excluded for now.

at least that is what I understood from the meeting.

[stephentoub]

Thanks. To me that's an issue for documentation: the overload may write into the supplied buffers, both for the data received and for the address from which it was received.

I'd really like for these overloads to be in .NET 8. @bartonjs, @terrajobst, can we revisit this at the beginning of the next API review?

[terrajobst]

Video

• let's change the name of the parameter socketAddress to receivedAddress to make it clear that it will be mutated.

namespace System.Net.Sockets;

public partial class Socket
{
    public int ReceiveFrom(Span<byte> buffer, SocketFlags socketFlags, SocketAddress receivedAddress);
    public ValueTask<int> ReceiveFromAsync(Memory<byte> buffer, SocketFlags socketFlags, SocketAddress receivedAddress, CancellationToken cancellationToken = default);

    // Approved already
    // public int SendTo(ReadOnlySpan<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress);
    // public ValueTask<int> SendToAsync(ReadOnlyMemory<byte> buffer, SocketFlags socketFlags, SocketAddress socketAddress, CancellationToken cancellationToken = default);
}