Por lo que deduzco, el estado si su implementación es la siguiente:
Tienes un servidor y varios clientes. Cada cliente tiene una conexión con el servidor y el servidor maneja múltiples hilos, uno para cada cliente.
De aquí en adelante, tienes varias opciones.
- ¿Es posible reducir la latencia de una línea telefónica VOIP?
- ¿Qué es la subred?
- Cómo dominar el arte de las redes
- ¿Cuál es la relación entre la red informática y el sistema complejo, la ciencia de redes?
- Cómo restablecer un enrutador Zyxel
1) El servidor reenvía los mensajes
El servidor mantiene información sobre todas sus conexiones con los clientes y crea una asignación de usuario a socket. No necesita preocuparse por los puertos, porque son específicos de los sockets.
Ahora, cuando el servidor recibe un mensaje, puede ser de varios tipos: desconectar, enviar un mensaje a otro usuario, agregar un amigo, etc. Cuando el servidor recibe un mensaje destinado a otro usuario, simplemente puede consultar su tabla y redirigir ese mensaje al socket correspondiente.
Este es el enfoque más simple e ingenuo. Se escala extremadamente mal y simplemente fallará si alcanza un número razonable de clientes, porque está creando una carga muy alta en el servidor.
2) Los clientes hablan entre ellos
En lugar de confiar en el servidor para reenviar mensajes, los clientes pueden conectarse entre sí y no molestar al servidor en absoluto. Por supuesto, esto introduce cierta complejidad.
En primer lugar, cada cliente debe tener un hilo separado con la responsabilidad de escuchar las conexiones de otros clientes. Cuando un cliente remoto quiere chatear con el cliente local, se crea otro hilo para manejar la comunicación. Multithreading es necesario en cualquier caso, si desea poder chatear con varios clientes a la vez.
Lo bueno es que el servidor no necesita arbitrar este intercambio en absoluto. Pero hay un problema. ¿Cómo sabrá el cliente en qué puerto está escuchando el cliente remoto? Aquí viene el servidor.
Cuando se conecta al servidor, le proporciona información sobre usted, incluida la dirección IP y el puerto que está escuchando para otros clientes. Cuando un cliente remoto desea enviarle un mensaje, le pedirá esta información al servidor e iniciará una conexión directa con usted. Después de eso, todo se reduce a escribir mensajes en un socket.
El servidor solo necesita manejar mensajes de control: desconectar, solicitar información sobre otro cliente, etc. Esto elimina gran parte de la carga del servidor y le permite manejar un número significativamente mayor de clientes.
Algo extra para la escalabilidad:
Su servidor está creando actualmente un subproceso por cliente, lo que no es ideal. Todo el proceso es muy intensivo en IO, lo que significa que hay mucha espera para la entrada del usuario y no mucho procesamiento. ¿Por qué tantos hilos no hacen nada cuando podemos tener menos hilos sin hacer nada?
Un mejor enfoque es utilizar el patrón de diseño Thread Pool.
Puede considerar cada solicitud de un cliente, sea lo que sea, un “Trabajo” para ser ejecutado por el servidor. Luego puede crear una serie de subprocesos destinados a ejecutar estos trabajos, generalmente llamados “Trabajador”.
Los subprocesos de trabajo verificarán periódicamente una o varias colas para los trabajos que se ejecutarán. Si usa una cola compartida, deberá tener en cuenta la necesidad de sincronizar los hilos. Si usa una cola por subproceso, deberá crear una lógica para distribuir trabajos a cada cola.
Esto brinda mucha más flexibilidad, ya que la cantidad de subprocesos se puede modificar fácilmente en tiempo de ejecución, de acuerdo con sus necesidades. En caso de que tenga un tráfico abrumador, esto evita que su servidor muera porque puede limitar fácilmente la cantidad de subprocesos. No es que el otro enfoque no pueda hacer esto, pero limitar por trabajos en lugar de por el número de conexiones da un resultado mucho más preciso.
Un buen número de subprocesos podría ser el número de núcleos de procesamiento en su CPU. De todos modos, solo ese número de subprocesos puede ejecutarse simultáneamente, por lo que esto elimina la sobrecarga de cambio de contexto, lo que lo hace aún más escalable.
Te dejaré empaparte de todo esto y buscar optimizaciones aún mejores por tu cuenta. ¡Que te diviertas!
