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?

-- 
Herr Groucho

ID Jabber: [EMAIL PROTECTED]
Clave pública GPG: hkp://pks.lugmen.org.ar
Fingerprint GPG: B7BD 0FC7 D9A2 66F3 4EFC  45EE 7DE2 3932 597B 6354

Responder a