¿Debería usar select () solo en el lado del cliente?

¿Qué te hace creer eso? Si tiene que mirar varios eventos IO a la vez en archivos u objetos similares, select () es la herramienta de elección. Eso es cierto tanto del lado del cliente como del servidor.

Del lado del servidor, generalmente se puede usar para esperar tanto los eventos de conexión en los zócalos de escucha como los datos reales en los conectados.

Por supuesto, hay otras formas: sondeo (), E / S asíncrona, hilos de bloqueo, etc.

El bloqueo de subprocesos es bastante popular en estos días (porque hace que la microprogramación de tareas se realice más fácilmente) pero los detalles puede complicarse

Elegir entre select () o poll () depende simplemente de los problemas de implementación del sistema operativo objetivo y solo es relevante con muchos descriptores de archivos.

select () es muy sencillo y, a menudo, una buena opción, y no hay una razón particular para evitarlo en el código del servidor. Solo asegúrese de no ingresar la manipulación de datos de larga duración en el hilo / proceso que ejecuta select (), porque la mayoría de las veces está en un bucle y debe volver a esperar el próximo evento.

Tuve exactamente el mismo dilema hace unas semanas. Intenté implementar una arquitectura de servidor cliente usando TCP, donde tuve que retransmitir mensajes del cliente (una GUI) a mi servidor (un back-end en C ++ que interactuaba con una radio XBee y actuaba como una puerta de entrada a una red de malla compuesta por XBees). Los mensajes eran comandos utilizados para controlar XBees. Estaba dividido entre el uso de subprocesos de selección frente a los de generación en el lado del servidor para cada conexión de cliente. La función de selección me pareció conveniente porque:

  • Solo tenía que hacer un procesamiento mínimo del mensaje en el lado del servidor. Era solo un simple reenvío a un puerto serie. Como el servidor estaba en una máquina poderosa (¡no en ningún dispositivo integrado!), Sentí que podía tomarme esta libertad.
  • Mi servidor no realizaba ninguna función de bloqueo. Era una simple escritura en un puerto serie conectado a un XBee.
  • Me salvó la máquina del lado del servidor de una sobrecarga considerable en caso de que muchos clientes se conectaran al servidor.
  • Como mi servidor también tenía que retransmitir mensajes del XBee al cliente, de todos modos tuve que hacer un seguimiento de un montón de descriptores de archivos abiertos. Esto complementó mi enfoque de selección de funciones. Si hubiera generado hilos, esto habría sido más complejo.

Lo único que debe tener en cuenta es la forma en que se maneja cuando un cliente se desconecta. Debe poner algo de lógica para manejar los descriptores de archivos incorrectos y también las conexiones abortadas.