Artículo: Sincronización (Parte I)

Esto es un tema que me hubiese gustado tratar de hace tiempo, pero entre el tiempo por un lado y que hasta la version 3.0 no merecía tampoco mucho la pena a tratar... vamos a intentar explicar que es la sincronización, que ventajas nos ofrece y por supuesto, como podemos hacernos la vida un poco más sencilla. Tenía pensado hacerlo en tan solo una entrega... pero ya me conoceis.

Vamos a intentar ir explicando terminos como Google Sync, mobileMe, SyncML, CalDAV, ActiveSync, LDAP...


Cada vez más, los dispositivos portátiles estan a la orden del día, cada vez con más funciones, cada vez usando más los estándares actuales pudiendo interactuar unos con ellos. ¿El problema?

Este podría ser el perfil de un trabajador de oficina:

Se levanta temprano para ir a trabajar y claro, en el bolsillo o en su maletín está claro que no faltará el móvil, es posible que incluso dos móviles, el de la empresa y el suyo. Es posible incluso que lleve una PDA en vez de teléfono móvil o incluso las dos herramientas. Tomando el café escrutina la agenda en el movil o en la PDA para refrescar en su cabeza las citas del día, y recuerda que debe de comer fuera. De camino al trabajo por tanto llama a su mujer con su movil para decirle que se quedará a comer.

Llega al trabajo y se sienta delante de su PC. ¿Lo primero? Está claro, iniciar sesión en red, revisar los cambios que se hayan podido aplicar en su agenda del día, ahora está más despierto y es más comodo verlo en una pantalla de 24'' y no en un dispositivo portatil. Redactar unos correos desde su cuenta coorporativa, una llamada al jefe y otra a su mujer de nuevo... actualiza su agenda, una cena con un potencial cliente, felicitar el aniversario a los padres... y un compañero le da el teléfono de una amiga de su mujer a quien debe de llamar para organizarle una fiesta. Por la tarde llega a su casa y se ha olvidado de redactar unos correos y recuperar unos archivos del servidor.


Llegados a este punto nuestro sujeto tiene dos opciones. Suponer que está al día él y su empresa en cuanto a tecnologías se refiere o por el contrario que ni le gusta la tecnología ni su empresa le interesa demasiado invertir en ello.

Veamos que sucede a partir de aquí suponiendo primero el segundo caso, es decir, vamos a decir no a la tecnología, por así decirlo:

Son las 7-8 de la tarde y se ha dado cuenta que debe de recoger dichos archivos y enviar dichos correos. Dado que se trata de un correo coorporativo sin acceso al exterior tampoco puede enviarlos desde casa. Deja el maletín en casa y se vuelve al trabajo. Ha tenido la mala suerte ademas de dejar en el maletín tanto la PDA como el movil de empresa, donde había apuntado en la agenda el número de la amiga de su mujer... tenía pensado ahorrar tiempo y llamarla de camino (La oficina está a 30 minutos de su casa). Llega a la oficina, arranca su PC, recupera los archivos del servidor, envia los correos pendientes... En su oficina se cruza con un amigo que le recuerda la despedida de solteros y la apunta en la agenda de su movil personal. Vuelve a casa. Cuando llega ya son las 9 largas, no es hora ya de llamar a nadie para organizar nada... ademas no recuerdas la direccion de tu compañero para enviarle un correo, dicha dirección la tienes en la oficina, en Thunderbirth, así que tendrás que esperar a mañana. Antes de acostarte, con la PDA por un lado, el PC en otro, el teléfono en otro... intentas añadir en la agenda de los demás los nuevos cambios, no quieres que se te escape nada, así como copiar el nuevo número de teléfono. Te pones una notita incluso para recordarte hacer lo mismo al llegar al trabajo, es posible que la secretaria haya añadido algo nuevo a la agenda y claro...


Es evidente que esto sería un infierno y nada productivo. Por otro lado un buen ejecutivo lo que haría sería lo siguiente:

Llegaría a casa, encendería su PC y se conectaría al servidor de su empresa por medio de una VPN. Una vez en red con la empresa, enviaría los correos necesarios y recuperaría los archivos necesarios. Mientras hace todo ello, con el movil personal buscaría en la agenda para llamar a la amiga de su mujer (cuyo número fue grabado en el movil de empresa y está en su maletín) y perfectamente aparecería el número de ella en él. Antes de irse a acostar abriría Lightning en Thunderbirth, revisaría el calendario para el día siguiente en el que ya se habrían añadido de forma automática todos los cambios del día y a dormir.


Esto puede parecer irreal para muchos. Se preguntarán que que personas necesitan coordinar 3 agendas, 4 calendarios diferentes, 5 cuentas de correos... pero es algo bastante normal. Con el correo esto pasa a diario con muchas personas que leen el correo desde sus PCs o desde sus dispositivos portátiles. IMAP nos permite precisamente eso, estar conectados desde donde sea a nuestro correo. Si lo leemos aquí lo leemos allí, si lo enviamos desde aquí recuperaré lo que he leído desde cualquier otro lado. Pero que sucede con el calendadrio, contactos, tareas...

En la actualidad por suerte existen protocolos y sistemas estándares que permiten todo esto y más. ¿Quien no tiene la agenda en su movil y por otro lado la agenda en Gmail con los contactos? O simplemente, quien no tiene dos móviles y alguna vez se ha visto en el problema de tener que pasar los contactos de uno a otro? Y el calendario? citas olvidadas porque esta la añadiste a Windows Calendar y no al calendario de tu iPod, o al revés!!. Si la solución pasa por cada vez que modifico tener que modificar en 6 sitios diferentes... mal negocio. Pues de eso vamos a hablar.

Nos vamos a centrar en tres tipos de datos: Correo, Agenda, Calendario. En realidad esto es aplicable también a las notas y otros, pero nuestro dispositivo no lo permite.



El 1-2-3 de la sincronización:

¿Que es una sincronización? Muchas veces se confunde el término. Normalmente cuando hablamos de sincronizar nos referimos a que dos dispositivos comparten su información para que esta sea la misma en un lugar y en el otro. Si un dato se crea en uno, el dato de algún modo deberá de propagarse hacia el otro dispositivo. Del mismo modo si la sincronización es bidireccional, cualquier cambio realizado en el otro dispositivo se deberá de propagar al nuestro. No solo añadir un dato, lo mismo cuando se modifica, se elimina...

Para esto existen una serie de protocolos y sistemas, algunos de ellos los iremos viendo. Pero antes de entrar en ellos cabe destacar como muy importante lo siguiente.

Aunque existen sistemas para sincronizar datos (ahora los veremos), una de las preguntas inmediatas es ¿Cómo se realiza? Está claro que para que exista una sincronización, del tipo que sea, es necesario acceder al servicio. Cuando por ejemplo abrimos el correo que es lo ¿que estamos haciendo? Enviando datos a nuestro servidor para solicitar la sincronización. Esto es un problema en entornos en los que se necesita tener acceso a la información casi al instante de que esta sea modificada. Imaginar que estamos esperando un correo muy importante. Claro, la solución pasaría por comprobar el correo cada cuanto... 10 segundos? 30 segundos?... Esto para un PC no es un problema, como si queremos comprobarlo cada 10 segundos como si comprobamos cada una hora. Pero imaginar esto en un dispositivo portatil... sería impensable. Aquí podríamos por lo tanto dividir dos tipos de accesos a nuestros datos a sincronizar:


-Polling:

Entenderemos Polling por preguntar. Es el sistema que probablemente use la gran mayoría de las personas, y ojo, no significa que sea malo. Simplemente cuando deseamos obtener la información que sea, ya sea una sincronización o no, solicitamos a nuestro servidor por los nuevos datos. El servidor recoje nuestra petición y nos responde. Cada vez que queramos conocer si tenemso algún dato nuevo, deberemos volver a preguntar. Esto puede ser tedioso si queremos un correo con urgencia o mucho peor... en los dispositivos portátiles. A día de hoy disponemos de una infraestructura inalámbrica muy grande. Tenemos dispositivos 3G, WIFI... en cambio el problema del consumo continua estando presente, y con consumo me refiero a el pago por las tarifas a estas líneas como al consumo de la batería por utilizar dichos recursos.

Realizar Polling implica un consumo de ancho de banda considerable. Imaginar que se configura nuestro cliente de correo para comprobar por correos nuevos cada 1 minuto. Cada minuto una nueva petición, una nueva contestación del servidor. En el caso de que la contestación sea: "No hay datos" la petición ha sido inutil, y esto se repetirá cada minuto. Y además, tan solo tendremos la certeza de tener el mail buscado con un margen temporal de retraso de 1 minuto. Claro que un minuto puede ser poco tiempo... o puede ser un tiempo precioso dependiendo de la urgencia del mensaje. Por otro lado pensar en la gran cantidad de ancho de banda desperdiciado cada minuto, e igualmente del consumo de la batería que llevaría a un dispositivo portatil hacer uso de una red 3G o de WIFI para enviar cada petición. En caso de 3G... el dineral que podría costar un sistema por Polling de un minuto...


-Push

En el otro lado tenemos Push. Push se concibe como el proceso contrario a Polling. Se supone que Polling es un sistema en el que el cliente contacta con el servidor para requerir nuvos datos. Con Push la idea es que será el servidor quien se ponga en contacto con el cliente cuando tenga un dato nuevo. Esto en realidad no es tan simple como puede parecer, puesto que existen muchísimos problemas de otra índole. Antes de entrar en los posibles problemas, las ventajas están claras. Imaginemos Push como un método ideal... nuestro dispositivo simplemente tendría conexión a la red sin hacer uso del ancho de banda y sin estar enviando o recibiendo paquetes, con lo que el consumo de batería lo agradecería enormemente. Llega un correo nuevo a nuestro servidor, nuestro servidor directamente nos envia el correo a nuestro dispositivo y no solo lo tenemos al instante, sino que no tenemos que estar preguntando cada dos por tres, el único ancho de banda que se ha gastado es la recepción del correo.

La mala noticia es que esto no es tan idealista. Evidentemente para que esto pueda hacerse, es necesario que el sevidor se encuentre conectado de algún modo al cliente antes de que el servidor reciba el dato que desea enviar a su vez al cliente. Esto es un problema múltiple. Para que esto sea posible el servidor debería de suponer que siempre conoce nuestra IP, que siempre presupone que hay una regla en el firwall de nuestra red que permita paquetes entrantes sin ser solicitados a nuestro dispositivo, que suponga que nuestro dispositivo estará 24 horas al día disponible... y evidentemente estos supuestos son impensables. ¿En teoría? En teoría sería posible construir un sistema completamente Push... pero no es viable. No obstante estos problemas se atenuan en lo que se pueden.

El problema de la IP siempre será un problema... pero si suponemos que son dispositivos portátiles, las redes 3G suelen otorgar una IP consistente, y suelen estar conectados a la red con dicha IP por mucho tiempo. Con lo que con que al entrar en la red el teléfono o el dispositivo enviara un reconocimiento al servidor, sería suficiente, pero aun así esto implicaría peticiones al servidor, con lo qeu siempre conyeba un tráfico

Por otro lado que nuestro dispositivo esté siempre operativo no puede solucionarse. Se puede imaginar que siempre lo estará, dado que podemos cargarlos mientras se encuentran encendidos... pero es una presunción tan solo. Se deberían implementar mecanismos en los que al apagarse y encender dar a conocer su estado al servidor, lo que conyeva tráfico de datos, lo que se aleja del idealismo de Push

Pero quizás el problema mayor es el de los FireWalls. Si nuestro servidor supiese tan solo con una petición inicial nuestra IP asociada a una cuenta y que nuestro dispositivo se encontrará disponible en las próximas 48 horas (por ejemplo), estaría solucionado. Cuando tan solo tuviese un dato nuevo lo reenviaría a la IP asociada a dicha cuenta y fin del problema. Pero esto en la vida real sería impensable en cuanto a seguridad. Por seguridad, lo normal es que cualquier firewall por pequeño que sea filtre cualquier acceso que no haya sido solicitado. A esto se le llama SPI, es decir, un analizador de los paquetes que entran y salen. Si un paquete llega al dispositivo, ya sea un router o sea un dispositivo final, lo normal es que su firewall compruebe si dicho dispositivo solicitó dicha transferencia. Si no es así el paquete se descarta. Esto es similar (no igual) a cualquier router que opere con NAT. Es evidente que si nos encontrásemos en esta situación (que sucederá muchísimas veces) el problema se complica radicalmente, porque nos obligaría a realizar antes una conexión al servidor para que este nos respondiese. ¿Se puede hacer algo para evitar esto? Sí y no.

Que se me ocurran podrían exister 3 soluciones:

La primera es simplemente deshabilitar cualquier tipo de firewall o NAT en la red a la que estamos conectados, aunque evidentemente esto sería una locura!! un dispositivo abierto completamente a una red?? Claro que en el caso de dispositivos portátiles no vamos a ir instalando Firewalls, pero nuestro router por malo que sea implementara NAT o SPI o los dos. Yo personalmente no lo haría, claro que si estamos conectados a una red 3G el problema no depende de nosotros si este tiene un firewall en sus sistemas, y vuelvo a repetir, que espero enormemente que los tengan, sino hackear un dispositivo portatil conectado por 3G sería coser y cantar, sobre todo cuando cada vez más se usan antenas 3G para los portátiles y otros.

La segunda opción sería menos drástico y simplemente abrir un puerto en nuestros firewall o el firewall de la compañía para permitir cierto tipo de tráfico dirigido a un puerto en concreto. Pero claro... esto tiene el inconveniente que tendríamos que andar configurando nuestros dispositivoos en primer lugar para permitir dichas conexiones, y evidentemente las operadoras deberían especificar con que estandar ellas serían compatibles y en fin... y aun así sería un problema grave de seguridad, un puerto abierto equivale a una brecha por la que se pueden obtener muchísimos datos... más de los deseados.

La tercera opción es la que se suele implementar... rendirnos a la evidencia que usar conexioens directas no es viable en dispositivos portátiles, aunque podría ser la mejor opcion para entornos empresariales y usar dichos sistemas para una red LAN. Pero para dispositivos que pueden conectarse a diferentes redes en diferentes sitios... Aceptar esto, y solucionarlo de la mejor manera posible. Lo que se intenta es mantener una conexión entre servidor y cliente el máximo tiempo posible. Es decir, efectivamente es el cliente quien nada más comenzar solicita acceder al servidor. Pero por el contrario, este no responde, sino que se queda esperando hasta recibir nuevos datos para responder. Cuando el servidor tiene el dato nuevo lo envia como contestación a la petición que a lo mejor se realizó 60 minitos antes, y el correo continua llegando justo en el mismo momento en el que el servidor lo recibe. Una vez el dato llega al cliente, este solicitaría inmediatamente otra petición al servidor y de nuevo se mantendría la conexión el máximo tiempo posible. ¿Inconvenientes? Evidentemente hay muchas peticiones por parte del cliente, una por cada dato recibido más la final, en el mejor de los casos. Digo en el mejor de los casos porque una conexión no se puede mantener activa indefinidamente. Esto ya es algo que depende de la configuración de cada aplicación, dispositivos, routers... por ejemplo, ¿cuanto tiempo es capaz un router de mantener en su tablas NAT o SPI la petición? Está claro que en muchos podrás configurarlo, pero en otros no. Con lo que se debe de establecer un tiempo mínimo y máximo para ello. Después de que ese tiempo se cumpla, si el cliente no recibió ningún dato debería de enviar un paquete al menos tipo Keep-Alive para mantener el canal abierto. A lo mejor no consume tanto como un paquete de datos, pero algo así.

Aun pese a todo, está claro que las virtudes de usar Push en dispositivos de este tipo son muchísimas. En cualquier caso el dato siempre es recivido en el mismo momento en el que llega a nuestro servidor y es evidente que en el peor de los casos, las peticiones realizadas son muchísimo menores que usando Polling. Es evidente que se tendría que buscar cual es el tiempo máximo para no cortar la conexión y otros menesteres, pero continua siedo una opción mucho más ventajosa. Es evidente que tiene un consumo de batería (en caso de dispositivos portátiles) y un consumo de ancho de banda, que sea inferior o no depende tan solo de la implementación y el sistema. Podría ser un sistema Push que andara actualizando las conexiones cada 10 minutos, con lo que a lo mejor en igualdad de condiciones, un Polling de 15 minutos tampoco supondría un consuno excesivo frente al primero.

Evidentemente existen alternativas completamente Push, pero como he dicho en un principio esto no es viable desde mi punto de vista, pero se usa en la actualizada. El método más común es tan solo para dispositivos tipo teléfonos, en los que el servidor envia un SMS al movil del usuario para indicarle que tiene un correo nuevo, y el movil es capaz de autoreconocer dicho sms y conectarse al servidor por 3G o cualquier otra tecnología. La ventaja está clara, notificación al instante y nunca hay ancho de banda desperdiciado ni consumo energético en ello. Evidentemente si hay una infrastructura mayor y SMS involucrados en ello.

Con esto aprendido podemos pasar al siguiente capítulo