En el primer post relacionado con el prototype server no tuvimos la oportunidad de hablar sobre la seguridad. Para entender las medidas de seguridad es imprescindible entender el protocolo cliente-servidor y servidor-servidor (federation). En esta entrada hablaremos sobre el protocolo cliente-servidor.
El protocolo cliente-servidor se basa en la Transformación de Operaciones (OT). Si estas un poco familiarizado con bases de datos, cuando dos usuarios tratan de actualizar los mismos datos, los leen al mismo tiempo e intentan guardarlos igual, se produce un error de inconsistencia sobre la base de datos. Para prevenir estos errores las bases de datos emplean sistemas como las transacciones. En pocas palabras, cuando un usuario accede a un dato este se bloquea hasta que lo ha actualizado y es entonces cuando se desbloquea y otro usuario puede acceder a el. Esta es una buena solución para por ejemplo, los bancos, pero si queremos edición en tiempo real, esto no es una opción. OT permite a los usuarios editar en paralelo y enviar sus datos en tiempo real. La idea básica de OT es permitir al cliente y a los servidores enviar datos tan rápido como les sea posible.
Esquema básico de (OT)
Como podemos ver los usuarios envían datos al mismo tiempo desde la misma fuente (abc). O1 introduce X en la posición 0 y O2 elimina la posición 2, “c”. El servidor recibe dos operaciones al mismo tiempo. Si cambiamos O1 y después O2 el resultado es diferente al esperado (xabc + eliminar[2] = xac). Por ese motivo es necesario tener un “ticket”, u orden de tarea. El “ticket” es solo una referencia en el tiempo para ordenar el flujo de operaciones. Lo que el servidor hace es aplicar las operaciones y transmitirlas al resto de usuarios. El servidor debe conocer la posición en el tiempo de cada operación y realizar los cambios adecuadamente. Esta es la idea básica de cómo funcionan las (OT).
Las Wave (OT) tienen la peculiaridad que los usuarios no pueden enviar los datos tan rápido como pueden. Si esto estuviera permitido cada usuario debería tener un espacio de memoria en cada servidor, esto implica un intenso uso de memoria y además complicaría el algoritmo del servidor, requiriendo la conversión de las operaciones de los clientes entre los espacios de memoria. Lo que Wave (OT) hace es enviar las operaciones y esperar a la confirmación del servidor. Este pequeño cambio, hace que el servidor solo deba tener un espacio de memoria formado por el historial de operaciones.
Lo que los clientes deben hacer es almacenar todas las operaciones hasta que reciban la confirmación del servidor. Un pequeño inconveniente es que los usuarios verán las operaciones de los demás, en intervalos del tiempo que tarde una ronda. Esto no será un problema si el tiempo de una vuelta es pequeño, sino los cambios tardaran un poco en aparecer.Una vez hayamos entendido Wave (OT), podemos empezar a hablar sobre el protocolo cliente-servidor. Las operaciones son “mutaciones” en los wavelets. Podemos entender el estado de un wavelet como la secuencia de operaciones que le han afectado.
Lo que el cliente y el servidor hacen es intercambiar las modificaciones de un wavelet. El servidor es el responsable de transmitir las operaciones al resto de usuarios involucrados en ese wavelet. (En la mayoría de los casos todos los participantes del wavelet, en los wavelets privados, solo a aquellos que les este permitido). Los usuarios aplican las modificaciones realizadas a una copia propia. Todos los usuarios deben aplicar las operaciones del mismo modo para mantener una consistencia con el resto de usuarios.
Wave OT requiere que todas las operaciones estén ordenadas, como ya hemos dicho, en Wave (OT) el cliente debe esperar la confirmación del servidor, y entonces enviar las nuevas operaciones. El usuario es el responsable de ordenar estas operaciones y este orden debe coincidir con el número de orden proporcionado por el servidor. Un participante que tenga un wavelet “abierto”, implicara el intensivo intercambio de operaciones de ese wavelet. Para abrir un wavelet el cliente envía una petición al servidor (identificador del Wave y del wavelet). El servidor responde con el estado del wavelet y el historial de esa versión, esto es necesario para ordenar nuevas operaciones y obtener los nuevos datos.
En una comunicación normal el cliente envía Delta (secuencia de una o mas operaciones) y el numero de la versión. El servidor confirma enviando la nueva versión y el historial. El servidor puede enviar cambios hechos por otros usuarios, entonces el servidor envía Delta número de la versión y el historial. En una comunicación fallida cliente-servidor, cliente y servidor deben ponerse de acuerdo con el estado del wavelet antes de volver a conectarse. El cliente vuelve a abrir el wavelet enviando una lista de historiales enviados previamente por el servidor. El cliente envía: el identificador del Wave del wavelet y la lista de historiales conocidos por el cliente. El servidor responde con el último historial conocido y una secuencia de deltas. Si los historiales son iguales, el usuario y el servidor están sincronizados. Si no coinciden o el servidor no reconoce ninguno de los historiales enviados por el cliente, este debe volver a cargar la página para ponerse de acuerdo con el estado de los demás usuarios. Este el motivo del error en Google Wave que pide recargar la pagina.
Diagrama de datos cliente - servidor
Hoy por hoy, Google Wave Federation Prototype Server, no tiene certificado de seguridad entre usuario y servidor. Los clientes confían en que los servidores de wave, manejen de forma adecuada sus datos. La gente de Google esperan que algún día haya soporte para la firma digital. Nosotros creemos que esto es totalmente necesario si queremos que Google Wave sea usado ampliamente por las compañías.
Esto es todo para esta primera parte, en la segunda hablaremos sobre el protocolo servidor-servidor y su seguridad.
Etiquetas:ack, client server protocol, client-server, hash tree, OT, protocol client, schema, wave ot, wavelet
If you like what you see, please, support us:
Posts that may be of your interest:
- Comprendiendo el protocolo – Parte 2
- Control de accesos en Wave
- Google Wave Federation protocol updates
- Wave Federation
- PyGoWave – Servidor Wave
Comprendiendo el protocolo – Parte 1
En el primer post relacionado con el prototype server no tuvimos la oportunidad de hablar sobre la seguridad. Para entender las medidas de seguridad es imprescindible entender el protocolo cliente-servidor y servidor-servidor (federation). En esta entrada hablaremos sobre el protocolo cliente-servidor.
El protocolo cliente-servidor se basa en la Transformación de Operaciones (OT). Si estas un poco familiarizado con bases de datos, cuando dos usuarios tratan de actualizar los mismos datos, los leen al mismo tiempo e intentan guardarlos igual, se produce un error de inconsistencia sobre la base de datos. Para prevenir estos errores las bases de datos emplean sistemas como las transacciones. En pocas palabras, cuando un usuario accede a un dato este se bloquea hasta que lo ha actualizado y es entonces cuando se desbloquea y otro usuario puede acceder a el. Esta es una buena solución para por ejemplo, los bancos, pero si queremos edición en tiempo real, esto no es una opción. OT permite a los usuarios editar en paralelo y enviar sus datos en tiempo real. La idea básica de OT es permitir al cliente y a los servidores enviar datos tan rápido como les sea posible.
Esquema básico de (OT)
Como podemos ver los usuarios envían datos al mismo tiempo desde la misma fuente (abc). O1 introduce X en la posición 0 y O2 elimina la posición 2, “c”. El servidor recibe dos operaciones al mismo tiempo. Si cambiamos O1 y después O2 el resultado es diferente al esperado (xabc + eliminar[2] = xac). Por ese motivo es necesario tener un “ticket”, u orden de tarea. El “ticket” es solo una referencia en el tiempo para ordenar el flujo de operaciones. Lo que el servidor hace es aplicar las operaciones y transmitirlas al resto de usuarios. El servidor debe conocer la posición en el tiempo de cada operación y realizar los cambios adecuadamente. Esta es la idea básica de cómo funcionan las (OT).
Las Wave (OT) tienen la peculiaridad que los usuarios no pueden enviar los datos tan rápido como pueden. Si esto estuviera permitido cada usuario debería tener un espacio de memoria en cada servidor, esto implica un intenso uso de memoria y además complicaría el algoritmo del servidor, requiriendo la conversión de las operaciones de los clientes entre los espacios de memoria. Lo que Wave (OT) hace es enviar las operaciones y esperar a la confirmación del servidor. Este pequeño cambio, hace que el servidor solo deba tener un espacio de memoria formado por el historial de operaciones.
Lo que los clientes deben hacer es almacenar todas las operaciones hasta que reciban la confirmación del servidor. Un pequeño inconveniente es que los usuarios verán las operaciones de los demás, en intervalos del tiempo que tarde una ronda. Esto no será un problema si el tiempo de una vuelta es pequeño, sino los cambios tardaran un poco en aparecer.Una vez hayamos entendido Wave (OT), podemos empezar a hablar sobre el protocolo cliente-servidor. Las operaciones son “mutaciones” en los wavelets. Podemos entender el estado de un wavelet como la secuencia de operaciones que le han afectado.
Lo que el cliente y el servidor hacen es intercambiar las modificaciones de un wavelet. El servidor es el responsable de transmitir las operaciones al resto de usuarios involucrados en ese wavelet. (En la mayoría de los casos todos los participantes del wavelet, en los wavelets privados, solo a aquellos que les este permitido). Los usuarios aplican las modificaciones realizadas a una copia propia. Todos los usuarios deben aplicar las operaciones del mismo modo para mantener una consistencia con el resto de usuarios.
Wave OT requiere que todas las operaciones estén ordenadas, como ya hemos dicho, en Wave (OT) el cliente debe esperar la confirmación del servidor, y entonces enviar las nuevas operaciones. El usuario es el responsable de ordenar estas operaciones y este orden debe coincidir con el número de orden proporcionado por el servidor. Un participante que tenga un wavelet “abierto”, implicara el intensivo intercambio de operaciones de ese wavelet. Para abrir un wavelet el cliente envía una petición al servidor (identificador del Wave y del wavelet). El servidor responde con el estado del wavelet y el historial de esa versión, esto es necesario para ordenar nuevas operaciones y obtener los nuevos datos.
En una comunicación normal el cliente envía Delta (secuencia de una o mas operaciones) y el numero de la versión. El servidor confirma enviando la nueva versión y el historial. El servidor puede enviar cambios hechos por otros usuarios, entonces el servidor envía Delta número de la versión y el historial. En una comunicación fallida cliente-servidor, cliente y servidor deben ponerse de acuerdo con el estado del wavelet antes de volver a conectarse. El cliente vuelve a abrir el wavelet enviando una lista de historiales enviados previamente por el servidor. El cliente envía: el identificador del Wave del wavelet y la lista de historiales conocidos por el cliente. El servidor responde con el último historial conocido y una secuencia de deltas. Si los historiales son iguales, el usuario y el servidor están sincronizados. Si no coinciden o el servidor no reconoce ninguno de los historiales enviados por el cliente, este debe volver a cargar la página para ponerse de acuerdo con el estado de los demás usuarios. Este el motivo del error en Google Wave que pide recargar la pagina.
Diagrama de datos cliente - servidor
Hoy por hoy, Google Wave Federation Prototype Server, no tiene certificado de seguridad entre usuario y servidor. Los clientes confían en que los servidores de wave, manejen de forma adecuada sus datos. La gente de Google esperan que algún día haya soporte para la firma digital. Nosotros creemos que esto es totalmente necesario si queremos que Google Wave sea usado ampliamente por las compañías.
Esto es todo para esta primera parte, en la segunda hablaremos sobre el protocolo servidor-servidor y su seguridad.
Etiquetas:ack, client server protocol, client-server, hash tree, OT, protocol client, schema, wave ot, wavelet
If you like what you see, please, support us:
Posts that may be of your interest: