We can probably improve this this by ditching SAEA and use _socket.AcceptAsync(null, cancellationToken) instead. The SAEA would be managed by the method and all pending accept command can be cancelled using the token.

Is that .NET 6 only?

Not sure, I can see the code in .NET 5.0, would have to check the .NET Standard API to see if its there

Nope, not available in .NET Standard 2.0. Introduced in .NET 5.0.

We can do an #if #endif for that in the .NET 6 version in Akka.NET v1.5 then

I'm working with this issue and find that TcpListener and its PullMode params:
_acceptLimit = bind.PullMode ? 0 : _tcp.Settings.BatchAcceptLimit;
probably doesn't work as expected.
If it mean that TcpListener should accept new connection only on Pull, then it doesn't work in this way. It will accept any new connection once it has accepted connection:

                case SocketEvent evt:
                    var saea = evt.Args;
                    if (saea.SocketError == SocketError.Success)
                        Context.ActorOf(Props.Create<TcpIncomingConnection>(_tcp, saea.AcceptSocket, _bind.Handler, _bind.Options, _bind.PullMode).WithDeploy(Deploy.Local));
                    
                    saea.AcceptSocket = null;
                    if (!_socket.AcceptAsync(saea))
                        Self.Tell(new SocketEvent(saea));
                    return true;

_socket.AcceptAsync will be called automatically after accepting current connection.

Do we need to change it to real pull mode?

Second question about io.tcp.batch-accept-limit setting. It manages size of array of SocketAsyncEventArgs in TcpListener and documentations says:

The maximum number of connection that are accepted in one go,
higher numbers decrease latency, lower numbers increase fairness on
the worker-dispatcher
batch-accept-limit = 10

If we take a look at MSDN example of SocketAsyncEventArgs usage at this page we can see that it use only one object for socket.AcceptAsync() because its usage is very short and all io operations is performed on connected socket:

SocketAsyncEventArgs readEventArgs = m_readWritePool.Pop();
readEventArgs.UserToken = e.AcceptSocket;

// As soon as the client is connected, post a receive to the connection
bool willRaiseEvent = e.AcceptSocket.ReceiveAsync(readEventArgs);

Moreover, we have this code in TcpListener

case SocketEvent evt:
    var saea = evt.Args;
    if (saea.SocketError == SocketError.Success)
        Context.ActorOf(Props.Create<TcpIncomingConnection>(_tcp, saea.AcceptSocket, _bind.Handler, _bind.Options, _bind.PullMode).WithDeploy(Deploy.Local));
                    
    saea.AcceptSocket = null;
    if (!_socket.AcceptAsync(saea))
        Self.Tell(new SocketEvent(saea));
    return true;

If usage of SAEA is very short in fact we can use only one element of array SAEA.
My proposal is to remove array of SAEA and mark io.tcp.batch-accept-limit setting as obsolete. Then create single SAEA object and hardly use it inside TcpListener.

We can't reduce the SAEA to a single SAEA. The point of using asynchronous event model is to make sure that the server socket can accept multiple incoming connection asynchronously without blocking.

This is described in the MS documentation:

In the new System.Net.Sockets.Socket class enhancements, asynchronous socket operations are described by reusable SocketAsyncEventArgs objects allocated and maintained by the application. High-performance socket applications know best the amount of overlapped socket operations that must be sustained. The application can create as many of the SocketAsyncEventArgs objects that it needs. For example, if a server application needs to have 15 socket accept operations outstanding at all times to support incoming client connection rates, it can allocate 15 reusable SocketAsyncEventArgs objects for that purpose.

I'm working with this issue and find that TcpListener and its PullMode params: _acceptLimit = bind.PullMode ? 0 : _tcp.Settings.BatchAcceptLimit; probably doesn't work as expected. If it mean that TcpListener should accept new connection only on Pull, then it doesn't work in this way. It will accept any new connection once it has accepted connection:

                case SocketEvent evt:
                    var saea = evt.Args;
                    if (saea.SocketError == SocketError.Success)
                        Context.ActorOf(Props.Create<TcpIncomingConnection>(_tcp, saea.AcceptSocket, _bind.Handler, _bind.Options, _bind.PullMode).WithDeploy(Deploy.Local));
                    
                    saea.AcceptSocket = null;
                    if (!_socket.AcceptAsync(saea))
                        Self.Tell(new SocketEvent(saea));
                    return true;

_socket.AcceptAsync will be called automatically after accepting current connection.

Do we need to change it to real pull mode?

Wouldn't AcceptAsync() be actually needed to start the socket? It just returns a bool to signal if the connection has been accepted, if false then then connection is still being negotiated (handshake) and we can't use the socket yet.

We can't reduce the SAEA to a single SAEA. The point of using asynchronous event model is to make sure that the server socket can accept multiple incoming connection asynchronously without blocking.

Ok, i was confused by MS example in the same post.

Wouldn't AcceptAsync() be actually needed to start the socket? It just returns a bool to signal if the connection has been accepted, if false then then connection is still being negotiated (handshake) and we can't use the socket yet.

Yes, but after you call AcceptAsync(saea) you ready to accept new connection and it would be accepted and processed because you have Completed handler. It doesn't wait for next Pull. Take a look:

                case SocketEvent evt:
                    var saea = evt.Args;
                    if (saea.SocketError == SocketError.Success)
                        Context.ActorOf(Props.Create<TcpIncomingConnection>(_tcp, saea.AcceptSocket, _bind.Handler, _bind.Options, _bind.PullMode).WithDeploy(Deploy.Local));
                    
                    saea.AcceptSocket = null;
                    if (!_socket.AcceptAsync(saea))
                        Self.Tell(new SocketEvent(saea));

SocketEvent here means we already got a connection, but we call AcceptAsync(saea) and Self.Tell(new SocketEvent(saea)); in the same handler, we don't wait for Pull. Do we need to change it to real Pull mode?