Add Memory support to SendPacketElements

[geoffkizer]

Proposed API

namespace System.Net.Sockets
{
 public class SendPacketsElement
 {
 // Existing APIs:
 public SendPacketsElement(byte[] buffer);
 public SendPacketsElement(byte[] buffer, int offset, int count);
 public SendPacketsElement(byte[] buffer, int offset, int count, bool endOfPacket);

 public byte[]? Buffer { get; }
 public int Offset { get; }
 public int Count { get; }

 // Proposed APIs:
 public SendPacketsElement(ReadOnlyMemory<byte> buffer);
 public SendPacketsElement(ReadOnlyMemory<byte> buffer, bool endOfPacket);

 public ReadOnlyMemory<byte>? MemoryBuffer { get; }
 }
}

This is modeled on how we added Memory support to SocketAsyncEventArgs.

If you use a new Memory constructor overload, then:

• MemoryBuffer will return the ReadOnlyMemory that you passed to the constructor
• Buffer will return null
• Offset will return 0
• Count will return MemoryBuffer.Length

If you use an old byte[] constructor overload, then:

• MemoryBuffer will return a ReadOnlyMemory constructed from the byte[], offset, and count you passed to the constructor.
• Buffer, Offset, and Count will return the values you passed to the constructor (as today)

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

Issue Details

---

Proposed API

namespace System.Net.Sockets
{
 public class SendPacketsElement
 {
 // Existing APIs:
 public SendPacketsElement(byte[] buffer);
 public SendPacketsElement(byte[] buffer, int offset, int count);
 public SendPacketsElement(byte[] buffer, int offset, int count, bool endOfPacket);

 public byte[]? Buffer { get; }
 public int Offset { get; }
 public int Count { get; }

 // Proposed APIs:
 public SendPacketsElement(ReadOnlyMemory<byte> buffer);
 public SendPacketsElement(ReadOnlyMemory<byte> buffer, bool endOfPacket);

 public Memory<byte>? MemoryBuffer { get; }
 }
}

This is modeled on how we added Memory support to SocketAsyncEventArgs.

If you use a new Memory constructor overload, then:

• MemoryBuffer will return the Memory that you passed to the constructor
• Buffer will return null
• Offset will return 0
• Count will return MemoryBuffer.Length

If you use an old byte[] constructor overload, then:

• MemoryBuffer will return a Memory constructed from the byte[], offset, and count you passed to the constructor.
• Buffer, Offset, and Count will return the values you passed to the constructor (as today)

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

[scalablecory]

• MemoryBuffer will return a ReadOnlyMemory constructed from the byte[], offset, and count you passed to the constructor.

if this is the case, there's no reason for the MemoryBuffer property to be nullable.

[gfoidl]

MemoryBuffer property to be nullable

Besides that it shouldn't be nullable anyway. If not set, it's default, so IsEmpty will return true.
So to work with the check for IsEmpty or HasValue has to be done in either way.

But this is superceded by @scalablecory's comment.

[geoffkizer]

if this is the case, there's no reason for the MemoryBuffer property to be nullable.

SendPacketElements can also be a file (or file segment). In that case, MemoryBuffer will return null, as Buffer does today.

[gfoidl]

...or MemoyBuffer will just be empty (instead of being null).

For span-overloads if no data is given, they're empty and we don't have nullable spans as arguments where null means void.
Same for other memory-overloads. I see this case in the same vein.

[geoffkizer]

I see this case in the same vein.

I think it's different. In this case you're not using a Memory at all; you are using a file.

[geoffkizer]

See https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.socketasynceventargs.memorybuffer?view=net-5.0

[gfoidl]

Ah, ok there it is also nullable, so it should be the same here.
You're right.