traves - ¿Cómo propagar las conexiones entrantes de tcplistener a través de subprocesos en.NET?

para que sirve invoke en c#

Question

Al usar Net.Sockets.TcpListener, ¿cuál es la mejor manera de manejar las conexiones entrantes (.AcceptSocket) en hilos separados?

La idea es comenzar un nuevo hilo cuando se acepte una nueva conexión entrante, mientras que el tcplistener permanece disponible para otras conexiones entrantes (y para cada nueva conexión entrante se crea un nuevo hilo). Toda la comunicación y la terminación con el cliente que originó la conexión se manejarán en el hilo.

Se aprecia el ejemplo C # del código VB.NET.

Answer 1

Creo que lo hace de la misma manera que cualquier otra operación asincrónica en .NET: llama a la versión BeginXxx del método, en este caso BeginAcceptSocket. Su devolución de llamada se ejecutará en el grupo de subprocesos.

Los subprocesos agrupados generalmente escalan mucho mejor que el subproceso por conexión: una vez que se superan unas pocas decenas de conexiones, el sistema trabaja mucho más para cambiar entre subprocesos que para realizar el trabajo real. Además, cada subproceso tiene su propia pila que suele tener un tamaño de 1 MB (aunque depende de los indicadores de enlace) que debe encontrarse en el espacio de direcciones virtuales de 2 GB (en sistemas de 32 bits); en la práctica, esto te limita a menos de 1000 hilos.

No estoy seguro de si el hilo de .NET lo usa actualmente, pero Windows tiene un objeto del kernel llamado puerto de finalización de E / S que ayuda a la E / S escalable. Puede asociar subprocesos con este objeto y las solicitudes de E / S (incluida la aceptación de conexiones entrantes) se pueden asociar a él. Cuando se completa una E / S (por ejemplo, llega una conexión), Windows lanzará un hilo en espera, pero solo si el número de subprocesos actualmente ejecutables (no bloqueados por algún otro motivo) es menor que el límite de escalabilidad configurado para el puerto de finalización. Por lo general, establecería esto en un pequeño múltiplo de la cantidad de núcleos.

Answer 2

Usaría un threadpool, de esta manera no tendrías que iniciar un nuevo thread cada vez (ya que esto es un poco caro). Tampoco esperaría indefinidamente para más conexiones, ya que los clientes pueden no cerrar sus conexiones. ¿Cómo planea enrutar al cliente al mismo hilo cada vez?

Lo siento, no tengo muestra.

Answer 3

Me gustaría sugerir un enfoque diferente: mi sugerencia utiliza solo dos hilos. * un hilo comprueba conexiones entrantes. * Cuando se abre una nueva conexión, esta información se escribe en una estructura de datos compartida que contiene todas las conexiones abiertas actuales. * El segundo subproceso enumera esa estructura de datos y para cada conexión abierta recibe los datos enviados y envía respuestas.

Esta solución es más escalable a nivel de subprocesos y, si se implementa correctamente, debería tener un mejor rendimiento que abrir un nuevo hilo por conexión abierta.

Answer 4

Hay un gran ejemplo en el libro de cocina O''Reilly C # 3.0. Puede descargar la fuente correspondiente desde http://examples.oreilly.com/9780596516109/CSharp3_0CookbookCodeRTM.zip

Answer 5

El código que he estado usando se ve así:

class Server
{
private AutoResetEvent connectionWaitHandle = new AutoResetEvent(false);
public void Start()
{
TcpListener listener = new TcpListener(IPAddress.Any, 5555);
listener.Start();
while(true)
{
IAsyncResult result = listener.BeginAcceptTcpClient(HandleAsyncConnection, listener);
connectionWaitHandle.WaitOne(); // Wait until a client has begun handling an event
connectionWaitHandle.Reset(); // Reset wait handle or the loop goes as fast as it can (after first request)
}
}
private void HandleAsyncConnection(IAsyncResult result)
{
TcpListener listener = (TcpListener)result.AsyncState;
TcpClient client = listener.EndAcceptTcpClient(result);
connectionWaitHandle.Set(); //Inform the main thread this connection is now handled
//... Use your TcpClient here
client.Close();
}
}