Docs Menu
Docs Home
/ /
Detalles técnicos

Protocolo de sincronización de dispositivos Atlas

Atlas Device Sync utiliza un protocolo para sincronizar de forma correcta y eficiente los cambios de datos en tiempo real entre varios clientes, cada uno de los cuales mantiene sus propios archivos de dominio locales. El protocolo define un conjunto de valores predefinidos. tipos de solicitud, así como un proceso mediante el cual un cliente, como un SDK de Realm, puede conectarse a un servidor de aplicaciones de Atlas App Services y sincronizar datos.

Nota

Los SDK de Realm implementan y gestionan internamente el protocolo de sincronización, por lo que, en la mayoría de las aplicaciones, no es necesario comprenderlo para usar Device Sync. Esta página describe el protocolo a grandes rasgos y no constituye una especificación de implementación.

Un conjunto de cambios es una lista de instrucciones que describen modificaciones granulares realizadas en el estado o la versión de un objeto conocido mediante una o más operaciones de escritura. Los conjuntos de cambios son la unidad básica del protocolo de sincronización. Los clientes del dominio sincronizado envían conjuntos de cambios al servidor de sincronización de dispositivos cada vez que realizan una operación de escritura. El servidor envía a cada cliente conectado los conjuntos de cambios correspondientes a las operaciones de escritura ejecutadas por otros clientes.

El servidor de sincronización de dispositivos acepta conjuntos de cambios de cualquier cliente de sincronización conectado (incluidos los cambios en un clúster MongoDB sincronizado) en cualquier momento y utiliza un algoritmo de transformación operativa para serializar los cambios en un orden lineal y resolver conjuntos de cambios conflictivos antes de enviarlos a los clientes conectados.

Nota

Sincronización Delta

Al realizar un cambio en un objeto sincronizado, App Services no vuelve a cargar el objeto completo. En su lugar, envía solo la diferencia ("delta") entre el antes y el después. El servicio comprime los deltas con zlib. compresión. Esto reduce la carga de la red, lo que es especialmente útil en condiciones de red móvil.

Una transformación operativa es una función que, dadas dos conjuntos de cambios, produce un tercer conjunto de cambios que representa lógicamente la aplicación de uno de los conjuntos de cambios dados después del otro. Device Sync utiliza transformación operacional para resolver conflictos entre conjuntos de cambios de diferentes clientes de sincronización que se aplican al mismo estado base.

Realm es una base de datos local que prioriza el uso sin conexión, incluso con la sincronización habilitada. Esto significa que cualquier dispositivo puede realizar escrituras sin conexión y cargar los conjuntos de cambios correspondientes posteriormente, una vez restablecida la conectividad de red. El algoritmo de transformación operativa está diseñado para gestionar eficazmente los conjuntos de cambios que llegan fuera de orden con respecto al reloj lógico del servidor, de modo que cada archivo de Realm sincronizado converja a la misma versión de cada objeto modificado.

Tip

Una transformación operativa en los conjuntos de cambios de Realm es análoga a una operación de rebase en Git.

Un identificador de archivo de cliente es un valor que identifica de forma única un archivo de Realm de cliente sincronizado y su archivo de servidor correspondiente. El servidor genera un identificador de archivo de cliente cada vez que un SDK lo solicita durante la sincronización inicial de un archivo de Realm. Cada identificador es un 64entero positivo con signo de bits, distinto de cero, estrictamente menor que 2^.63

Nota

El servidor garantiza que todos los identificadores generados para un archivo de servidor específico sean únicos entre sí. El servidor puede generar identificadores idénticos para dos archivos de cliente si están asociados a archivos de servidor diferentes.

El SDK se sincroniza con el servidor de aplicaciones a través de una conexión WebSocket protegida por HTTPS usando TLS.1.3

Para iniciar, ejecutar y finalizar una sesión de sincronización de dispositivos, un SDK de Realm y un servidor de aplicaciones envían y reciben un conjunto de solicitudes específicas del protocolo.

El SDK negocia una conexión WebSocket a través de HTTP y luego establece una sesión de sincronización enviando Las solicitudes BINDyIDENTse envían al servidor a través de la conexión WebSocket. Una vez establecida la sesión, el SDK y el servidor se envían conjuntos de cambios sincronizados para un archivo de Realm determinado mediante mensajesUPLOADyDOWNLOAD. Para finalizar la sesión, el SDK envía una solicitudUNBIND.

Realm SDK App Server
| |
| <---- 1. HTTP Handshake -----> |
| |
| --------- 2. BIND -----------> |
| |
| <-- 3. IDENT (first time) ---- |
| |
| --------- 4. IDENT ----------> |
| |
| <---- 5. UPLOAD/DOWNLOAD ----> |
| |
| --------- 6. UNBIND ---------> |
1

El protocolo de sincronización se gestiona principalmente mediante una conexión WebSocket entre el SDK y el servidor. Para establecer una conexión, el SDK envía una solicitud HTTP de protocolo de enlace que incluye lo siguiente:

  • una versión del protocolo

  • una clave WebSocket

  • un token de acceso válido para un usuario autenticado de la aplicación App Services

El servidor envía una respuesta HTTP 101 de protocolos de conmutación que especifica una conexión WebSocket para el SDK. El resto del protocolo de sincronización se realiza a través de esta conexión.

2

Para iniciar una sesión de sincronización, un SDK de Realm envía una solicitud BIND a un servidor Device Sync. La solicitud identifica un archivo específico de base de datos local Realm a sincronizar e incluye una clave de conexión WebSocket que el servidor usará para abrir una conexión bidireccional con el SDK.

Si el SDK intenta sincronizar un archivo de base de datos de Realm por primera vez, aún no posee un identificador de cliente generado por el servidor para dicho archivo. En este caso, la BIND solicitud también indica que el servidor de sincronización de dispositivos debe asignar uno.

3

Si una solicitud indica que el SDK necesita un identificador de archivo de cliente, el servidor de sincronización de dispositivos genera BIND un valor único para el archivo de base de datos de dominio especificado y lo envía al SDK en una respuesta. Cuando IDENT IDENT el SDK recibe la, almacena el nuevo identificador de cliente de forma persistente en el archivo de base de datos de dominio local.

Un SDK solo necesita solicitar un identificador de archivo de cliente la primera vez que sincroniza cada archivo de base de datos de Realm. Para las siguientes sesiones de sincronización, el SDK puede usar el identificador persistente.

4

Una vez que un SDK inicia una sesión de sincronización con una solicitud, debe BIND IDENT identificar el archivo de la base de datos de dominio local que desea sincronizar. Para ello, el SDK envía al servidor de aplicaciones un mensaje que contiene el identificador del archivo del cliente. Si el SDK ya ha sincronizado el dominio con el servidor, puede especificar la versión del servidor sincronizada más reciente para optimizar el proceso de sincronización.

Al recibir el mensaje, el servidor establece la sesión. El SDK y el servidor ahora pueden enviar libremente conjuntos de cambios de sincronización de carga y descarga en cualquier IDENT momento.

5

Una vez que se establece una sesión de sincronización, el SDK y el servidor pueden enviar y recibir libremente UPLOAD mensajes y DOWNLOAD para sincronizar los cambios cuando ocurran.

El SDK envía un mensaje por cada conjunto de cambios UPLOAD DOWNLOAD que aplica, excepto aquellos que recibió en un mensaje del servidor.

Cuando el servidor recibe un mensaje,UPLOAD aplica transformaciones operativas para resolver cualquier conflicto con otros conjuntos de cambios y, a continuación, aplica el conjunto de cambios transformado a la versión del servidor del dominio. Esto activa el servidor para enviar mensajes a otros clientes conectados, incluido el clúster DOWNLOAD DOWNLOAD Atlas sincronizado que refleja el dominio del servidor. Un mensaje agrupa uno o más conjuntos de cambios transformados en orden cronológico, del más antiguo al más reciente, según el historial del servidor. El SDK aplica los conjuntos de cambios en el mismo orden.

6

Una vez establecida una sesión de sincronización, los servidores de sincronización de dispositivos seguirán aceptando mensajes UPLOAD y enviando mensajes hasta que el SDK la finalice. Para DOWNLOAD UNBIND finalizar una sesión de sincronización, un SDK envía una solicitud al servidor de sincronización de dispositivos.

La siguiente tabla describe los tipos de solicitud que un cliente de sincronización puede enviar a un servidor de sincronización de dispositivos:

Solicitud
Descripción
BIND

Inicia una nueva sesión de sincronización en el servidor y proporciona un token de autorización firmado para el usuario actual de la aplicación. Si el cliente aún no posee un identificador de archivo de cliente para el archivo de Realm que desea sincronizar, esto también indica que el servidor debe generar uno y enviárselo.

Un cliente debe enviar un BIND antes de poder enviar cualquier otra solicitud.

IDENT

Proporciona el identificador de archivo del cliente que indica lo siguiente:

  • El archivo Realm para sincronizar

  • la versión actual del reino del cliente

  • la versión del servidor sincronizada más recientemente del ámbito del cliente

Esta solicitud está relacionada con el mensaje que envía el servidor cuando un cliente solicita un identificador de archivo de IDENT cliente.

UPLOAD

Especifica uno o más conjuntos de cambios para las operaciones realizadas en el cliente. Los conjuntos de cambios se enumeran por versión del cliente en orden ascendente.

TRANSACT

Especifica un conjunto de cambios que describe una transacción serializada realizada en el cliente. El cliente no puede cargar ningún otro conjunto de cambios hasta que el servidor confirme o rechace la transacción.

UNBIND

Finaliza una sesión de sincronización en ejecución.

Un cliente no puede enviar ninguna otra solicitud para una UNBOUND sesión.

MARK

Solicita que el servidor notifique al cliente cuando haya sincronizado el último conjunto de cambios en el historial del servidor (en el momento de la solicitud).

REFRESH

Vuelve a autorizar una sesión de sincronización actual con un nuevo token de usuario.

STATE_REQUEST

Solicita al servidor que envíe uno o más mensajes, que el cliente utiliza para descargar la versión actual del archivo Realm. Los clientes emiten solicitudes de estado al abrir asincrónicamente un dominio STATE sincronizado.

CLIENT_VERSION_REQUEST

Solicita al servidor que envíe la versión del cliente del último conjunto de cambios enviado por el cliente y procesado por el servidor. Esto se usa con mayor frecuencia cuando un SDK ejecuta un restablecimiento del cliente.

PING

Indica que el cliente sigue conectado y que el servidor debe mantener la sesión sincronizada. Un cliente debe enviar al menos un ping al servidor cada 10 minutos. El servidor confirma cada ping con PONG un.

Si el servidor no ha recibido un PING de un cliente en más de 10 minutos, considera que el cliente está desconectado y puede finalizar la sesión automáticamente.

La siguiente tabla describe los tipos de solicitud que el servidor de sincronización de dispositivos puede enviar a un cliente de sincronización:

Solicitud
Descripción
IDENT

Proporciona un identificador de archivo de cliente que el servidor generó en respuesta a un que solicitó el BIND identificador.

DOWNLOAD

Especifica uno o más conjuntos de cambios (hasta 16MB en total) para operaciones realizadas en otros clientes. Los conjuntos de cambios se enumeran por versión del servidor en orden ascendente.

Los conjuntos de cambios en una DESCARGA pueden no ser exactamente los mismos que subieron otros clientes. En cambio, pueden ser conjuntos de cambios equivalentes generados por el algoritmo de transformación operativa de Device Sync.

UNBOUND

Especifica que el servidor finalizó una sesión de sincronización en respuesta a UNBIND un.

TRANSACT

Indica si el servidor procesó con éxito o no un conjunto de cambios especificado en un del TRANSACT cliente.

MARK

Indica que el servidor ha enviado al cliente el último conjunto de cambios que estaba en el historial del servidor cuando el servidor recibió un MARK del cliente.

STATE

Contiene uno o más segmentos de datos codificados que el cliente puede concatenar para construir la última versión del servidor del dominio. Se envía en respuesta a STATE_REQUEST un.

CLIENT_VERSION

Especifica la versión del cliente del último conjunto de cambios enviado por el cliente y procesado por el servidor. Se envía en respuesta a CLIENT_VERSION_REQUEST un.

ERROR

Indica que el servidor encontró un problema que parece haber sido causado por el cliente conectado. Para obtener más detalles, consulta Errores del cliente de sincronización.

PONG

Confirma un. Si un cliente no recibe una confirmación de PING, indica que no puede comunicarse con el servidor a través de la red y que es posible que el servidor no haya recibido PING el PING correspondiente.

Volver

Resolución de conflictos