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. 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. 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. > No es complicado de hacer lo que decís, pero se pierde bastante > funcionalidad. Bueno, tendrías que pensar qué funcionalidades se pierden (que realmente se estén usando o se piense usar) y si se puede implementar sin tener la conexión activa. > 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. >> 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. > 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. No es lo mismo que tenerlo siempre en línea pero si podés hacer que el equipo soporte ambos protocolos: el de llamar o el de ser llamado, podés hacer que el servidor llame a los que tienen conexión a internet "de verdad", los que no puedan recibir llamadas tendrán que llamar ellos. En ese caso la funcionalidad reducida la tendrías sólo en los equipos que tengan una conexión a internet peor. 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. Si el equipo se da cuenta de que le han cambiado la IP, vuelve a llamarte y mandar la IP nueva. 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.
