Desbordamiento de pila al utilizar el modelo System.Net.Sockets.Socket.AcceptAsync

Question

Con respecto al método System.Net.Sockets.Socket.AcceptAsync de C# y .NET, se necesitaría uno para manejar un valor devuelto de "falso" para manejar el estado SocketAsyncEventArgs inmediatamente disponible desde la conexión procesada sincrónicamente. Microsoft proporciona ejemplos (que se encuentran en la página de la clase System.Net.Sockets.SocketAsyncEventArgs) que causarán un desbordamiento de la pila si hay una gran cantidad de conexiones pendientes, que pueden explotarse en cualquier sistema que implemente su modelo de manejo.

Otras ideas para evitar este problema son crear un bucle que llama al método del controlador, con la condición de que el valor Socket.AcceptAsync devuelve es igual a falso y romper el bucle (para permitir el procesamiento diferido) si el valor indica que la operación se está completando de forma asíncrona (verdadera). Sin embargo, esta solución también causa una vulnerabilidad de desbordamiento de pila debido al hecho de que la devolución de llamada asociada con SocketAsyncEventArgs pasada a Socket.AcceptAsync tiene al final del método, una llamada a Socket.AcceptAsync, que también tiene un bucle para conexiones inmediatamente disponibles, sincronizadas aceptadas .

Como puede ver, este es un problema bastante sólido, y aún no he encontrado una buena solución que no implique System.Threading.ThreadPool y la creación de toneladas de otros métodos y el procesamiento de la programación. Por lo que puedo ver, el modelo de socket asíncrono relacionado con Socket.AcceptAsync requiere más de lo que se demuestra en los ejemplos en MSDN.

¿Alguien tiene una solución limpia y eficiente para manejar conexiones inmediatamente pendientes que se aceptan sincrónicamente desde Socket.AcceptAsync sin tener que crear subprocesos separados para manejar las conexiones y sin utilizar la recursión?

Answer 1

No utilizaría AcceptAsync, sino más bien BeginAccept/EndAccept, e implementa correctamente el patrón asíncrono común, es decir, verificando CompletedSynchronously para evitar devoluciones de llamada en el hilo de devolución de llamada en las operaciones que se completaron.

Ver también AsyncCallBack CompletedSynchronously

---

Editar con respecto a la obligación de utilizar AcceptAsync:

El MSDN documentation dice explícitamente que la devolución de llamada no se invocará para las operaciones que completaban de forma sincrónica. Esto es diferente al patrón asíncrono común donde siempre se invoca la devolución de llamada.

Devuelve verdadero si la operación de E/S está pendiente. El evento SocketAsyncEventArgs.Completed en el parámetro e se generará al completar la operación . Devuelve falso si la operación de E/S completó de forma síncrona. El SocketAsyncEventArgs.Completed caso en el parámetro de correo no será levantado y el objeto e pasado como parámetro puede ser examinado inmediatamente después de la llamada al método vuelve a recuperar el resultado de la operación.

Actualmente no veo cómo un bucle no resolvería el problema de desbordamiento de pila. ¿Tal vez puede ser más específico sobre el código que causa el problema?

---

Edición 2: Estoy pensando en código como este (sólo en lo que respecta a AcceptAsync, el resto era sólo para obtener una aplicación de trabajo a intentarlo con):

static void Main(string[] args) { 
    Socket listenSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); 
    listenSocket.Bind(new IPEndPoint(IPAddress.Loopback, 4444)); 
    listenSocket.Listen(100); 
    SocketAsyncEventArgs e = new SocketAsyncEventArgs(); 
    e.Completed += AcceptCallback; 
    if (!listenSocket.AcceptAsync(e)) { 
     AcceptCallback(listenSocket, e); 
    } 
    Console.ReadKey(true); 
} 

private static void AcceptCallback(object sender, SocketAsyncEventArgs e) { 
    Socket listenSocket = (Socket)sender; 
    do { 
     try { 
      Socket newSocket = e.AcceptSocket; 
      Debug.Assert(newSocket != null); 
      // do your magic here with the new socket 
      newSocket.Send(Encoding.ASCII.GetBytes("Hello socket!")); 
      newSocket.Disconnect(false); 
      newSocket.Close(); 
     } catch { 
      // handle any exceptions here; 
     } finally { 
      e.AcceptSocket = null; // to enable reuse 
     } 
    } while (!listenSocket.AcceptAsync(e)); 
} 

Answer 2

No he mirado con cuidado, pero huele a esto podría ser útil (véase la sección denominada "buceo pila"):

http://blogs.msdn.com/b/mjm/archive/2005/05/04/414793.aspx

Answer 3

tengo resolvió este problema simplemente cambiando la ubicación del ciclo. En lugar de invocar recursivamente el controlador accept desde dentro de sí mismo, envolver el código en un ciclo do-while con la condición siendo "! Socket.AcceptAsync (args)" evita un desbordamiento de la pila.

El razonamiento detrás de esto es que utiliza el hilo de devolución de llamada para procesar las conexiones que están inmediatamente disponibles, antes de molestarse en esperar de forma asíncrona para que aparezcan otras conexiones. Está reutilizando un hilo agrupado, efectivamente.

Agradezco las respuestas, pero por alguna razón ninguno de ellos hizo clic en mí y realmente no resolvió el problema. Sin embargo, parece que algo allí activó mi mente para pensar en esa idea. Evita trabajar manualmente con la clase ThreadPool y no usa recursividad.

Por supuesto, si alguien tiene una mejor solución o incluso una alternativa, estaría encantado de escucharla.

Answer 4

newSocket.Send(Encoding.ASCII.GetBytes("Hello socket!")); 
newSocket.Disconnect(false); 
newSocket.Close(); 

El problema con este fragmento de arriba es que esto bloqueará su próxima operación de aceptación.

Una mejor manera es la siguiente:

while (true) 
{ 
    if (e.SocketError == SocketError.Success) 
    { 
     //ReadEventArg object user token 
     SocketAsyncEventArgs readEventArgs = m_readWritePool.Pop(); 
     Socket socket = ((AsyncUserToken)readEventArgs.UserToken).Socket = e.AcceptSocket; 

     if (!socket.ReceiveAsync(readEventArgs)) 
     ThreadPool.QueueUserWorkItem(new WaitCallback(ProcessReceiveEx), readEventArgs); . 
    } 
    else 
    { 
     HadleBadAccept(e); 
    } 

    e.AcceptSocket = null; 

    m_maxNumberAcceptedClients.WaitOne(); 
    if (listenSocket.AcceptAsync(e)) 
     break; 
}