Lautaro Cozzani escribió: > On 8/25/08, Herr Groucho <[EMAIL PROTECTED]> wrote: >> 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? > > No se si podras usar la funcion select[1] de C para sockets, pero es > justamente para eso.
Sí, select() está mencionado entre una de las opciones en lo que escribí más arriba. La pregunta es por qué debería usar esa opción en lugar de las otras. Otra opción que no mencioné porque me parece que es lo mismo que usar fork() es usar threads, ya que para Linux, los threads igual ocupan entradas en la tabla de procesos pues los ve como "procesos tomados con liviandad". -- 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
