El Jueves, 28 de Agosto de 2008 04:37, Alejandro Vargas escribió: > El día 26 de agosto de 2008 21:15, Herr Groucho <[EMAIL PROTECTED]> escribió: > > Me perdería la capacidad de tener al equipo en línea para > > mandarle un comando, ver su configuración o estado en un momento > > arbitrario, accederlo desde otro host, etc. pero lo fundamental > > andaría. > > Bueno, podés hacer que de vez en cuando se comuniquen igual aunque > no tengan nada que mandar. De esa forma, si un equipo no se ha > "reportado" en un determinado tiempo podés dar algun tipo de > alarma. > > > Luego tendría que implementar un comando para que esos bits sean > > manipulables por el servidor. > > Dijiste que tenías un protocolo para mandar y confirmar envío de > paquetes. Podés hacer que si el envío fue confirmado lo marque.
No, el protocolo de comunicación debe permanecer libre de otras funcionalidades aparte de la de hacer accesible el modelo de datos con el que el equipo representa su funcionalidad. En todo caso enriquezco ese modelo de datos para que exporte la funcionalidad necesaria para marcar bloques y que el servidor accesa a esa funcionalidad usando el protocolo sin que el protocolo haya cambiado en lo más mínimo. A través del protocolo, el equipo se vé como un arreglo de registros de 16 bits, y el protocolo ofrece funciones para leer y escribir esos registros sueltos o en grupo de diversas formas. Yo podría agregar unos registros legibles y escribibles que en cada bit representen el estado de "ya visto/nuevo" de cada uno de los bloques de datos y con las funciones de lectura y escritura existentes en el protocolo obtener el valor de esos bits o alterarlos. Pero en realidad la idea que creo que se va a implementar es otra. Para darle máximo control al servidor de cuándo debería reconectase, el servidor antes de mandar el comando de desconectar del cual ya hablé en otro mensaje (mandar un comando es escribir un 1 en uno de los bits de uno de los registros presentados por el equipo, que le indica al equipo que el comando asociado a ese bit está pendiente de ejecución), escribirá en otro registro un tiempo de espera antes de reconectarse. Entonces el servidor le va a estar diciendo al equipo "no me rompás las pelotas por 15 min", y ese tiempo puede ser elegido dinámicamente según muchos factores: carga del sistema, urgencia por hablar con un módulo que por alguna razón no se estuvo comunicando fiablemente y que se esté quedando sin buffers para los datos, prioridad del cliente que paga por ese enlace respecto de otros, etc. > Por > otro lado, si hacés que se comunique "por las dudas" de vez en > cuando, ahí el servidor puede aprovechar para pedirle otras cosas. Las comunicaciones "por las dudas" son posibles con el esquema de decirle "no te reconectés hasta dentro de n minutos". > Tal vez se pueda simplificar más: el equipo se conecta "por las > dudas". El servidor, que es el que realmente sabe si tiene algo que > pedir o no, lo pide y al finalizar la conexión le manda una señal > para setear un flag. Ese flag le dice al equipo que no tiene que > comunicarse más hasta digamos dentro de media hora. Sin embargo, si > el equipo agrega un nuevo bloque de datos, limpia ese flag, y eso > hace que se conecte más pronto. Bueno, en lugar de un bit, que sean 16, y que un bit elija que se reconecte en 1 min, otro en 2, otro en 4 y así, y que si hay varios de esos bits encendidos, se sumen sus efectos. :-) > > A 0,01 pesos el kB excedente de tráfico... 5 paquetes (SYN, > > SYN+ACK, ACK, FIN, FIN+ACK) cada 5 min, son 480 al día, o 14400 > > al mes. El tamaño mínimo de los paquetes IP creo que era 320 > > bytes, o sea que terminan siendo 4500 kB extra al mes, o 45 pesos > > extra al mes, comparado con los 12 pesos por 5 MB al mes que es > > una excelentísima tarifa conseguible... sería la muuerte! > > Ups... bueno, acá estamos en una situación difernte. Si el jefe, el > señor Money lo dice, hay que hacer lo que haga falta. Si querés > reducir el tamaño y cantidad de paquetes, tal vez necesités cambiar > el protocolo o cambiarte a UDP. Estuve googleando y parece que el tamaño mínimo de carga útil de TCP es 1 byte, así que estamos hablando de 21 bytes, no de 320 bytes por paquete. (debería mirar el libro que estudié para los exámenes de Google, recién me doy cuenta de que ahí está claramente explicado esto). Me había confundido con el tamaño mínimo de paquete que un router debe ser capaz de manejar, que es 576 bytes. O sea que está garantizado que cualquier paquete de menos de 576 bytes pueda circular por cualquier parte de Internet sin dramas ni fragmentación. Eso no quiere decir que no puedan existir paquetes más chicos! > >> De esa forma, con un número relativamente chico de procesos > >> servidores se puede atender a muchísimos clientes. > > > > pero no simultáneamente. Pero cumple, a costa de sacrificar > > algunas flexibilidades y comodidades. Lo voy a seguir masticando. > > Sí, yo supongo que seguramente no hace falta que sea simultánea la > comunicación porque de todas foramas si fuera simultánea tal vez no > te daría el ancho de banda para recibirlas todas al mismo tiempo. Se compra el ancho de banda necesario para ser capaz de leer todos los datos de todos los equipos en menos de 5 min, con la cantidad que se pueda de conexiones simultáneas. Si el caño no da para transportar los datos al ritmo que se están generando, no sirve... > > Como yo me lo imagino, cuando haya datos nuevos o no marcados > > como ya vistos por el servidor, el equipo va a querse conectar > > con el máximo de empeño. Le agrego una espera aleatoria entre > > intentos de unos pocos segundos, y listo. Cuando logre conectarse > > y el servidor logre chuparle todos los datos y marcárselos como > > ya vistos, que lo desconecte (o le mande el comando de > > desconexión ya existente al equipo) y listo: el equipo > > permanecerá desconectado hasta que de nuevo haya datos nuevos (5 > > min). > > Claro, y simplemente podés implementar algún tipo de alarma cuando > haya pasado digamos más de 10 minutos sin tener noticias de él. Alarma que ya existe... > A todo esto, si el único problema de conectarse con ellos es que > tienen ip variable, me imagino que ya habrás pensado en implementar > tu propio "dyndns". O sea, que el equipo te llame y te diga "che, > yo soy XKJ6969, anotá mi IP por si querés llamarme", y corte. El proveedor de comunicaciones me corta la conexión luego de un tiempo de inactividad, total, las aplicaciones típicas de GPRS son interactivas, y no orientadas a conexión (HTTP) así que en el caso normal a nadie le molesta que se haya cortado la comunicación cuando terminó de bajar fotos de minas en bolas en el celular y unos minutos después quiere mandar un mail "super importante" y el celular se demore unos segundos en reconectarse antes de hacerlo... Además me complicaba y agrandaba el código bastante y se decidió no hacerlo. > Si el > equipo se da cuenta de que le han cambiado la IP, vuelve a llamarte > y mandar la IP nueva. Como la dirección IP sólo cambia al reconectarse y para indicar la nueva dirección tiene que conectarse antes, es más fácil y fiable que mande la actualización cada vez que se reconecte, aunque 1 vez por millón justo al reconectarse le haya tocado en suerte la misma dirección IP que tenía antes. > No se si será factible en esta situación pero > te permitiría mantener más o menos el mismo esquema que si tuvieran > IP fija. En realidad se hizo otra cosa: se implementó un "puenteador de sockets", que es en realidad un gateway de capa 7 para el protocolo de aplicación usado por los equipos. El puenteador acepta todas las conexiones que le lleguen, tira una pregunta mediante el protocolo de aplicación para identificar si se trata de uno de estos equipos y le lee su número de serie e ID (es decir, su dirección en el protocolo de aplicación) y se acuerda que en ese socket tiene conectado a tal equipo. Cuando vienen paquetes de cualquiera de los sockets se observa su cabecera y se lo escribe en el socket en donde esté conectado el equipo con esa dirección. Y al servidor se lo configuró de modo que todos los equipos tuviesen la misma dirección IP, la del host en donde esta el puenteador, así que para el servidor, los módulos siguen viéndose como servidores, no como clientes TCP. Pero si se puede hacer un nuevo programa "barredor" que no requiera del "puenteador" y que pueda por sí mismo tanto hacer como aceptar conexiones con/de los módulos, mucho mejor. -- Herr Groucho ID Jabber: [EMAIL PROTECTED] Señal distintiva: LU5MJR - 144,550 MHz FM. Clave pública GPG: hkp://pks.lugmen.org.ar Fingerprint GPG: B7BD 0FC7 D9A2 66F3 4EFC 45EE 7DE2 3932 597B 6354
