Herr Groucho escribió: > Hola. > Para resolver un problema, se me ha planteado la necesidad de hacer un > programa que acepte conexiones TCP desde equipos embebidos y les lea datos > que dichos equipos están recabando en campo. > > Actualmente el programa de esos equipos embebidos establece la conexión > TCP y la mantiene conectada todo el tiempo. Entonces el servidor que > acepta esas conexiones va a tener un socket conectado con cada equipo todo > el tiempo. Si hay 10 equipos, tendrá 10 conexiones abiertas. Pero qué pasa > cuando hay 10000 equipos y por lo tanto 10000 conexiones? > > El programa que va a aceptar las conexiones actualmente lanza un proceso > hijo por cada conexión que acepta. Eso tiene la ventaja de que el > tratamiento de TCP/IP y la implementación del protocolo de aplicación se > simplifica (sólo hay un socket del cual preocuparse y si el protocolo de > aplicación tiene que esperar un evento, directamente se puede bloquear en > un read() o write() o irse a dormir con timeout en un select()). > Con 10000 conexiones, tendría 10001 procesos. Es esta una estrategia > cuerda para manejar 10000 conexiones? > > - El sistema operativo soportará 10000 procesos (hace unos años el tamaño > de la tabla de procesos era elegido en tiempo de compilación del kernel, > en valores miserables como 200)? > - El stack TCP/IP soportará 10000 conexiones? > - Qué le pasará al consumo de memoria? > - Qué le pasará al multitasking si el scheduler tiene que mirar una tabla > de procesos tan grande cada unas pocas decenas de milisegundos? > > > Qué otras estrategias son concebibles? > - Un único proceso que atienda y maneje todas las conexiones, usando > arreglos para guardar los file descriptors de los sockets, select() para > esperar que pase algo interesante en alguno de ellos e iteraciones por > todos lados? > > - Un proceso que lance hijos, cada uno de los cuales maneje unos pocos > threads (un híbrido entre los 2) > > - Varios sistemas operativos independientes, corriendo en máquinas (reales > o virtuales) separadas ejecutando cada uno alguno de los programas > anteriores. > > Sugerencias? > > Groucho:
Más allá de que un kernel tuviera la capacidad (o pudiera recompilarse para que las tenga), 10000 conexiones ya sean atendidas por procesos independientes o por threads, me parece algo que puede tornarse inmanejable para una sola máquina. Creo que antes que todo, habría que ver cómo se comportan estos equipos embebidos que transmiten datos. Por ejemplo, si la transmisión de datos es esporádica, manteniéndose las conexiones la mayoría del tiempo en espera, y los equipos embebidos intentan una reconexión cuando la conexión TCP con el receptor se interrumpe, una política plausible sería utilizar temporizadores para cerrar conexiones no utilizadas en un cierto lapso de tiempo. O incluso cerrarlas luego de aceptar un paquete de datos. Pero todo dependerá obviamente de cómo se transmiten esos datos sobre TCP. De esta manera se puede controlar cuántas conexiones simultáneas (y por ende procesos o threads) se crean. El resto de las conexiones irán siendo aceptadas en la medida que se vayan desocupando otras. Pero como te digo, todo depende de qué es lo que esperan del otro lado estos equipos embebidos, y de las cantidades de datos que se transmiten simultáneamente. Saludos, Santiago.
