Can the .NET framework handle non-blocking socket operations more efficiently?

[AliKhalili]

In the Socket library, we can use non-blocking I/O operations with SocketAsyncEventArgs, which is managed by an event loop. This loop checks with the OS to see if any socket is ready for reading or writing(get notifications from epoll|kqueue). When a socket is ready, it is added to a queue(_eventQueue), and another thread dequeues it to execute the socket callback, regardless of how many bytes are read, for example.

In some data protocols, we already know the length of the messages, so we can avoid executing the callback if we haven't received enough bytes on a particular socket. We can use ioctl with FIONREAD to check the available bytes after receiving a readiness notification. This way, we can skip unnecessary callback execution and reduce the pressure on the thread scheduler.

I just want to ask what you think about this approach. Is this something that could be handled within the framework rather than in the application code?

[gfoidl]

@wfurt can you please take a look here?

[wfurt]

This is tricky business. Not reading the buffer can for example impact TCP windows. In corner case the Windows can string to 0 and whole flow can stall. So there may be more to it. There is no good low-level primitive to communicate how much data you want. NetworkStream has ReadAtLeast but that is really just a wrapper around Read.

You can experiment with DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS and look at #72153 and #59157.
There is probably more work to be done but having specific workload and example may help to move it forward.

Also you mentioned Framework but the link points to Core (even if we do not call it Core any more)