On 8/25/08, Herr Groucho <[EMAIL PROTECTED]> wrote: > 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.
ups... eso me pasa por leer por encima... antes de seguir contestando voy a leer el link que mando Fedux > > 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". -- Lautaro Serenity Now!!
