El Lunes, 25 de Agosto de 2008 14:38, Santiago Bosio escribió: > 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.
Realmente no esperan nada. Si no están conectados, se conectan y luego no hacen nada. Si a través del socket que conectaron les viene una consulta, la atienden, si no, no pasa nada. -- Herr Groucho ID Jabber: [EMAIL PROTECTED] Señal distintiva: LU5MJR - 144,550 MHz FM. Clave pública GPG: hkp://pks.lugmen.org.ar Fingerprint GPG: B7BD 0FC7 D9A2 66F3 4EFC 45EE 7DE2 3932 597B 6354
