¿Cuáles son las dificultades más comunes de la sincronización basada en la marca de tiempo?

Question

Estoy implementando mi primer código de sincronización. En mi caso, tendré 2 tipos de clientes iOS por usuario que sincronizarán registros con un servidor usando un lastSyncTimestamp, un entero de 64 bits que representa la época Unix en milisegundos de la última sincronización. Los registros se pueden crear en el servidor o los clientes en cualquier momento y los registros se intercambian como JSON a través de HTTP.

No me preocupan los conflictos ya que hay pocas actualizaciones y siempre del mismo usuario. Sin embargo, me pregunto si hay cosas comunes que debo tener en cuenta que pueden salir mal con un enfoque basado en la marca de tiempo como la sincronización durante el horario de verano, las sincronizaciones en conflicto con otras u otras trampas.

Sé que git y algunos otros sistemas de control de versiones evitan la sincronización con marcas de tiempo para un enfoque de sincronización de negociación basado en contenido. También podría imaginar un enfoque así para mis aplicaciones, donde usando el uuid o el hash de los objetos, ambos pares anuncian qué objetos poseen y luego los intercambian hasta que ambos pares tengan los mismos conjuntos.

Si alguien conoce las ventajas o desventajas de la sincronización basada en contenido en comparación con la sincronización basada en la marca de tiempo en general, también sería útil.

Editar - Estas son algunas de las ventajas/desventajas que he encontrado para la sincronización de la marca de tiempo y el contenido. Por favor desafíe/corrija.

Nota - Estoy definiendo la sincronización basada en contenidos de negociación tan simple de 2 conjuntos de objetos tales como la forma 2 niños intercambiaban tarjetas si se les dio a cada uno partes de un embarullado encima de pila de 2 conjuntos idénticos de tarjetas de béisbol y les dijo que a medida que miraban a través de ellos para anunciar y entregar los duplicados que encontraron al otro hasta que ambos tengan conjuntos idénticos.

• Johnny - "Tengo esta tarjeta".
• Davey - "Recibí este montón de tarjetas. Dame esa tarjeta".
• Johnny - "Aquí está su tarjeta. Dame ese montón de cartas".
• Davey - "Aquí tienes tu montón de cartas".
• ....
• Tanto - "Hemos terminado"

Ventajas de la marca de tiempo basada en la sincronización de

• Fácil de implementar
• propiedad individual se utiliza para la sincronización.

Desventajas de la marca de tiempo basada en la sincronización de

• El tiempo es un concepto relativo al observador y relojes diferentes de máquina puede estar fuera de sincronía. Hay un par de formas de resolver esto. Genere la marca de tiempo en una sola máquina, que no se escala bien y representa un único punto de falla. O usa relojes lógicos como relojes vectoriales. Para el desarrollador promedio que construye su propio sistema, los relojes vectoriales pueden ser demasiado complejos para implementarlos.
• La sincronización basada en la marca de tiempo funciona para que el cliente domine la sincronización, pero no funciona tan bien para la sincronización de igual a igual o cuando la sincronización puede ocurrir con 2 maestros.
• Único punto de falla, cualquiera que sea la fuente de la marca de tiempo.
• El tiempo no está realmente relacionado con el contenido de lo que se está sincronizando.

Ventajas de la sincronización basada en contenidos

• n por pares marca de tiempo debe ser mantenido. 2 pares pueden iniciar una sesión de sincronización e iniciar la sincronización según el contenido.
• Punto final bien definido para sincronizar: cuando ambas partes tienen conjuntos idénticos.
• Permite una arquitectura de igual a igual, donde cualquier par puede actuar como cliente o servidor, siempre que puedan alojar un servidor HTTP.
• Sync funciona con el contenido de los conjuntos, no con un tiempo de concepto abstracto.
• Dado que la sincronización se basa en el contenido, la sincronización se puede utilizar para realizar la verificación de contenido si se desea. P.ej. un hash SHA-1 se puede calcular en el contenido y usar como uuid. Se puede comparar con lo que se envía durante la sincronización.
• Además, los hashes SHA-1 se pueden basar en hashes previos para mantener un historial constante de contenido.

desventajas de sincronización basada en contenidos

• propiedades extra en sus objetos pueden ser necesarios para poner en práctica.
• Más lógica en ambos lados en comparación con la sincronización basada en la marca de tiempo.
• Un poco más de protocolo de conversación (esto se puede sintonizar mediante la sincronización de contenido en clústeres).

Answer 1

No sé si se aplica a su entorno, pero podría considerar quién es el tiempo "correcto", el cliente o el servidor (o si importa). Si todos los clientes y todos los servidores no están sincronizados con la misma fuente de tiempo, podría existir la posibilidad, aunque leve, de que un cliente obtenga un resultado inesperado al sincronizarse con (o desde) el servidor usando el tiempo "ahora" del cliente.

Nuestra organización de desarrollo de hecho se encontró con algunos problemas con esto hace varios años. Las máquinas desarrolladoras no se sincronizaron todas con la misma fuente de tiempo que el servidor donde residía el SCM (y es posible que no se haya sincronizado con ninguna fuente de tiempo, por lo que el tiempo de la máquina del desarrollador podría variar). Una máquina desarrolladora podría tardar varios minutos después de unos meses. No recuerdo todos los problemas, pero parece que el proceso de compilación intentó modificar todos los archivos desde cierto tiempo (la última compilación). Los archivos podrían haberse ingresado, desde la última compilación, que tuvo tiempos de modificación (desde el cliente) que ocurrieron ANTES de la última compilación.

Podría ser que nuestros procedimientos SCM simplemente no fueran muy buenos, o que nuestro sistema SCM o nuestro proceso de construcción fueran indebidamente susceptibles a este problema. Incluso hoy en día, se supone que todas nuestras máquinas de desarrollo sincronizan el tiempo con el servidor que tiene nuestro sistema SCM.

Una vez más, esto fue hace varios años y no recuerdo los detalles, pero quería mencionarlo en caso de que sea significativo en su caso.

Answer 2

Parte del problema es que el tiempo no es un concepto absoluto. Si algo sucede antes o después de algo más es una cuestión de perspectiva, no de cumplimiento con un reloj de pared.

leer un poco en relativity of simultaneity a entender por qué la gente ha dejado de tratar de usar el tiempo de la pared para averiguar estas cosas y se han trasladado a las construcciones que representan la causalidad real utilizando vector clocks (o al menos Lamport clocks).

Si desea utilizar un reloj para la sincronización, un reloj lógico es lo que más le conviene. Evitará todos sus problemas de sincronización de reloj y esas cosas.

Answer 3

Puede echar un vistazo a unison. Está basado en archivos, pero es posible que encuentre interesantes algunas de las ideas.