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?
Tal como ya han sugerido otros en este thread, 1proceso/conexi?n
para este problema no es apropiado, y para el bajo ancho
de banda, un buen multiplexado "arriba" de epoll() funcar? ok.
>
> - 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?
Sip. En mi laburo tenemos m?quinas ~normales con kernels
convencionales que laburan con reg?menes de 10K-20K conexiones
"steady" sin drama.
> - Qu? le pasar? al consumo de memoria?
Asumiendo ~8K/socket conectado, 10K conn te dan ~80MB de memoria
de kernel + obviamente la aplicaci?n (la cual por cierto yo
la mlockall()ear?a ).
Ning?n n?mero que asuste para los hardwares de hoy.
> - 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)
Tal como ya se dijo en el thread, 1proceso+multiplex es muucho mejor
en este caso.
>
> - Varios sistemas operativos independientes, corriendo en m?quinas (reales
> o virtuales) separadas ejecutando cada uno alguno de los programas
> anteriores.
Justamente ESO estaba por plantearte: crecer "horizontalmente" (a menos
que apiles las m?quinas unas sobre otras :P ) en vez de "verticalmente"
(EL maquin?nn) y de paso evitar un SPOF.
Con lo anterior logr?s: balanceo de carga, resilencia y escalabilidad.
>
> Sugerencias?
>
LA implementaci?n podr?a ser: 1 (mejor 2) LVS en el frente, distribuyendo
las conexiones hacia los hosts que efectivamente corren el programa,
?stos a su vez deber?an entonces enviar la info hacia el repositorio
central, se me ocurre desde smtp (queueing+retry solucionado ;),
mysql c/replicaci?n ? simplemente nfs con una estructura de
directorios adecuada.
> --
> 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
>
Sal?/tty
--
--JuanJo
oO Juan Jose Ciarlante - juanjosec Ogmail.com - jjo O{um.edu.ar,google.com}
Oo gpg --keyserver wwwkeys.eu.pgp.net --recv-key 81276430
