Alejandro Vargas escribió:
> El día 25 de agosto de 2008 16:35, Herr Groucho <[EMAIL PROTECTED]>
> escribió:
>> Con 10000 conexiones, tendría 10001 procesos. Es esta una estrategia
>> cuerda para manejar 10000 conexiones?
>
> ¿Y es imprescindible que se mantenga la conexión establecida
> permanentemente?
> Dada la cantidad de equipos y que no has manifestado
> preocupación por el ancho de banda,
Cada equipo genera 768 byes de datos cada 5 min, de los cuales interesará
leer la mitad salvo ocasiones especiales. Cada equipo tiene buffers no
volátiles para almacenar hasta 96 bloques de datos, que a razón de 1
bloque cada 5 min, permite tener pendientes de leer los datos generados
durante 8 horas.
Para que los equipos no estén todo el tiempo conectados, tendría que
hacerlos trabajar como servidores, no como clientes, pero en la mayoría de
los casos no se puede disponer de direcciones IP fijas así que usarlos
como servidores se complica.
Siendo clientes, para que no estén todo el tiempo conectados, tendría que
idear e implementar un algoritmo para decidir cuándo deberían conectarse
más sofisticado que el actual ("siempre"). Podría hacer que se quieran
conectar cada cierto tiempo y pernamezcan conectados mientras haya
actividad, o podría hacer que quisieran conectarse todo el tiempo y que
sea el servidor el que maneje cuántos se conectan realmente no aceptando
todas las conexiones, pero tampoco quiero derrochar tráfico con el
establecimiento y terminación de las conexiones TCP al pedo.
> supongo que no habrá una transmisión constante de datos.
768 bytes cada 5 min, de los cuales la mayoría de las veces sólo
interesará leer unos 480.
> Tal vez sea más sensato establecer la
> conexión, mandar el dato y cerrarla.
La ventaja de tenerlos conectados todo el tiempo (además de que es lo más
fácil de implementar) es el ahorro en tráfico al no derrocharse bytes en
establecer y terminar conexiones TCP.
> En ese caso se crearía un hijo
> para cada conexión pero se terminaría rápidamente. Podrías copiar el
> funcionamiento de Apache, que mantiene una cantidad de hijos corriendo
> por las dudas y les asigna trabajo a medida que llegan las
> comunicaciones.
"pre-fork". Pero eso es sólo para aumentar el rendimiento ahorrándose el
tiempo de ejecutar un fork. Acá no me parece que ese factor sea
determinante del desempeño, toda vez que los enlaces de datos de cada
equipo remoto son de 9,6 kbps (o quizás un poco más, dependiendo las
condiciones de la red), que sólo hay que procesar 480 bytes cada 5 min y
que de todos modos al equipo le lleva de 10 a 120 segundos reconectarse,
así que unos milisegundos menos en el servidor para que este esté listo
para aceptar la conexión me parecen irrelevantes.
> Por otro lado, un solo programa posiblemente pudiera hacer el trabajo,
> pero reducirías bastante la complejidad si no mantibieras las
> conexiones abiertas o si usaras UDP en lugar de TCP.
Sólo si los 10000 equipos escupieran los datos cuando los obtienen, por sí
solos, encapsulados dentro de un paquete UDP, que no es el caso. El
protocolo de aplicación es tal que a los equipos hay que mandarles una
pregunta para que devuelvan los datos, y en la pregunta se puede elegir
cuántos y cuáles datos.
> La calidad de las
> comunicaciones actuales hace que sea muy raro que se pierda un
> paquete.
Eso decíselo a Movistar, Claro o Personal... Sus redes GPRS pierden muchos
paquetes y tienen una latencia inmunda.
> Si te querés asegurar de que no se pierde nada implementás un
> mensaje de respuesta con un acuse de recibo, timeout y reenvío.
Sí, el protocolo de aplicación prevé eso.
> Claro
> que complica un poco el programa en el equipo emisor pero reduce el
> tamaño de los paquetes y creo que solucionaría el problema del
> servidor.
El sistema nació con los 10000 equipos en el rol de servidores. El
servidor se iba a conectar a ellos (a razón de unas pocas decenas cada
vez) y sacarle los datos que hiciera falta. Pero eso requería direcciones
IP fijas para que el servidor supiera a dónde ir a conectarse. Ese
servicio no está siempre disponible y hay que flexibilizar el sistema y al
hacerlo, me gustaría reescribir la menor cantidad de código de los equipos
embebidos.
--
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
