Tengo que mantener actualizado un único archivo relativamente pequeño a través de una conexión de módem de acceso telefónico lenta e inestable.
El archivo es un XML que podría comenzar con 15K y, dos horas después, terminar con 500K.
Es una replicación unidireccional. Mi solución actual sigue descargando el archivo completo una vez por minuto. Hasta ahora funciona bien con conexiones de banda ancha, pero ahora tengo que usarlo en una ubicación donde sólo está disponible el acceso telefónico. La ilusión de "datos en tiempo real" se pierde porque la descarga es lenta.
Pensé que rsync podría salvarme de desarrollar un protocolo propietario (y deficiente) "sólo delta". Me pregunto si rsync proporcionaría beneficios reales en este caso particular.
Entonces, la pregunta es: ¿Es el protocolo rsync una buena opción para un solo archivo de 15K a 500K?
Respuesta1
No en este caso. Es mejor que uses algo comodiffxmlenviar solo la diferencia entre archivos como actualización y aplicar el parche en la máquina de destino.
Respuesta2
Bueno, lo hice con rsync y debo decir que funcionó bien.
Transfiere tan pocos datos que pude acortar la frecuencia de actualización a 20 segundos con una conexión de acceso telefónico estrecha (¡un tercio de la frecuencia anterior que usábamos con banda ancha!).
¡Actualizar un XML de 800 kb ahora requiere 5 kb de descarga + 800 bytes de carga!
Verificar versiones cuando no hay cambios para actualizar requiere menos 500 bytes de descarga + 100 bytes de carga. (¡Transfiero más bytes escribiendo en una sesión de chat normal!)
Mucho mejor que otras soluciones de diferencias y no tuve que programar nada a su alrededor. (Anteriormente pensamos en agregar un mecanismo de inserción para activar rsync, pero realmente no lo necesitamos todavía. 20 segundos son aceptables y el sondeo es muy liviano).
¡Así se hace, rsync!
PD: No probé Git y probablemente tampoco habría sido una buena solución.