On Mon, Aug 25, 2008 at 11:35:16AM -0300, Herr Groucho 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? > > -- > 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
Faltan un detalle, saber que tipo de trabajo va a tener el servidor. Si las 10000 conexiones son para pasar mensajes chicos no pasa nada, pero si las conexiones implican cosas mas pesadas como conexiones a base de datos ahi hay que pensarlo mejor. A mi me gusta usar libevent para estas cosas, es muy simple y practica. Ademas elige el metodo de multiplexado de conexiones acorde a la plataforma. En linux hoy en dia lo mejor es usar epoll() no select(). -- -------------- Diego Woitasen
