No dudo que de tener dicha información la publicaría... y así ha sido en la conferencia anual Black Hat
Dos expertos en seguridad mostraron ante 4.000 invitados como hacerse con el control de cualquier iPhone del mundo tan solo a través de SMS, y no es una broma. Así lo demostraron frente a 4 iPhone diferentes de AT&T, aunque aseguran que debería de funcionar todo igual para cualquier operador.
El fallo de seguridad radica en como maneja el iPhone estos SMS. La mayoría tan solo conoce de los SMS que no son más que textos que se envían de un terminal a otro, pero no es solo eso. Existen multitud de tipos de SMS diferentes, entre los que se incluyen SMS de comandos, por así decirlo. Por ejemplo, es posible usar SMS para indicar a un terminal (que lo soporte claro) que se debe de actualizar. A través de un exploit simplemente se logra ir ejecutando código malicioso en el terminal, hasta que se han enviados suficientes sms como para inyectar el código necesario.
Creo que rondaban los 100-150 SMS necesarios para hacerlo, frente a la posibilidad de tomar el control de cualquier iPhone!! es simple, imaginar que teneis la IP 3G de un iPhone conectado permanentemente a inet y teneis un acceso SSH a él sin que su dueño lo sepa!! y que dicho acceso se lo has configurado/mandado por SMS, sin que su dueño se de cuenta de nada!! ni siquiera que esos SMS le han llegado. El control total del dispositivo es por tanto imaginarlo... desde controlar las llamadas que se hacen, llamar, enviar SMS, acceso a la agenda, correos... todo
Los expertos que han mostrado esto, han explicado igualmente que Apple fue avisada hace ya semanas sobre esta vulnerabilidad, y como es costumbre... Apple hizo oídos sordos. Una vulnerabilidad similar se descubrió en Android, y Google le puso fin casi al mismo instante de ser norificados.
Para males de Apple, Apple sabemos que lanzará la nueva versión 3.1 en poco tiempo... con suerte, y solo con suerte, es de suponer que dicho fallo de seguridad será corregido. Con lo que primero que Apple saque la actualización 3.1, después que en dicha actualización sea arreglado, y por último esperar que los iPhone del mundo la instalen. Esto va a dar un margen de tiempo enorme a cualquier Hacker a crear aplicaciones sencillas para hacerse con el control de los iPhone que se deseen, tan solo sabiendo su número de teléfono.
Que que importancia tiene todo esto? Pues desde mi punto de vista es mayúscula!! Quiere decir que dentro de muy pocos días, una semana, quizás dos... la gran mayoría de todos los iPhone quedarán completamente expuestos a cualquier usuario malicioso. Evidentemente Apple no se ha pronunciado, lo cual no es extraño. Ellos tienen que mantener la postura y el idealismo que intenta marcar siempre a sus clientes de que Apple y su software es lo más seguro. Hacer un comunicado oficial en el que decir que es cierto y que solucionarán el problema "pronto" sería de muy mal gusto, cuando es un fallo de seguridad no grave, gravísimo, lo suficiente al menos desde mi punto de vista para larzar de inmediato una versión 3.0.1 o similar.
En fin... tan solo informo de que en una semanas aproximadamente... tener cuidado si teneis "enemigos" o alguien que les pueda interesar de modo alguno vuestro terminal. No vamos a tardar en ver el exploit en funcionamiento, e incluso despues de Apple lo solucione, pasará mucho tiempo a que se vaya instalando. La estadística dice que menos d el 20% se entretiene en actualizar sus dispositivos... con lo que...
viernes, 31 de julio de 2009
domingo, 19 de julio de 2009
Proyecto: Después del éxito de Hammerfest, Brutus!!. Invirtiendo el tiempo en vacaciones
En vacaciones solemos tener siempre los mismos problemas... nunca hay noticias interesantes y sin embargo si nos lo montamos bien algo más de tiempo libre. Voy a seguir ausente unos días debido a que tengo que terminar de portar todo mi sistema al PC nuevo y posiblemente espere para terminarlo todo a la RTM de Windows 7 que debería de estar para esta semana que entra, por ello es que aun no he actualizado tampoco mi archivo de publicidad para Cydia y esas cosillas... lo siento...
Bueno vamos a dar un adelanto... en realidad esta idea no surgió de mí, dado que nunca me había interesado por este juego que por lo que parece ahora está de moda entre algunos aficionados.
Todo ocurrió hace ya unas semanas cuando un amigo me preguntó si sería posible lograr algo con este juego. Me explicó el funcionamiento del juego a grandes rasgos. Por lo visto lo que se intenta lograr es tener el mayor número de discípulos creo. Bueno, en cuanto termine la migración y otros menesteres explicaré y publicaré un código fuente para que cualquiera pueda compilarlo (tb lo daré compilado, o quizás no de el código... ya veré que hago) para digamos... disparar los discípulos a un nunmero indeterminado de ellos.
¿Gracioso verdad?
Ya iremos diciendo mas cosas...
Bueno vamos a dar un adelanto... en realidad esta idea no surgió de mí, dado que nunca me había interesado por este juego que por lo que parece ahora está de moda entre algunos aficionados.
Todo ocurrió hace ya unas semanas cuando un amigo me preguntó si sería posible lograr algo con este juego. Me explicó el funcionamiento del juego a grandes rasgos. Por lo visto lo que se intenta lograr es tener el mayor número de discípulos creo. Bueno, en cuanto termine la migración y otros menesteres explicaré y publicaré un código fuente para que cualquiera pueda compilarlo (tb lo daré compilado, o quizás no de el código... ya veré que hago) para digamos... disparar los discípulos a un nunmero indeterminado de ellos.
¿Gracioso verdad?
Ya iremos diciendo mas cosas...
miércoles, 8 de julio de 2009
Proyecto: Eliminando publicidad en Cydia y Safari II (Actualizado 19/09/09)
Bueno, por ahora han aparecido dos problemas:
SBSettings chequea por si tenemos añadido en nuestro archivo host bloqueadores de Ads. Esto lo he solucionado a lo facil, redirigiendo el archivo del que se tomará de entrada en vez de "hosts" a "hostt". El archivo no existe, luego la comprobación no es negativa, con lo que sbsettings funciona bien.
Categories usa el mismo sistema. Ahora mismo no tengo categories instalado, pero lo publicaré dentro de poco tambien.
Para poder corregir esto, volver a descargar el archivo de mi repositorio, en el que incluiré una/s versiones modificadas de sbsetting (ya lista) y categorie (aun no incluida) para solucionar esto. Simplemente hay que sustituir los archivos tal y como sustituimos el archivo de host.
SBSettings se encuentra en -> "/Applications/SBSettings/SBSettings". De todos modos intentaré conservar la estructura dentro de mi propio 7z. Siento que no exista un modo mejor de hacerlo... y me temo que deberé de actualizar los parches a medida que actualicen los programas... pero por suerte tampoco existen apenas programas con este problema, por ahora tan solo son dos.
Quien no use estos programas, simplemente que no sustituya dichos archivos.
En realidad esto sería mucho más simple hacerlo a través de Cydia, pero mientras que logro poner el repositorio en linea y mientras no.
Os dejo como quedaría SBSettings, como podeis ver, adios a la publi, y en este caso sí que arranca ahora.
SBSettings chequea por si tenemos añadido en nuestro archivo host bloqueadores de Ads. Esto lo he solucionado a lo facil, redirigiendo el archivo del que se tomará de entrada en vez de "hosts" a "hostt". El archivo no existe, luego la comprobación no es negativa, con lo que sbsettings funciona bien.
Categories usa el mismo sistema. Ahora mismo no tengo categories instalado, pero lo publicaré dentro de poco tambien.
Para poder corregir esto, volver a descargar el archivo de mi repositorio, en el que incluiré una/s versiones modificadas de sbsetting (ya lista) y categorie (aun no incluida) para solucionar esto. Simplemente hay que sustituir los archivos tal y como sustituimos el archivo de host.
SBSettings se encuentra en -> "/Applications/SBSettings/SBSettings". De todos modos intentaré conservar la estructura dentro de mi propio 7z. Siento que no exista un modo mejor de hacerlo... y me temo que deberé de actualizar los parches a medida que actualicen los programas... pero por suerte tampoco existen apenas programas con este problema, por ahora tan solo son dos.
Quien no use estos programas, simplemente que no sustituya dichos archivos.
En realidad esto sería mucho más simple hacerlo a través de Cydia, pero mientras que logro poner el repositorio en linea y mientras no.
Os dejo como quedaría SBSettings, como podeis ver, adios a la publi, y en este caso sí que arranca ahora.
martes, 7 de julio de 2009
iPhone 3GS: Jailbreak
Bueno, de manera oficial se une a la familia el JB para el iPhone 3GS, incluido el Unlock, pero con algunas pegas:
1º. El Unlock tan solo es posible ahora mismo sobre la firmware 3.0, esto incluye la baseband de este. Esto significa q cuando Apple, posiblemente en esta semana, libere la versión 3.1, si se actualice la baseband no podrá realizarse el Unlock.
2º. Para que sea posible hacer el JB, antes es necesario la obstención de los dos archivos citados en una entrada anterior, que serán solicitados por el mismo RedSn0W en su momento. Sin estos archivos, no hay caso. Eso sí, si ya hemos obtenido estos dos archivos, el JB podremos realizarlo cuando queramos.
RedSn0w 0.8
Un saludo a todos.
1º. El Unlock tan solo es posible ahora mismo sobre la firmware 3.0, esto incluye la baseband de este. Esto significa q cuando Apple, posiblemente en esta semana, libere la versión 3.1, si se actualice la baseband no podrá realizarse el Unlock.
2º. Para que sea posible hacer el JB, antes es necesario la obstención de los dos archivos citados en una entrada anterior, que serán solicitados por el mismo RedSn0W en su momento. Sin estos archivos, no hay caso. Eso sí, si ya hemos obtenido estos dos archivos, el JB podremos realizarlo cuando queramos.
RedSn0w 0.8
Un saludo a todos.
viernes, 3 de julio de 2009
Encuesta y barra de búsqueda
La barra de búsqueda era claro que tenía que añadirla... comprendo la complicación que puede ser a veces encontrar algo en un blog, sobre todo despues de tantas entradas publicadas.
Lo segundo es una encuentas. Son muchos que por curiosidad quieren saber mi edad, y tengo curiosidad de saber que edad creeis que tengo. Tres encuentas. La primera intervalos de 20 años, el más votado (sea cierto o no) lo dividiré en otros 4 segmentos y la tercera encuesta en 5. Tengo curuisidad por saber cuan joven o cuan viejo aparento ser detrás de unas letras.
Gracias amigos.
Lo segundo es una encuentas. Son muchos que por curiosidad quieren saber mi edad, y tengo curiosidad de saber que edad creeis que tengo. Tres encuentas. La primera intervalos de 20 años, el más votado (sea cierto o no) lo dividiré en otros 4 segmentos y la tercera encuesta en 5. Tengo curuisidad por saber cuan joven o cuan viejo aparento ser detrás de unas letras.
Gracias amigos.
Proyecto: Eliminando publicidad en Cydia y Safari (Actualizado)
Esto me ha creado un pequeño dilema moral/ético. Llevaba ya un tiempo pensando en si es correcto filtrar la publicidad que aparece por ejemplo en Cydia en cada repositorio, o cuando queremos acceder a la información de una aplicación de Cydia en concreto o... la verdad es que algunas son realmente molestas y consumen un ancho de banda brutal en comparación de lo que consume simplemente lo que es el repositorio o la información util.
Pero claro... por otro lado las aplicaciones de Cydia son en su mayoría gratuitas y los repositorios se hospedan gratuitamente, siendo la publicidad algo de ingresos para ellos, cosa que me parece bien también.
Al final me he decantado por crear el proyecto, y espero que ningún desarrollador de Cydia se moleste. La idea es ir erradicando poco a poco cualquier publicidad no deseada en Cydia e ir extendiendo esto a Safari. En realidad filtrar contenidos es algo muy simple y efectivo, es usado en multitud de programas. Por ejemplo en Firefox tenemos la extensión Adblock plus con la cual nos suscribimso a listas para bloquear los molestos Ads q cada vez más invaden la red. La solución simple para nosotros sin tener que acudir a ningún programa es usar el archivo "hosts".
Esto es algo que he explicado en alguna que otra entrada ya, pero lo comento de nuevo. El archivo "hosts" que existe virtualmente en cualquier OS, es un listado de hosts preconfigurados que usa el sistema operativo para fijar hosts, es decir, mapea nombres de host a direcciones IP. Esto tiene multitud de aplicaciones, luego explicaremos alguna. Su formato es muy simple, una entrada que corresponde a una IP se le asocia un nombre de host. ¿Que significa esto? que cuando cualqueir recurso del sistema tenga que acceder a dicho host, se envía directamente a la IP configurada. En realidad es como un sistema DNS.
Esto tiene una cantidad increible de usos:
-Acelerar la navegacion web añadiendo de forma estática las IPs de los host, con lo que las peticiones DNS no son necesarias para dichos Host, ahorrando ancho de banda y ganando velocidad
-Asignar estáticamente nodos de nuestra propia red, de forma que podamos alcanzar cualquier nodo de nuestra red con un nombre de host.
-Redirigir peticiones de una web (un host) a otra, por ejemplo para empresas o por pura comodidad. Aunque un virus podría dar buena cuenta de ello tambien y usarlo maléficamente. Tu quieres visitar hotmail.com y a todos los efectos estas en dicha página... solo que la iP es diferente y es un sitio Pishing.
-Bloquear contenido. Esta es la opción que le vamos a dar nosotros. Dado que el archivo de hosts hace de tradcutor, podemos hacer que se rediriga cada host a la ip que queramos. ¿Pero que sucede si redirigimos un host a la ip 127.0.0.1?
127.0.0.1 es la direccion de loopback, es decir, es la IP que identifica a tu propio PC en tu PC. Es decir si un programa envia un paquete a dicha dirección IP, lo envía a la interfaz de si mismo. Que sucede si tenemos Apache instalado (un servidor web) y tecleamos en nuestro navegador http://127.0.0.1? Pues que accederemos a la web index.html por defecto de apache, puesto que estaremos accediendo a nuetro mismo PC. Y si no tenemos apache instalado? nos devolverá un error el explorador pq no tenemos ningun servidor corriendo.
Luego si mapeamos un dominio cualquiera a 127.0.0.1, salvamos y accedemos desde el navegador a dicho host, nuestro navegador de firma mágica nos dirá que el host no existe. Que sucede si hacemos un listado de hosts de publicidad mapeados todos a 127.0.0.1? pues que la publicidad de dichos dominios no aparecerá, ni siquiera se solicitará al exterior puesto que internamente la buscará en nuestro propio PC. No hay consumo de ancho de banda de nuestra linea y nos quitamos los molestos ads.
Mi primer objetivo es eliminar la publicidad que pueda de Cydia con este método. Ya podeis descargar el archivo "hotst" que iré poco a poco modificando. Lo teneis a la derecha, en mi blog. Lo descargais, descomprimir y lo copiais y sustituis en el iPod/iPhone, en la ruta:
/private/etc -> Permisos 0644, archivo copiado como root.
No hace falta siquiera reiniciar. Por ahora croe que está eliminada toda la publicidad de todos los repositorios que vienen por defecto en Cydia menos el de iSpazio, debido a que no usan un host propio para ello, y si lo bloquease por este método, bloquearía el acceso tb al repositorio.
El archivo host especifica que hosts bloqueados estan en cada repositorio, aunque no es del todo exacto. Por ejemplo se bloquean los Ads de Google, y es algo que no es exclusivo del repositorio de BigBoss. Todos los ads bloqueados no solo corresponden Cydia, sino que safari o cualquier otra aplicación tendrá acceso a ellos.
Esto quiere decir que espero la colaboración de el resto para que si usando mi archivo de Host encuentra alguna publicidad en Cydia (que no sea la de iSpazio) que me lo deje en lso comentarios que repositorio fue y q me indique información sobre ella.
He dejado por motivos obios los logotipos de cada repositorio, no los considero publicidad, y además sería problemático bloquearlos
Con el tiempo iré creciendo el archivo y bloqueando mas y más ads de safari, por ahora tan solo los que afectan directamente a Cydia, aunque indirectamente los bloquea tb en safari. En safari empezaré por los más usuales.
sé que existen archivos hosts para descargar con listados interminables de adss, pero esa no es mi idea. Para empezar pq esos listados puden ocupar hasta cantidades de 1MB!! lo que haría el procesado de dicho archivo bastante pesado, y además nuestro dispositivo no es que ande muy sobrado de RAM. Así que por ahora me limitaré a ir filtrando poco a poco lo que sea más habitual. Repito, quien tenga interes por eliminar la publicidad de algunos sitios web comunes que lo diga que los añado.
Iba a poner algunas imágenes mostrando Cydia, pero os lo vais a tener que imaginar, otro día
Nada más por hoy... y posiblemente hasta el martes, que un servidor tiene que disfrutar del sol y el mar.
Actualizado: Nota!! la aplicación Categorie de Cydia usa banners de publicidad molestos que están bloqueados por mi version de archivo host. El problema es que la aplicación chequea si el archivo host está bloqueando dichas entradas, y de encontrarla simplemente reusa a ejecutar Categories. Es un método para obligar a tener los Spam aun cuando se use mi sistema. no obstente posiblemente o doy con una solución a esto, o parcheo categories para que no compruebe esto. Odio este tipo de sistemas.
Pero claro... por otro lado las aplicaciones de Cydia son en su mayoría gratuitas y los repositorios se hospedan gratuitamente, siendo la publicidad algo de ingresos para ellos, cosa que me parece bien también.
Al final me he decantado por crear el proyecto, y espero que ningún desarrollador de Cydia se moleste. La idea es ir erradicando poco a poco cualquier publicidad no deseada en Cydia e ir extendiendo esto a Safari. En realidad filtrar contenidos es algo muy simple y efectivo, es usado en multitud de programas. Por ejemplo en Firefox tenemos la extensión Adblock plus con la cual nos suscribimso a listas para bloquear los molestos Ads q cada vez más invaden la red. La solución simple para nosotros sin tener que acudir a ningún programa es usar el archivo "hosts".
Esto es algo que he explicado en alguna que otra entrada ya, pero lo comento de nuevo. El archivo "hosts" que existe virtualmente en cualquier OS, es un listado de hosts preconfigurados que usa el sistema operativo para fijar hosts, es decir, mapea nombres de host a direcciones IP. Esto tiene multitud de aplicaciones, luego explicaremos alguna. Su formato es muy simple, una entrada que corresponde a una IP se le asocia un nombre de host. ¿Que significa esto? que cuando cualqueir recurso del sistema tenga que acceder a dicho host, se envía directamente a la IP configurada. En realidad es como un sistema DNS.
Esto tiene una cantidad increible de usos:
-Acelerar la navegacion web añadiendo de forma estática las IPs de los host, con lo que las peticiones DNS no son necesarias para dichos Host, ahorrando ancho de banda y ganando velocidad
-Asignar estáticamente nodos de nuestra propia red, de forma que podamos alcanzar cualquier nodo de nuestra red con un nombre de host.
-Redirigir peticiones de una web (un host) a otra, por ejemplo para empresas o por pura comodidad. Aunque un virus podría dar buena cuenta de ello tambien y usarlo maléficamente. Tu quieres visitar hotmail.com y a todos los efectos estas en dicha página... solo que la iP es diferente y es un sitio Pishing.
-Bloquear contenido. Esta es la opción que le vamos a dar nosotros. Dado que el archivo de hosts hace de tradcutor, podemos hacer que se rediriga cada host a la ip que queramos. ¿Pero que sucede si redirigimos un host a la ip 127.0.0.1?
127.0.0.1 es la direccion de loopback, es decir, es la IP que identifica a tu propio PC en tu PC. Es decir si un programa envia un paquete a dicha dirección IP, lo envía a la interfaz de si mismo. Que sucede si tenemos Apache instalado (un servidor web) y tecleamos en nuestro navegador http://127.0.0.1? Pues que accederemos a la web index.html por defecto de apache, puesto que estaremos accediendo a nuetro mismo PC. Y si no tenemos apache instalado? nos devolverá un error el explorador pq no tenemos ningun servidor corriendo.
Luego si mapeamos un dominio cualquiera a 127.0.0.1, salvamos y accedemos desde el navegador a dicho host, nuestro navegador de firma mágica nos dirá que el host no existe. Que sucede si hacemos un listado de hosts de publicidad mapeados todos a 127.0.0.1? pues que la publicidad de dichos dominios no aparecerá, ni siquiera se solicitará al exterior puesto que internamente la buscará en nuestro propio PC. No hay consumo de ancho de banda de nuestra linea y nos quitamos los molestos ads.
Mi primer objetivo es eliminar la publicidad que pueda de Cydia con este método. Ya podeis descargar el archivo "hotst" que iré poco a poco modificando. Lo teneis a la derecha, en mi blog. Lo descargais, descomprimir y lo copiais y sustituis en el iPod/iPhone, en la ruta:
/private/etc -> Permisos 0644, archivo copiado como root.
No hace falta siquiera reiniciar. Por ahora croe que está eliminada toda la publicidad de todos los repositorios que vienen por defecto en Cydia menos el de iSpazio, debido a que no usan un host propio para ello, y si lo bloquease por este método, bloquearía el acceso tb al repositorio.
El archivo host especifica que hosts bloqueados estan en cada repositorio, aunque no es del todo exacto. Por ejemplo se bloquean los Ads de Google, y es algo que no es exclusivo del repositorio de BigBoss. Todos los ads bloqueados no solo corresponden Cydia, sino que safari o cualquier otra aplicación tendrá acceso a ellos.
Esto quiere decir que espero la colaboración de el resto para que si usando mi archivo de Host encuentra alguna publicidad en Cydia (que no sea la de iSpazio) que me lo deje en lso comentarios que repositorio fue y q me indique información sobre ella.
He dejado por motivos obios los logotipos de cada repositorio, no los considero publicidad, y además sería problemático bloquearlos
Con el tiempo iré creciendo el archivo y bloqueando mas y más ads de safari, por ahora tan solo los que afectan directamente a Cydia, aunque indirectamente los bloquea tb en safari. En safari empezaré por los más usuales.
sé que existen archivos hosts para descargar con listados interminables de adss, pero esa no es mi idea. Para empezar pq esos listados puden ocupar hasta cantidades de 1MB!! lo que haría el procesado de dicho archivo bastante pesado, y además nuestro dispositivo no es que ande muy sobrado de RAM. Así que por ahora me limitaré a ir filtrando poco a poco lo que sea más habitual. Repito, quien tenga interes por eliminar la publicidad de algunos sitios web comunes que lo diga que los añado.
Iba a poner algunas imágenes mostrando Cydia, pero os lo vais a tener que imaginar, otro día
Nada más por hoy... y posiblemente hasta el martes, que un servidor tiene que disfrutar del sol y el mar.
Actualizado: Nota!! la aplicación Categorie de Cydia usa banners de publicidad molestos que están bloqueados por mi version de archivo host. El problema es que la aplicación chequea si el archivo host está bloqueando dichas entradas, y de encontrarla simplemente reusa a ejecutar Categories. Es un método para obligar a tener los Spam aun cuando se use mi sistema. no obstente posiblemente o doy con una solución a esto, o parcheo categories para que no compruebe esto. Odio este tipo de sistemas.
jueves, 2 de julio de 2009
iPhone 3GS: Jailbreak III
Ya dijimos que será posible JB y unlock vuestro iPhone 3GS, pero por ahroa con algo de trabajo manual. Para poder llevar esto a cabo (cuando salga), será necesario disponer antes de dos archivos concretos para nustro dispositivo. Estos dos archivos son únicos para cada dispositivo, no vale ningún otro, y la única forma de obtenerlos es cada uno los suyos. Sin estos archivos sera imposible el JB, con lo que animará a cualquier de vosotros a obtenerlos. La idea es extraer el iBEC y el iBSS de vuestro iphone, pero ya firmado y preparado. Estos archivos son los que permiten establecer correctamente nuestro dispositivo en modo DFU o en modo de restauración, pero en el caso del iPhone 3GS estos archivos tienen q estar firmado para nuestro dispositivo y esto tan solo es posibel con un ID hardware que tiene nuestro dispositivo.
Hay dos formas de hacer esto. La primera es viendo la forma en la q itunes y el iphone 3gs se comunican y ser capaces de interceptar el ID hardware de nuestro dispositivo y poder realizar una firma de dichos archivos. La otra opcion es capturar estos archivos, q es lo q vamos a hacer. ¿Como?
Por suerte, estos archivos son creados en nuestro PC durente el proceso de restauración/DFU de nuestro dispositivo. Cuando el proceso termina, los archivos temporales son eliminados. Con lo que el proceso es simple!! Realizar una restauración primera y vigilar nuestra carpeta de temporales, cuando empiece la restauración debería de aparecer una carpeta temporal donde estaría nuestro iBEC. Posteriormente ponerlo en modo DFU, restaurar y hacer lo mismo, copiar la carpeta temporal creada a un sitio seguro y listo.
los archivos necesarios son:
iBEC.n88ap.RELEASE.dfu
iBSS.n88ap.RELEASE.dfu
ambos archivos se encontrarán en las carpetas temporales copiadas
Hay que tener en cuenta que dichas carpetas temporales tan solo estaran disponibles durante X tiempo, así q se deben de copiar a otra localidad. He visto en algunos sitios donde aparecen imagenes del proceso, especifican las rutas de temporales... yo soy de los que opina que un proceso así tan solo lo realice quien sabe un mínimo! al menos que son los archivos temporales, donde encontrarlos, etc...
Con lo dicho estoy seguro que quien sea responsable y sepa un mínimo de lo que está haciendo, será capaz de hacerlo.
Hay dos formas de hacer esto. La primera es viendo la forma en la q itunes y el iphone 3gs se comunican y ser capaces de interceptar el ID hardware de nuestro dispositivo y poder realizar una firma de dichos archivos. La otra opcion es capturar estos archivos, q es lo q vamos a hacer. ¿Como?
Por suerte, estos archivos son creados en nuestro PC durente el proceso de restauración/DFU de nuestro dispositivo. Cuando el proceso termina, los archivos temporales son eliminados. Con lo que el proceso es simple!! Realizar una restauración primera y vigilar nuestra carpeta de temporales, cuando empiece la restauración debería de aparecer una carpeta temporal donde estaría nuestro iBEC. Posteriormente ponerlo en modo DFU, restaurar y hacer lo mismo, copiar la carpeta temporal creada a un sitio seguro y listo.
los archivos necesarios son:
iBEC.n88ap.RELEASE.dfu
iBSS.n88ap.RELEASE.dfu
ambos archivos se encontrarán en las carpetas temporales copiadas
Hay que tener en cuenta que dichas carpetas temporales tan solo estaran disponibles durante X tiempo, así q se deben de copiar a otra localidad. He visto en algunos sitios donde aparecen imagenes del proceso, especifican las rutas de temporales... yo soy de los que opina que un proceso así tan solo lo realice quien sabe un mínimo! al menos que son los archivos temporales, donde encontrarlos, etc...
Con lo dicho estoy seguro que quien sea responsable y sepa un mínimo de lo que está haciendo, será capaz de hacerlo.
Artículo: Sincronización (Parte II)
Hemos visto en la primera parte la importancia de tener mecanismos que nos ayuden a sincronizar nuestros datos a lo largo de nuestros diferentes dispositivos. Ahora veremos los mecanismos que tenemos a nuestra disposición para tales efectos. Estos sistemas dependerán de los datos que deseemos sincronizar evidentemente, y evidentemente las limitaciones que tendremos vendran por parte de los servicios que estamos usando y del software cliente. Nos vamos a centrar en tres apartados, aunque se podrían sincronizar otro tipo de datos, y existen protocolos para ello, pero por ahora tan solo nos vamos a centrar en: Correo, Agenda y Calendario.
Correo:
Existen dos protocolos universalmente aceptados y estándares, bien conocidos por casi todos que serían POP e IMAP. Cada uno de ellos tiene sus pros y sus contras. Aunque parezca lo contrario, POP e IMAP sería una forma de sincronización de correo. a fin de cuentas podemos enviar correos, recibirlos... desde cualquier lugar gracias a estos protocolos. Parece curioso como aun siendo sistemas de sincronización (aunque quizás podríamos decir que POP no lo es) sus usuarios no saben en realidad que estan usando dichas tecnologías. No me gustan las tablas comparativas sobre que es mejor que no es mejor, que funciones tiene uno que el otro no... cada cual que saque sus propias conclusiones.
POP:
Si bien sabemos que POP no es un sistema de sincronización dado que tan solo se dedica a descagar el correo y ya está, podríamos decir que actua más o menso como un sistema de Polling de sincronización, aunque como digo no sería puramente un sistema como tal. Dependiendo de la gran cantidad de implementaciones de POP, el servidor podrá retener o no una copia del correo que se descarga. Lo más habitual es que las cuentas POP tan solo son útiles en la gran mayoría de los casos para entornos donde tan solo se desea leer el corro desde un sitio, dado que una vez el correo es descargado desde dicho dispositivo no se podrá recuperar desde otro.
Sobre POP al igual que IMAP se dedicó una entrada extensiva sobre ello, con lo que tampoco vamos a entrar en muchos detalles. Evidentemente, como todo protocolo o sistema usado, si deseamso hacer uso de esta tecnología, deberemos tener un proveedor de correo electrónico que permita conexiones POP y un cliente que permita realizar la conexión.
Pros: Rápido, facil de implementar.
Contras: No sería conveniente para leer el correo desde dos ubicaciones diferentes, tampoco es un sistema real de sincronización, los cambios efectuados tan solo se reflejan en local, no el servidor de correos mismo. En teoría no acepta tampoco carpetas de trabajo, dado que tan solo es un "descargador de correos". Al realizar accesos por Polling, hasta que no se realiza una petición, no sabremos si tenemos un correo nuevo
Consumo: Dado que es un método de Polling, significa que el consumo de ancho de banda o energético, será proporcional simplemente al número de veces que se realicen comprobaciones al servidor. No es un sistema optimizado, muchas de las peticiones devolverán cero correos, con lo que el ancho de banda y el consumo energético por ello será en vano.
Pese los pros/contras y consuno, no obstante para el usuario medio puede ser incluso más eficiente y mejor, dado que a lo mejor este usuario tan solo desea leer el correo una vez al día, siempre desde el mismo lugar, y por seguro que algún correo tendrá. Con lo que será consultar, descargar y se acabó, el consumo en este caso sería poco y los contras de POP no le implicarían nada. Se tendría acceso a los correos en el momento en el que se realizase la petición, si no hay petición no sabremos si hay correo.
IMAP:
IMAP es bastante más sofisticado. En este caso si podríamos hablar de una sincronización propiamente dicha, ya que cualquier dispositivo podrá acceder incluso a la vez a su servidor para recuperar cualquier correo. Cualquier cambio incluso q se realice de forma local se verá afectado en su servidor, con lo que podemos decir q la información se encuentra sincronizada en todo momento. Un mensaje leído desde IMAP permanecerá leído para todos los dispositivos, un mensaje eliminado estará eliminado en todos. Este sistema evidentemente será conveniente según las necesidades de cada uno. Si tan solo deseamos gestionar el correo en un PC y de manera rápida, simple, sin complicaciones y otros, a alguno podría interesarle usar POP en lugar de IMAP. Y al igual que POP, tendrá que ser un protocolo soportado por nuestro proveedor de correos y nuestro cliente.
Es importante destacar que tanto IMAP como POP realizan las peticiones al servidor de correo mediante Polling.
Pros: Sincroniza los correos, permite trabajar en local y sincronizar cuando esté online por ejemplo. Es una interfaz directa a nuestro servidor de correo. Permite la descarga selectiva de cabeceras o correos enteros, trabajar con carpetas y al estar sincronizadas, cualquier ubicación trabajará exactamente igual. Permite por tanto el acceso simultaneo a la cuenta, etc etc... Puede permitir tambien realizar búsquedas de correo sobre el servidor.
Contras: Es un sistema muchísimo más complejo que POP (POP es un sistema muy simple), y dado que todo se realiza de forma sincronizada, suele ser más lento, por ejemplo si guardamos una plantilla, la plantilla lo normal es que se guarda en el servidor, con el tiempo necesario para enviar dichos datos al servidor. Dado que es un sistema más complejo, normalmente los proveedores de correo no todos implementan IMAP. Al realizar accesos por Polling, hasta que no se realiza una petición, no sabremos si tenemos un correo nuevo
Consumo: En cuanto a consumo de ancho de banda suele consumir más que POP. Esto es pq cliente y servidor intercambian mayor información que simplemente los correos. Por otro lado tb el cliente suele enviar datos al servidor como por ejemplo que un mensaje ha sido eliminado, leído o guardado un borrador. Todo ello es ancho de banda, que implica proporcionalmente un incremente en cualquier consumo energético.
Este caso sería ideal para cualquier usuario con accesos desde diferentes lugares a sus cuentas, sacrificas algo de ancho de banda y mayor consumo para poder tener una sincronización real que de otro modo no tendrías. De nueco recordamos que una tecnología no es mejor o peor por sus recursos, sino para lo que se requiera si cumple con los objetivos.
IMAP IDLE:
Está aceptado como estandar. Es una extensión a IMAP que permite realizar un sistema de Push en vez de Polling. Consiste como hemos dicho anteriormente, en enviar una petición de espera latente, en la que nuestro cliente se mantendrá conectado por un tiempo "muy largo" a nuestro servidor. Cuando a nuestro servidor llega un correo entrante, este nos lo notifica por la conexión que está a la espera, con lo que la notificación debería de ser inmediata. Por lo demás su funcionamiento es igual a IMAP.
Su eficiencia no obstante depende normalmente de la implementación de cada servidor y sobre todo cada cliente. Posíblemente el parámetro más importante sería desde mi punto de vista cada cuanto tiempo máximo se debe de enviar una señal de KeepAlive. Como ya vimos en la primera parte de este manual, no podemos dejar eternamente una conexión establecida por diversos factores. Los dos más inmediatos son el TimeOut por parte del servidor y el TimeOut por parte de nuestro routers en caso de estar detrás de uno.
Esto que significa?. El TimeOut por parte del servidor es un tiempo establecido en ellos por el cual si no se detecta actividad de dicha conexión en ese tiempo, la conexión se cierra. Lo mismo sucede con el TimeOut de cualquier router que use NAT, la conexión se desecha de pasar un cierto tiempo. Esto quiere decir que el cliente que quiere mantenerse en modo idle debe de encargarse en mantener la conexión abierta. El como y cada cuanto tiempo, depende tan solo del cliente.
En teoría la norma es que antes de que sucedan los 30 minutos desde avisar del estado idle, se debe de dar por terminado el estado idle y rehacer la petición odle para otros 30 minutos. Esto es al margen de los correos, luego explico como funciona el sistema. Esto quiere decir que cada 30 minutos máximos nuestro cliente debería de hacer uso de nuevo del ancho de banda para realizar dichas peticiones. Lo normal llegado a este punto es usar comandos IMAP NOOP que significa "no hacer nada". Básicamente es como hacer un ACK o un pin al servidor destino para que este refresque la conexión, usando muy pocos bytes de información para ello. En teoría forzando muchos los tiempos se podría usar comandos NOOP cada 29 minutos. Cada 29 minutos existiría un consumo mínimo de ancho de banda y en consecuencia de transmisión de datos = consumo energético. El problema es que estos 29 minutos serían tan solo el salvaguarda de cara al servidor, no de cara a nusetro router. ¿Y como saber el TimeOut de este? Pues a menos que el router disponga de un sistema para saberlo, ya sea por web o telnet... tocará probar. Lo normal es que los router desechen conexiones pasados los 10-20 minutos. Mi Router por ejemplo se puede establecer el TimeOut, y ahora mismo lo tengo establecido en 60 minutos, con lo que en mi caso no sería problema.
Para terminar decir que los clientes IMAP IDLE suelen estar configurados de manera genérica para realizar NOOP cada 15 minutos aproximadamente. Ni que decir tiene que si la conexion se finaliza por tiempo de espera o por cualquier otra causa, estaríamos en el peor de los casos, y la conexion se debería de reestablecer de nuevo.
Os dejo unas capturas de pantalla de una sesión IMAP IDLE a la vieja usanza. La primera hace referencia exactamente a que sucede si no se ejecutan comandos tipo NOOP (u otros sistemas) para mantener la conexión abierta:
El primer paquete de la lista es la petición de idle. El servidor contesta con un ack y acto seguido responde con que se ha "activado" el modo idle y mi pc contesta con el ack correspondiente. Si os fijais en los tiempos, la conexión se queda ahí. Pasados 30 minutos el servidor al no detectar ninguna actividad en la conexión, inicia el handshake de fin de conexión.
¿Pero que sucede de cara a la sesión?
Los puntos rojos corresponden a lo que sería el cliente. El resto son las respuestas del servidor. Todo lo que precede al comando "IDLE", es simplemente la autentificación y pido solicitud de la bandeja de entrada, que dice que tengo 0 mensajes nuevos. Despues ejecuto "idle". 6 minutos después me envio un correo desde otra cuenta y que sucede? que segundos después aparece en pantalla la respuesta por parte del servidor a mi cliente avisando de que el correo número 10187 acaba de llegar. Minutos más tarde me vuelvo a enviar un correo, y de nuevo el aviso es recibido correctamente. Para acabar la sesión tecleo "done" para dar por finalizada la sesión idle y listo.
En este caso google soporta perfectamente IDLE. Para comprobar esto de todos modos tan solo sería necesario con teclear en la sesion IMAP anterior el comando ". capability". Se puede apreciar como todos mis comandos están antecedidos por un punto. En realidad puede ser cualquier cosa, es una etiqueta. Se usa debido a que se permiten sesiones múltiples por IMAP, y de esta forma se identifica mi sesión actual. Si el servidor me responde con un "." será un mensaje de respuesta a mi sesión específica, si responde con * son respuestas de modo global.
Un buen cliente compatible con IMAP IDLE debería por tanto mantenerse a la espera el máximo tiempo posible antes de enviar un ack/ping/NOOP...
La pregunta inmediata: ¿Es compatible la aplicación de nusetro dispositivo con IMAP IDLE? Por desgracia a Apple también se le olvidó implementar dicha extensión. Es posible que por el incremento en consumo, pero tampoco tendría esto mucho sentido dado que si permite realizar Polling incluso cada minuto!!, que seguro que el consumo sería muy muy superior. He visto comentarios de quienes afirman que si soporta IMAP IDLE, pero creerme, no lo hace.
Pros: Los correos llegan exactamente al momento, sin necesidad de requerir la petición al servidor. Esto puede evitar en caso de ser algo crítico, el uso intensivo del ancho de banda requerido que se necesitaría para realizar Polling cada 10 segundos a lo mejor.
Contras: Evidentemente aunque tenga un consumo bajo de ancho de banda, algo siempre existe, aunque se intenta minimizar lo máximo posible. No está considerado como un sistema Push puro, para ello se necesitaría acudir a sistemas de notificación SMS o similar.
Consumo: Inferior o superior a IMAP dependiendo de cada cuanto tiempo se tenga establecido el Polling. Si la idea es comprobar el correo cada 24 horas, IMAP IDLE es un consumo excesivo. Si deseamos ser notificados al instante de correo nuevo por el contrario, IMAP IDLE es la solución, ya que con IMAP tendríamos que realizar un Polling cada muy poco tiempo y ello llevaría a un enorme consumo.
P-IMAP
P-IMAP es una solución no estandarizada para realizar Push por IMAP. En realidad es un sistema similar a IMAP IDLE, aunque mas que similar deberíamos decir que IMAP IDLE forma parte añadida de P-IMAP. Pero por otro lado P-IMAP ofrece la posibilidad de que la notificación se realice por SMS o más automatizado por vía de WAP Push. Pero en esencia es lo mismo. Posiblemente no se llegue a estandarizar nunca dado las grandes diferencias entre compañias, el tipo de SMS, el tipo de WAP Push... depende de tecnologías que estas depende a su vez de las compañías. Aunque existe el planteamiento por algunos de que sea un estandar, dudo mucho que se convierta como tal, existiendo como ya existen IMAP IDLE. Es posible no obstante que en un futuro veamos IMAP4 actualizado para dar soporte a alguna tecnología estandarizada para tal efecto.
Al ser por tanto un sistema no estandar, su utilización por parte de servidores y clientes se ve reducido enórmemente, siendo ahora mismo usado básicamente por algunos programas y servidores, mientras que IMAP IDLE gana adeptos y cada vez más servidores lo permiten. Con lo que tampoco me gustaría darle más importancia a ello
Pros: Verdadero Push por medio de SMS o WAP Push.
Contras: En realidad las diferencias entre IMAP IDLE puede no ser justificable para la infrastructura requerida. Tener en cuenta que los servicios de notificación SMS o Push SMS suele ser un coste adicional por parte de nuestro operador, ISP o proveedor, con lo que para el usuario medio no sería una opción viable.
Consumo: Si se usa un sistema vía SMS por ejemplo, tan solo existe un consumo cuando se solicita la recepción del correo. En este caso nuestro dispositivo sabrá a ciencia exacta cuando ha llegado un correo y que puede descargarlo, iniciando una conexión desde cero nueva, sin neecsidad de mantener la conexión activa.
Existen sistemas de sincronización globales, pero esos los trataremos al final como protocolos de sincroniazción. Es cierto que IMAP pueda ser un protocolo de sincronización, pero me refiero a sistemas globales como pueda serlo GoogleSync, SyncML, ActiveSync, MobileMe...
-----------------------------------------
-----------------------------------------
Agenda y Calendarios:
Ahora nos toca abordar la agenda y los calendarios. Normalmente un recurso mucho más usado que el mismo correo electrónico, ya sea para buscar números de teléfonos, para buscar direcciones, notas... apuntar citas, cumpleaños, reuniones... hoy en día es casi imprescindible una buena agenda/calendario actualizadas. Y de eso vamos a tratar fundamentalmente, actualizada.
Al contrario que los correos, la agenda y el calendario tienen un problema añadido que no suponía para el correo, y este problema provoca la mayoría de los dolores de cabeza. Las incompatibilidades.
Está claro que un correo es un correo, un estandar definido perfectamente, ya sea un correo encriptado, un correo HTML, un correo en texto plano, los destinatarios que sean (ocultos, copias..). Está todo perfectamente definido, e incluso se puede expandir gracias a etiquetas concretas para ello. Pero para los calendarios y agendas electrónicas esto no es así. Sí, claro que existen estándares, pero luego cada cual hace un poco lo que quiere. Así por ejemplo en las agendas podemos ver algunas que puedes introducir todos los números de telefonos que desees, en cambio otros solo uno de casa y otro de trabajo, otros a lo mejor puedes configurar 3, pero no especificar de que tipo son... así con casi cualquier campo que podamos encontrar en uan agenda: Dirección, telefonos, correos, foto, notas, cumpleaños, empresa, nombre... algunas agendas tan solo computan un nombre en el que incluyen el apellido, otros tienen campos específicos para un solo apellido donde van los dos, otras dos apellidos... bueno creo que todos nos hacemos ya una idea de lo que implica esto. En caso de los calendarios es lo mismo, aunque tienen además el agrabante de los usos horarios, interpretar las mismas fechas... un caos.
Si esto es así, como diablos vamos a ser capaces de encajar (usando ya el protocolo que sea) una agenda que tiene mil campos en una agenda que tan solo contempla 10. Gracias a dios cada vez está todo más estandarizado y más o menos se tiende a una norma. Pero aun hoy por hoy existe cierta variedad de formatos diferentes, implementaciones de cada uno... aquí es cuando se agradece a aquellos que intentan en la medida de lo posible estandarizar las cosas.
Por ejemplo desde mi punto de vista, podemos tener a un lado SonyEriccson. Desde que han ido existiendo los estándares se han ido ciñedo a ellos: Agendas, calendarios, Bluetooth, notas, correo... Ventajas? es evidente, una mayor interoperatibidad. Al otro lado por ejemplo podemos ver Nokia. Una compañía que desde siempre ha intentado hacer las cosas a su modo (Como Apple). Hasta hace muy poco (algunos aun seguro que lo recordaran) si tenías Nokia, para poder pasar por BT un archivo ambos tenian que ser nokia, o el formato propietario para agenda/calendario, o para las notas usan simples arcihvos de texto... esto implica a la larga problemas. Tiene su lógica. Algunos desarrolladores (empresas) consideran que para el usuario final prima la versatilidad, la interoperabilidad... para otros prima el sello, el dar por culo y la exclusividad. ¿Que sucede con el tiempo? Que los estándares se afianzan, y las compañías que llevan años y años apollándolos sacan ventajas en implementaciones, velocidad, ideas... Así sucede por ejemplo q es tremendamente simple manejar un teléfono de SonyEriccson mediante comandos AT, o tener la seguridad casi del 100% que no vas a tener un solo problema de compatibilidad con nada.
Si volvemos a Apple, el problema es aun mayor. Apple en sus iPhone e iPod Touch usa formatos propios incluso en el sistema de guardado en disco. Esto puede hacer para muchos un infierno. No os podeis imaginar la de personas que me han preguntado como pueden exportar su agenda en sus teléfonos y meterla en un iPod o un iPhone y al revés. Gracias Apple por complicarnos la vida. ¿Que es lo que sucede al final? Que lo que podría ser algo muy simple si nativamente usa un estandar, a la hora de usar protocolos de sincronización estándares tienes que montar un jaleo increible para convertir los datos, adaptarlos... etc. Y muchos preguntarán... claro, pero al menos usan protocolos estándares, eso es bueno. Sí, es bueno, pero es que ha sido por obligación más que nada. Apple ya usaba (y usa, y lo veremos más adelante) como protocolos propietario de sincronización MobileMe. ¿Que sucede? Que además de ser de pago, no lo usa ni el tato, de ahí ahora a añadir la funcion de localización remota y demás... hay que intentar lo que sea. Si Apple no hubiese implementado protocolos como los que veremos ahora, el volumen de ventas para empresarios sería casi nulo, que ya de por si es muy bajo en comparación con BlackBerry.
Bueno, dejando todo ello a un lado... En el caso de la agenda y el calendario es diferente al del correo, puesto que para tener una agenda o un calendario no hace falta una conexión a inet la mayoría de las veces, no tienes que enviar nada, con lo que la sincronización o la conexión es completamente opcional.
Por eso mismo sería absurdo intentar listar cada uno de los formatos existentes, pues aunque existen algunos estándares como puedan serlo ldif, vcard, vcal... luego cada programador hace la implementación que le da la gana.
Directorios LDAP:
LDAP en realidad no se constituyó como agendas de teléfono o contactos. LDAP es un protocolo de acceso, sincronización y modificación a un directorio... una base de datos. En cierto modo son bases de datos estructuradas con un formato propio, con un acceso propio y otros, pero se puede asemejar a ello. Su uso es bastante abitual, por ejemplo en los servidores de DNS. Por como funcionan estos es muy común usar LDAP para las DNS. Pero al caso que nos atañe a nosotros, es para su uso como agenda.
Pero claro... ¿cual es entonces la idea de LDAP como agenda? Lo normal es usar una agenda siempre en local, pero pensar en una empresa. Una empresa con 1000 trabajodes por ejemplo, cada uno con su nombre apellidos y pongamos por ejemplo el correo electrónico de ellas. Sería tremendamente útil de cara a todos los trabajadores que todos los trabajadores tuviesen acceso a un directorio LDAP con dicha información, además a lo mejor de otro privado. De un solo golpe todos los trabajadores serían capaces de tener acceso a todos los correos de todos los compañeros.
Otro uso normal sería el que andamos explicando. La sincronización. Tener en algún servidor centralizado nuestra agenda LDIF (formato usado normalmente para LDAP), de modo que desde cualquier ubicación pudiésemos no solo tener acceso a ella, sino también modificarla.
Las posibilidades son muchísimas.
CalDav
Por un lado podríamos decir que es el homólogo a LDAP para calendarios, pero en realidad decir esto sería incorrecto. CalDav no es en sí una forma de almacenar datos, no es una base de datos, no es un sistema de directorios... es básicamente un protocolo de sincronización para calendarios usando el formato de calendarios iCalendar, y al margen de lo que pueda pensar ya la mayoría por la 'i' delante, no, no se trata de un formato desarrollado por Apple ni muchísimo menos, es un estandar en cuanto a calendarios se refiere, y CalDav es el protocolo de sincronización para ello. Esto nos permite por lo tanto poder acceder al igual que hacemos por LDAP a nuestra agenda, a nuestro calendario, estemos donde estemos, y teniendo la certeza que modifiquemos lo que modifiquemos los cambios serán propagados por todos nuestros dispositivos en el momento que estos se vayan conectando.
Ambos sistemas que estamos explicando, pueden ser a su vez ser accedios mediante Polling o mediante Push. Recordar que el protocolo de sincronización es el que realiza la comparación de los datos por así decirlo, pero por encima de ello hay alguien que inicia la transmisión de los datos, que se conecta, que... y al igual que el correo, dado que son accesos directos a los servidores, esto se puede hacer manualmente mediante Polling (Preguntando al servidor si ha ocurrido algún cambio nuevo) o mediante Push si el servidor lo permite, mediante algunos de los sistemas Push que hemos explicado, siendo el más habitual las conexiones abiertas por largo tiempo, al estilo de IMAP IDLE.
-----------------------------------------
-----------------------------------------
Protocolos de Sincronización:
Bueno llegamos a la recta final. Por ahora hemos hablado de protocolos relacionados directamente con cada uno de los tipos de datos que deseamos, algunas veces podremos realizar sincronización y otras veces no. Pero al margen de todo ello existen protocolos de sincronización para ello, al margen de IMAP, CalDav o LDAP. A veces estos protoclos de sincronización usan por debajo estos otros protocolos y a veces usan protocolos propios. Es una forma de estandarizar lo que sería el sistema de sincronización, por ejemplo como se va a usar Push o si se va a usar Polling, que tipo de datos se van a sincronizar... etc.
Aquí aparece el mismo problema. Tenemos protocolos propietarios y protocolos estándares. Vamos a citar 4 en concreto. Volvemos a lo mismo, lo ideal sería que todos usasen protocolos estandares y asi usando el mismo protocolo todo el mundo pudiésemos tener una compatibilidad perfecta. Pero claro, a ver quien es el guapo que le dice por ejemplo ahora a Microsoft que su ActiveSync no vale, o a Apple que MobileMe es una porquería.
Lo normal es que cualquier protocolo de sincronización permita al menos la sincronización de Correo, Calendario y agenda, aunque muchos otros soportan desde notas a archivos de casi cualquier tipo. Vuelvo a repetir que no necesariamente estos protocolos usan IMAP para el correo o LDAP para las agendas. Una cosa es el sistema que usen los servidores para tener los datos o como acceder independientemente a ellos. Otra cosa es muy diferente es esta capa que permite acceso a todos esos recursos para que puedan sincronizarse correctamente con nusetros dispositivos. No se si queda clara la idea.
ActiveSync:
Es el sistema de sincronización de Microsoft. Lleva apostando por él desde hace ya muchos años. En realidad no es un sistema nada malo, permite sincroniazción de casi cualquier tipo de datos, siendo evidentemente los más usados contactos, calendario, correo y notas. Su uso es fundamentalmente en dispositivos portátiles evidentemente, y evidentemente es un protocolo propietario de Microsoft. Muchas veces se usa también el nombre de Exchange, en realidad el nombre completo del protocolo es ActiveSync Exchange. Permite evidentemente funciones de Push, sistemas similares siempre a IMAP IDLE, es decir, conexiones abiertas durente mucho tiempo.
GoogleSync:
En realidad aunque tenga nombre propio, GoogleSync usa ActiveSync, al menos una implementación muy similar a él, de forma que casi cualquier dispositivo que sea compatible con ello, puede usar GoogleSync. Es una tecnología de Google que nos permite sincronizar por ahora Calendarios y Agendas, e incluso da la opción de alertas SMS de cambios. Funcionan realmente bien, el iPhone/iPod Touch es completamente compatible y tengo que decir que una vez más google ha realizado un trabajo genial, nos da conectividad casi con todos los estándares que existen!! LDAP, 3 tipos de accesos diferentes a los calendarios (CalDav, GoogleSync y suscripciones), IMAP y POP para el correo... y ahora GoogleSync para calendario y agenda (de momento) y completamente gratuito. ¿Quien puede pedir más?
Un ejemplo de ello configurado correctamente en mi iPod Touch:
Un ejemplo de Agenda/Calendario sincronizados por GoogleSync y un calendario suscrito de ejemplo además de lo comentado.
Google te facilita los datos propios necesarios:
GoogleSync (Calendario y Agenda, soporta Push):
Protocolo: ActiveSync
Usuario: UsuarioGmail
Contraseña: ContraseñaGmail
Servidor: m.google.com
Dominio: Nada.
CalDav (Calendario, no soporta Push):
Protocolo: CalDav
Usuario: UsuarioGmail
Contraseña: ContraseñaGmail
Servidor: google.com
SyncML
En teoría es el estandar para sincronización que hay. Permite sincronizar prácticamente cualquier tipo de datos, es compatible con Push o Polling... está bastante extendido su uso. Es cierto que al ser casi el único protocolo de sincronización estandar, es normal que muchos hayan optado por esta solución. Pero no todo es bueno... tampoco ha sido muy definido este estandar, dando cabida a muchisimas implementaciones diferentes, tanto a nivel de cliente como de servidores, siendo muchas de ellas incompatibles entre ellas. Por ejemplo, SyncML usa una base de datos, pero esta base de datos no está estipulada y cada cual la implementa como quiere, con lo que un cliente SyncML no tiene porque funcionar con un servidor que usa una BD menos estandar o más rara.
En realidad poco cabe decir de este protocolo. Aunque poco a poco se abre un hueco... le cuesta trabajo dado que protoclos propietarios suelen cubrir la mayoría de las necesidades, dado que la sincronización a día de hoy no suele ser usada en demasía por el usuario medio, cno lo que no se molesta, no lo necesita. El usuario avanzado que lo necesita suele ser pro temas de trabajo, y en consecuencia suele usar simplemente lo que le dicen que tiene que usar, y suele ser un software propietario por comodidad.
MobileMe
Es un invento de Apple para luchar contra ActiveSync y otros protoclos de sincronización. Como no puede ser de otro modo, es un servicio de pago de Apple que requiere de una suscripción anual para poder usarlo. Permite sincronización de correo, calendario, agenda... y espacio en disco. Pero son muchas las razones por las que este servicio no ha llegado a muy buen término, aunque seguro que los mas aferrados a Apple lo usarán y lo defenderán. Lo gracioso es que Apple en un intento de implantarlo comenzó a distribuir en el mismo paquete de iTunes componentes para Windows para MobileMe y referencias a suscribirse y otros... aunque después de la poca verguenza de Apple en incluir en el actualizador de iTunes Safari... sin comentarios.
Primero es un servicio de pago, con lo que ya de por sí es un handicap muy importante, máxime cuando tenemos por ejemplo GoogleSync+Google IMAP IDLE que funciona perfectamenete y que es un servicio completamente gratuito.
Segundo, quien no lo sepa, MobileMe no cifra la conexión!! esto para mi es directamente impensable. Un protocolo de sincronización que no usa una conexión segura?? ¿Estamos locos? Como nota diré que todos los protocolos comentados anteriormente, TODOS, aceptan y usan SSL (encriptación/autentificacion).
Tercero, causa bastantes problemas y errores de sincronización, sujeto a cuelges de los servidores de Apple... en fin.. se han reportado muchísimos problemas por su uso.
-----------------------------------------
-----------------------------------------
Bueno, no tengo más ganas de seguir con esta entrada, creo que más o menos he dejado claro lo que quería expresar sobre sincronización, calendarios, agenda, correos... Así que no dejeis de tener buestros dipositivos móviles y de sobremesa sincronizados!! una sola agenda, un solo calendario y una sola cuenta de correo en todos los dispositivos. En serio, hace la vida muuuuuuuucho más fácil.
Un saludo amigos
Correo:
Existen dos protocolos universalmente aceptados y estándares, bien conocidos por casi todos que serían POP e IMAP. Cada uno de ellos tiene sus pros y sus contras. Aunque parezca lo contrario, POP e IMAP sería una forma de sincronización de correo. a fin de cuentas podemos enviar correos, recibirlos... desde cualquier lugar gracias a estos protocolos. Parece curioso como aun siendo sistemas de sincronización (aunque quizás podríamos decir que POP no lo es) sus usuarios no saben en realidad que estan usando dichas tecnologías. No me gustan las tablas comparativas sobre que es mejor que no es mejor, que funciones tiene uno que el otro no... cada cual que saque sus propias conclusiones.
POP:
Si bien sabemos que POP no es un sistema de sincronización dado que tan solo se dedica a descagar el correo y ya está, podríamos decir que actua más o menso como un sistema de Polling de sincronización, aunque como digo no sería puramente un sistema como tal. Dependiendo de la gran cantidad de implementaciones de POP, el servidor podrá retener o no una copia del correo que se descarga. Lo más habitual es que las cuentas POP tan solo son útiles en la gran mayoría de los casos para entornos donde tan solo se desea leer el corro desde un sitio, dado que una vez el correo es descargado desde dicho dispositivo no se podrá recuperar desde otro.
Sobre POP al igual que IMAP se dedicó una entrada extensiva sobre ello, con lo que tampoco vamos a entrar en muchos detalles. Evidentemente, como todo protocolo o sistema usado, si deseamso hacer uso de esta tecnología, deberemos tener un proveedor de correo electrónico que permita conexiones POP y un cliente que permita realizar la conexión.
Pros: Rápido, facil de implementar.
Contras: No sería conveniente para leer el correo desde dos ubicaciones diferentes, tampoco es un sistema real de sincronización, los cambios efectuados tan solo se reflejan en local, no el servidor de correos mismo. En teoría no acepta tampoco carpetas de trabajo, dado que tan solo es un "descargador de correos". Al realizar accesos por Polling, hasta que no se realiza una petición, no sabremos si tenemos un correo nuevo
Consumo: Dado que es un método de Polling, significa que el consumo de ancho de banda o energético, será proporcional simplemente al número de veces que se realicen comprobaciones al servidor. No es un sistema optimizado, muchas de las peticiones devolverán cero correos, con lo que el ancho de banda y el consumo energético por ello será en vano.
Pese los pros/contras y consuno, no obstante para el usuario medio puede ser incluso más eficiente y mejor, dado que a lo mejor este usuario tan solo desea leer el correo una vez al día, siempre desde el mismo lugar, y por seguro que algún correo tendrá. Con lo que será consultar, descargar y se acabó, el consumo en este caso sería poco y los contras de POP no le implicarían nada. Se tendría acceso a los correos en el momento en el que se realizase la petición, si no hay petición no sabremos si hay correo.
IMAP:
IMAP es bastante más sofisticado. En este caso si podríamos hablar de una sincronización propiamente dicha, ya que cualquier dispositivo podrá acceder incluso a la vez a su servidor para recuperar cualquier correo. Cualquier cambio incluso q se realice de forma local se verá afectado en su servidor, con lo que podemos decir q la información se encuentra sincronizada en todo momento. Un mensaje leído desde IMAP permanecerá leído para todos los dispositivos, un mensaje eliminado estará eliminado en todos. Este sistema evidentemente será conveniente según las necesidades de cada uno. Si tan solo deseamos gestionar el correo en un PC y de manera rápida, simple, sin complicaciones y otros, a alguno podría interesarle usar POP en lugar de IMAP. Y al igual que POP, tendrá que ser un protocolo soportado por nuestro proveedor de correos y nuestro cliente.
Es importante destacar que tanto IMAP como POP realizan las peticiones al servidor de correo mediante Polling.
Pros: Sincroniza los correos, permite trabajar en local y sincronizar cuando esté online por ejemplo. Es una interfaz directa a nuestro servidor de correo. Permite la descarga selectiva de cabeceras o correos enteros, trabajar con carpetas y al estar sincronizadas, cualquier ubicación trabajará exactamente igual. Permite por tanto el acceso simultaneo a la cuenta, etc etc... Puede permitir tambien realizar búsquedas de correo sobre el servidor.
Contras: Es un sistema muchísimo más complejo que POP (POP es un sistema muy simple), y dado que todo se realiza de forma sincronizada, suele ser más lento, por ejemplo si guardamos una plantilla, la plantilla lo normal es que se guarda en el servidor, con el tiempo necesario para enviar dichos datos al servidor. Dado que es un sistema más complejo, normalmente los proveedores de correo no todos implementan IMAP. Al realizar accesos por Polling, hasta que no se realiza una petición, no sabremos si tenemos un correo nuevo
Consumo: En cuanto a consumo de ancho de banda suele consumir más que POP. Esto es pq cliente y servidor intercambian mayor información que simplemente los correos. Por otro lado tb el cliente suele enviar datos al servidor como por ejemplo que un mensaje ha sido eliminado, leído o guardado un borrador. Todo ello es ancho de banda, que implica proporcionalmente un incremente en cualquier consumo energético.
Este caso sería ideal para cualquier usuario con accesos desde diferentes lugares a sus cuentas, sacrificas algo de ancho de banda y mayor consumo para poder tener una sincronización real que de otro modo no tendrías. De nueco recordamos que una tecnología no es mejor o peor por sus recursos, sino para lo que se requiera si cumple con los objetivos.
IMAP IDLE:
Está aceptado como estandar. Es una extensión a IMAP que permite realizar un sistema de Push en vez de Polling. Consiste como hemos dicho anteriormente, en enviar una petición de espera latente, en la que nuestro cliente se mantendrá conectado por un tiempo "muy largo" a nuestro servidor. Cuando a nuestro servidor llega un correo entrante, este nos lo notifica por la conexión que está a la espera, con lo que la notificación debería de ser inmediata. Por lo demás su funcionamiento es igual a IMAP.
Su eficiencia no obstante depende normalmente de la implementación de cada servidor y sobre todo cada cliente. Posíblemente el parámetro más importante sería desde mi punto de vista cada cuanto tiempo máximo se debe de enviar una señal de KeepAlive. Como ya vimos en la primera parte de este manual, no podemos dejar eternamente una conexión establecida por diversos factores. Los dos más inmediatos son el TimeOut por parte del servidor y el TimeOut por parte de nuestro routers en caso de estar detrás de uno.
Esto que significa?. El TimeOut por parte del servidor es un tiempo establecido en ellos por el cual si no se detecta actividad de dicha conexión en ese tiempo, la conexión se cierra. Lo mismo sucede con el TimeOut de cualquier router que use NAT, la conexión se desecha de pasar un cierto tiempo. Esto quiere decir que el cliente que quiere mantenerse en modo idle debe de encargarse en mantener la conexión abierta. El como y cada cuanto tiempo, depende tan solo del cliente.
En teoría la norma es que antes de que sucedan los 30 minutos desde avisar del estado idle, se debe de dar por terminado el estado idle y rehacer la petición odle para otros 30 minutos. Esto es al margen de los correos, luego explico como funciona el sistema. Esto quiere decir que cada 30 minutos máximos nuestro cliente debería de hacer uso de nuevo del ancho de banda para realizar dichas peticiones. Lo normal llegado a este punto es usar comandos IMAP NOOP que significa "no hacer nada". Básicamente es como hacer un ACK o un pin al servidor destino para que este refresque la conexión, usando muy pocos bytes de información para ello. En teoría forzando muchos los tiempos se podría usar comandos NOOP cada 29 minutos. Cada 29 minutos existiría un consumo mínimo de ancho de banda y en consecuencia de transmisión de datos = consumo energético. El problema es que estos 29 minutos serían tan solo el salvaguarda de cara al servidor, no de cara a nusetro router. ¿Y como saber el TimeOut de este? Pues a menos que el router disponga de un sistema para saberlo, ya sea por web o telnet... tocará probar. Lo normal es que los router desechen conexiones pasados los 10-20 minutos. Mi Router por ejemplo se puede establecer el TimeOut, y ahora mismo lo tengo establecido en 60 minutos, con lo que en mi caso no sería problema.
Para terminar decir que los clientes IMAP IDLE suelen estar configurados de manera genérica para realizar NOOP cada 15 minutos aproximadamente. Ni que decir tiene que si la conexion se finaliza por tiempo de espera o por cualquier otra causa, estaríamos en el peor de los casos, y la conexion se debería de reestablecer de nuevo.
Os dejo unas capturas de pantalla de una sesión IMAP IDLE a la vieja usanza. La primera hace referencia exactamente a que sucede si no se ejecutan comandos tipo NOOP (u otros sistemas) para mantener la conexión abierta:
El primer paquete de la lista es la petición de idle. El servidor contesta con un ack y acto seguido responde con que se ha "activado" el modo idle y mi pc contesta con el ack correspondiente. Si os fijais en los tiempos, la conexión se queda ahí. Pasados 30 minutos el servidor al no detectar ninguna actividad en la conexión, inicia el handshake de fin de conexión.
¿Pero que sucede de cara a la sesión?
Los puntos rojos corresponden a lo que sería el cliente. El resto son las respuestas del servidor. Todo lo que precede al comando "IDLE", es simplemente la autentificación y pido solicitud de la bandeja de entrada, que dice que tengo 0 mensajes nuevos. Despues ejecuto "idle". 6 minutos después me envio un correo desde otra cuenta y que sucede? que segundos después aparece en pantalla la respuesta por parte del servidor a mi cliente avisando de que el correo número 10187 acaba de llegar. Minutos más tarde me vuelvo a enviar un correo, y de nuevo el aviso es recibido correctamente. Para acabar la sesión tecleo "done" para dar por finalizada la sesión idle y listo.
En este caso google soporta perfectamente IDLE. Para comprobar esto de todos modos tan solo sería necesario con teclear en la sesion IMAP anterior el comando ". capability". Se puede apreciar como todos mis comandos están antecedidos por un punto. En realidad puede ser cualquier cosa, es una etiqueta. Se usa debido a que se permiten sesiones múltiples por IMAP, y de esta forma se identifica mi sesión actual. Si el servidor me responde con un "." será un mensaje de respuesta a mi sesión específica, si responde con * son respuestas de modo global.
Un buen cliente compatible con IMAP IDLE debería por tanto mantenerse a la espera el máximo tiempo posible antes de enviar un ack/ping/NOOP...
La pregunta inmediata: ¿Es compatible la aplicación de nusetro dispositivo con IMAP IDLE? Por desgracia a Apple también se le olvidó implementar dicha extensión. Es posible que por el incremento en consumo, pero tampoco tendría esto mucho sentido dado que si permite realizar Polling incluso cada minuto!!, que seguro que el consumo sería muy muy superior. He visto comentarios de quienes afirman que si soporta IMAP IDLE, pero creerme, no lo hace.
Pros: Los correos llegan exactamente al momento, sin necesidad de requerir la petición al servidor. Esto puede evitar en caso de ser algo crítico, el uso intensivo del ancho de banda requerido que se necesitaría para realizar Polling cada 10 segundos a lo mejor.
Contras: Evidentemente aunque tenga un consumo bajo de ancho de banda, algo siempre existe, aunque se intenta minimizar lo máximo posible. No está considerado como un sistema Push puro, para ello se necesitaría acudir a sistemas de notificación SMS o similar.
Consumo: Inferior o superior a IMAP dependiendo de cada cuanto tiempo se tenga establecido el Polling. Si la idea es comprobar el correo cada 24 horas, IMAP IDLE es un consumo excesivo. Si deseamos ser notificados al instante de correo nuevo por el contrario, IMAP IDLE es la solución, ya que con IMAP tendríamos que realizar un Polling cada muy poco tiempo y ello llevaría a un enorme consumo.
P-IMAP
P-IMAP es una solución no estandarizada para realizar Push por IMAP. En realidad es un sistema similar a IMAP IDLE, aunque mas que similar deberíamos decir que IMAP IDLE forma parte añadida de P-IMAP. Pero por otro lado P-IMAP ofrece la posibilidad de que la notificación se realice por SMS o más automatizado por vía de WAP Push. Pero en esencia es lo mismo. Posiblemente no se llegue a estandarizar nunca dado las grandes diferencias entre compañias, el tipo de SMS, el tipo de WAP Push... depende de tecnologías que estas depende a su vez de las compañías. Aunque existe el planteamiento por algunos de que sea un estandar, dudo mucho que se convierta como tal, existiendo como ya existen IMAP IDLE. Es posible no obstante que en un futuro veamos IMAP4 actualizado para dar soporte a alguna tecnología estandarizada para tal efecto.
Al ser por tanto un sistema no estandar, su utilización por parte de servidores y clientes se ve reducido enórmemente, siendo ahora mismo usado básicamente por algunos programas y servidores, mientras que IMAP IDLE gana adeptos y cada vez más servidores lo permiten. Con lo que tampoco me gustaría darle más importancia a ello
Pros: Verdadero Push por medio de SMS o WAP Push.
Contras: En realidad las diferencias entre IMAP IDLE puede no ser justificable para la infrastructura requerida. Tener en cuenta que los servicios de notificación SMS o Push SMS suele ser un coste adicional por parte de nuestro operador, ISP o proveedor, con lo que para el usuario medio no sería una opción viable.
Consumo: Si se usa un sistema vía SMS por ejemplo, tan solo existe un consumo cuando se solicita la recepción del correo. En este caso nuestro dispositivo sabrá a ciencia exacta cuando ha llegado un correo y que puede descargarlo, iniciando una conexión desde cero nueva, sin neecsidad de mantener la conexión activa.
Existen sistemas de sincronización globales, pero esos los trataremos al final como protocolos de sincroniazción. Es cierto que IMAP pueda ser un protocolo de sincronización, pero me refiero a sistemas globales como pueda serlo GoogleSync, SyncML, ActiveSync, MobileMe...
-----------------------------------------
-----------------------------------------
Agenda y Calendarios:
Ahora nos toca abordar la agenda y los calendarios. Normalmente un recurso mucho más usado que el mismo correo electrónico, ya sea para buscar números de teléfonos, para buscar direcciones, notas... apuntar citas, cumpleaños, reuniones... hoy en día es casi imprescindible una buena agenda/calendario actualizadas. Y de eso vamos a tratar fundamentalmente, actualizada.
Al contrario que los correos, la agenda y el calendario tienen un problema añadido que no suponía para el correo, y este problema provoca la mayoría de los dolores de cabeza. Las incompatibilidades.
Está claro que un correo es un correo, un estandar definido perfectamente, ya sea un correo encriptado, un correo HTML, un correo en texto plano, los destinatarios que sean (ocultos, copias..). Está todo perfectamente definido, e incluso se puede expandir gracias a etiquetas concretas para ello. Pero para los calendarios y agendas electrónicas esto no es así. Sí, claro que existen estándares, pero luego cada cual hace un poco lo que quiere. Así por ejemplo en las agendas podemos ver algunas que puedes introducir todos los números de telefonos que desees, en cambio otros solo uno de casa y otro de trabajo, otros a lo mejor puedes configurar 3, pero no especificar de que tipo son... así con casi cualquier campo que podamos encontrar en uan agenda: Dirección, telefonos, correos, foto, notas, cumpleaños, empresa, nombre... algunas agendas tan solo computan un nombre en el que incluyen el apellido, otros tienen campos específicos para un solo apellido donde van los dos, otras dos apellidos... bueno creo que todos nos hacemos ya una idea de lo que implica esto. En caso de los calendarios es lo mismo, aunque tienen además el agrabante de los usos horarios, interpretar las mismas fechas... un caos.
Si esto es así, como diablos vamos a ser capaces de encajar (usando ya el protocolo que sea) una agenda que tiene mil campos en una agenda que tan solo contempla 10. Gracias a dios cada vez está todo más estandarizado y más o menos se tiende a una norma. Pero aun hoy por hoy existe cierta variedad de formatos diferentes, implementaciones de cada uno... aquí es cuando se agradece a aquellos que intentan en la medida de lo posible estandarizar las cosas.
Por ejemplo desde mi punto de vista, podemos tener a un lado SonyEriccson. Desde que han ido existiendo los estándares se han ido ciñedo a ellos: Agendas, calendarios, Bluetooth, notas, correo... Ventajas? es evidente, una mayor interoperatibidad. Al otro lado por ejemplo podemos ver Nokia. Una compañía que desde siempre ha intentado hacer las cosas a su modo (Como Apple). Hasta hace muy poco (algunos aun seguro que lo recordaran) si tenías Nokia, para poder pasar por BT un archivo ambos tenian que ser nokia, o el formato propietario para agenda/calendario, o para las notas usan simples arcihvos de texto... esto implica a la larga problemas. Tiene su lógica. Algunos desarrolladores (empresas) consideran que para el usuario final prima la versatilidad, la interoperabilidad... para otros prima el sello, el dar por culo y la exclusividad. ¿Que sucede con el tiempo? Que los estándares se afianzan, y las compañías que llevan años y años apollándolos sacan ventajas en implementaciones, velocidad, ideas... Así sucede por ejemplo q es tremendamente simple manejar un teléfono de SonyEriccson mediante comandos AT, o tener la seguridad casi del 100% que no vas a tener un solo problema de compatibilidad con nada.
Si volvemos a Apple, el problema es aun mayor. Apple en sus iPhone e iPod Touch usa formatos propios incluso en el sistema de guardado en disco. Esto puede hacer para muchos un infierno. No os podeis imaginar la de personas que me han preguntado como pueden exportar su agenda en sus teléfonos y meterla en un iPod o un iPhone y al revés. Gracias Apple por complicarnos la vida. ¿Que es lo que sucede al final? Que lo que podría ser algo muy simple si nativamente usa un estandar, a la hora de usar protocolos de sincronización estándares tienes que montar un jaleo increible para convertir los datos, adaptarlos... etc. Y muchos preguntarán... claro, pero al menos usan protocolos estándares, eso es bueno. Sí, es bueno, pero es que ha sido por obligación más que nada. Apple ya usaba (y usa, y lo veremos más adelante) como protocolos propietario de sincronización MobileMe. ¿Que sucede? Que además de ser de pago, no lo usa ni el tato, de ahí ahora a añadir la funcion de localización remota y demás... hay que intentar lo que sea. Si Apple no hubiese implementado protocolos como los que veremos ahora, el volumen de ventas para empresarios sería casi nulo, que ya de por si es muy bajo en comparación con BlackBerry.
Bueno, dejando todo ello a un lado... En el caso de la agenda y el calendario es diferente al del correo, puesto que para tener una agenda o un calendario no hace falta una conexión a inet la mayoría de las veces, no tienes que enviar nada, con lo que la sincronización o la conexión es completamente opcional.
Por eso mismo sería absurdo intentar listar cada uno de los formatos existentes, pues aunque existen algunos estándares como puedan serlo ldif, vcard, vcal... luego cada programador hace la implementación que le da la gana.
Directorios LDAP:
LDAP en realidad no se constituyó como agendas de teléfono o contactos. LDAP es un protocolo de acceso, sincronización y modificación a un directorio... una base de datos. En cierto modo son bases de datos estructuradas con un formato propio, con un acceso propio y otros, pero se puede asemejar a ello. Su uso es bastante abitual, por ejemplo en los servidores de DNS. Por como funcionan estos es muy común usar LDAP para las DNS. Pero al caso que nos atañe a nosotros, es para su uso como agenda.
Pero claro... ¿cual es entonces la idea de LDAP como agenda? Lo normal es usar una agenda siempre en local, pero pensar en una empresa. Una empresa con 1000 trabajodes por ejemplo, cada uno con su nombre apellidos y pongamos por ejemplo el correo electrónico de ellas. Sería tremendamente útil de cara a todos los trabajadores que todos los trabajadores tuviesen acceso a un directorio LDAP con dicha información, además a lo mejor de otro privado. De un solo golpe todos los trabajadores serían capaces de tener acceso a todos los correos de todos los compañeros.
Otro uso normal sería el que andamos explicando. La sincronización. Tener en algún servidor centralizado nuestra agenda LDIF (formato usado normalmente para LDAP), de modo que desde cualquier ubicación pudiésemos no solo tener acceso a ella, sino también modificarla.
Las posibilidades son muchísimas.
CalDav
Por un lado podríamos decir que es el homólogo a LDAP para calendarios, pero en realidad decir esto sería incorrecto. CalDav no es en sí una forma de almacenar datos, no es una base de datos, no es un sistema de directorios... es básicamente un protocolo de sincronización para calendarios usando el formato de calendarios iCalendar, y al margen de lo que pueda pensar ya la mayoría por la 'i' delante, no, no se trata de un formato desarrollado por Apple ni muchísimo menos, es un estandar en cuanto a calendarios se refiere, y CalDav es el protocolo de sincronización para ello. Esto nos permite por lo tanto poder acceder al igual que hacemos por LDAP a nuestra agenda, a nuestro calendario, estemos donde estemos, y teniendo la certeza que modifiquemos lo que modifiquemos los cambios serán propagados por todos nuestros dispositivos en el momento que estos se vayan conectando.
Ambos sistemas que estamos explicando, pueden ser a su vez ser accedios mediante Polling o mediante Push. Recordar que el protocolo de sincronización es el que realiza la comparación de los datos por así decirlo, pero por encima de ello hay alguien que inicia la transmisión de los datos, que se conecta, que... y al igual que el correo, dado que son accesos directos a los servidores, esto se puede hacer manualmente mediante Polling (Preguntando al servidor si ha ocurrido algún cambio nuevo) o mediante Push si el servidor lo permite, mediante algunos de los sistemas Push que hemos explicado, siendo el más habitual las conexiones abiertas por largo tiempo, al estilo de IMAP IDLE.
-----------------------------------------
-----------------------------------------
Protocolos de Sincronización:
Bueno llegamos a la recta final. Por ahora hemos hablado de protocolos relacionados directamente con cada uno de los tipos de datos que deseamos, algunas veces podremos realizar sincronización y otras veces no. Pero al margen de todo ello existen protocolos de sincronización para ello, al margen de IMAP, CalDav o LDAP. A veces estos protoclos de sincronización usan por debajo estos otros protocolos y a veces usan protocolos propios. Es una forma de estandarizar lo que sería el sistema de sincronización, por ejemplo como se va a usar Push o si se va a usar Polling, que tipo de datos se van a sincronizar... etc.
Aquí aparece el mismo problema. Tenemos protocolos propietarios y protocolos estándares. Vamos a citar 4 en concreto. Volvemos a lo mismo, lo ideal sería que todos usasen protocolos estandares y asi usando el mismo protocolo todo el mundo pudiésemos tener una compatibilidad perfecta. Pero claro, a ver quien es el guapo que le dice por ejemplo ahora a Microsoft que su ActiveSync no vale, o a Apple que MobileMe es una porquería.
Lo normal es que cualquier protocolo de sincronización permita al menos la sincronización de Correo, Calendario y agenda, aunque muchos otros soportan desde notas a archivos de casi cualquier tipo. Vuelvo a repetir que no necesariamente estos protocolos usan IMAP para el correo o LDAP para las agendas. Una cosa es el sistema que usen los servidores para tener los datos o como acceder independientemente a ellos. Otra cosa es muy diferente es esta capa que permite acceso a todos esos recursos para que puedan sincronizarse correctamente con nusetros dispositivos. No se si queda clara la idea.
ActiveSync:
Es el sistema de sincronización de Microsoft. Lleva apostando por él desde hace ya muchos años. En realidad no es un sistema nada malo, permite sincroniazción de casi cualquier tipo de datos, siendo evidentemente los más usados contactos, calendario, correo y notas. Su uso es fundamentalmente en dispositivos portátiles evidentemente, y evidentemente es un protocolo propietario de Microsoft. Muchas veces se usa también el nombre de Exchange, en realidad el nombre completo del protocolo es ActiveSync Exchange. Permite evidentemente funciones de Push, sistemas similares siempre a IMAP IDLE, es decir, conexiones abiertas durente mucho tiempo.
GoogleSync:
En realidad aunque tenga nombre propio, GoogleSync usa ActiveSync, al menos una implementación muy similar a él, de forma que casi cualquier dispositivo que sea compatible con ello, puede usar GoogleSync. Es una tecnología de Google que nos permite sincronizar por ahora Calendarios y Agendas, e incluso da la opción de alertas SMS de cambios. Funcionan realmente bien, el iPhone/iPod Touch es completamente compatible y tengo que decir que una vez más google ha realizado un trabajo genial, nos da conectividad casi con todos los estándares que existen!! LDAP, 3 tipos de accesos diferentes a los calendarios (CalDav, GoogleSync y suscripciones), IMAP y POP para el correo... y ahora GoogleSync para calendario y agenda (de momento) y completamente gratuito. ¿Quien puede pedir más?
Un ejemplo de ello configurado correctamente en mi iPod Touch:
Un ejemplo de Agenda/Calendario sincronizados por GoogleSync y un calendario suscrito de ejemplo además de lo comentado.
Google te facilita los datos propios necesarios:
GoogleSync (Calendario y Agenda, soporta Push):
Protocolo: ActiveSync
Usuario: UsuarioGmail
Contraseña: ContraseñaGmail
Servidor: m.google.com
Dominio: Nada.
CalDav (Calendario, no soporta Push):
Protocolo: CalDav
Usuario: UsuarioGmail
Contraseña: ContraseñaGmail
Servidor: google.com
SyncML
En teoría es el estandar para sincronización que hay. Permite sincronizar prácticamente cualquier tipo de datos, es compatible con Push o Polling... está bastante extendido su uso. Es cierto que al ser casi el único protocolo de sincronización estandar, es normal que muchos hayan optado por esta solución. Pero no todo es bueno... tampoco ha sido muy definido este estandar, dando cabida a muchisimas implementaciones diferentes, tanto a nivel de cliente como de servidores, siendo muchas de ellas incompatibles entre ellas. Por ejemplo, SyncML usa una base de datos, pero esta base de datos no está estipulada y cada cual la implementa como quiere, con lo que un cliente SyncML no tiene porque funcionar con un servidor que usa una BD menos estandar o más rara.
En realidad poco cabe decir de este protocolo. Aunque poco a poco se abre un hueco... le cuesta trabajo dado que protoclos propietarios suelen cubrir la mayoría de las necesidades, dado que la sincronización a día de hoy no suele ser usada en demasía por el usuario medio, cno lo que no se molesta, no lo necesita. El usuario avanzado que lo necesita suele ser pro temas de trabajo, y en consecuencia suele usar simplemente lo que le dicen que tiene que usar, y suele ser un software propietario por comodidad.
MobileMe
Es un invento de Apple para luchar contra ActiveSync y otros protoclos de sincronización. Como no puede ser de otro modo, es un servicio de pago de Apple que requiere de una suscripción anual para poder usarlo. Permite sincronización de correo, calendario, agenda... y espacio en disco. Pero son muchas las razones por las que este servicio no ha llegado a muy buen término, aunque seguro que los mas aferrados a Apple lo usarán y lo defenderán. Lo gracioso es que Apple en un intento de implantarlo comenzó a distribuir en el mismo paquete de iTunes componentes para Windows para MobileMe y referencias a suscribirse y otros... aunque después de la poca verguenza de Apple en incluir en el actualizador de iTunes Safari... sin comentarios.
Primero es un servicio de pago, con lo que ya de por sí es un handicap muy importante, máxime cuando tenemos por ejemplo GoogleSync+Google IMAP IDLE que funciona perfectamenete y que es un servicio completamente gratuito.
Segundo, quien no lo sepa, MobileMe no cifra la conexión!! esto para mi es directamente impensable. Un protocolo de sincronización que no usa una conexión segura?? ¿Estamos locos? Como nota diré que todos los protocolos comentados anteriormente, TODOS, aceptan y usan SSL (encriptación/autentificacion).
Tercero, causa bastantes problemas y errores de sincronización, sujeto a cuelges de los servidores de Apple... en fin.. se han reportado muchísimos problemas por su uso.
-----------------------------------------
-----------------------------------------
Bueno, no tengo más ganas de seguir con esta entrada, creo que más o menos he dejado claro lo que quería expresar sobre sincronización, calendarios, agenda, correos... Así que no dejeis de tener buestros dipositivos móviles y de sobremesa sincronizados!! una sola agenda, un solo calendario y una sola cuenta de correo en todos los dispositivos. En serio, hace la vida muuuuuuuucho más fácil.
Un saludo amigos
miércoles, 1 de julio de 2009
Firmware 3.1: Beta, hasta los ******* de tanta Firmware
Ya estaba tardando en aparecer la versión de verdad. No tiene mucho sentido, pero a Apple le suele pasar lo mismo siempre. Siempre que aparece un gran lanzamiento, no pasa ni una semana en aparecer una versión actualizada para corregir los fallos de la anterior. Vamos a ver señores. Cuantas firmwares teneis pensado sacar? Con la versión 3.1 ya son si no he contado mal 13!! Si tenemos en cuenta que quitando la 2.0 y la 3.0 las demás han sido básicamente para corregir fallos...
¿Tanto trabajo cuesta sacar un software en condiciones? Vamos a ver, que todo lo que sea mejorar está bien, pero es que parece que nos toman el pelo. Ahora en la 3.1 que si añaden una opción a safari para pishing creo que es. Vamos a ver si me parece bien, pero vaya, ponla en la 3.0. Y así con todo. ¿Que pasa? Que claro, que es que si no no cumplen los tiempos, es que sino hay más retrasos... La firmware 3.0 de echo no deja de ser básicamente lo que se le pidió a Apple desde la 1.0 que integrara!! Bueno no, aun no hay Flash...
Que las mejoras son buenas, que las nuevas funciones son buenas, que el software necesita tiempo para crearse y más aun para probarse... pero no he conocido jamás nada que necesite de tantas actualizaciones tan frecuentemente para que funcione bien. Pero si hasta mi equipo se actualiza menos frecuentemente...
Pues nada, otra versión más, la número 13, para añadir la protección de Pishing y arreglar los fallos que han cometido en la 3.0 de velocidad, rendimiento y consumo de batería. Y eso sin pensar en lo que añadirán aun en la versión 4.0, que creerme, llegará algun día para implementar:
Bluetooth de verdad
Flash
VPN IPSec no solo para Cisco
IMAP IDLE
SyncML
Pestañas para Safari
...
En fin... esto es el cuento de nunca acabar. A lo mejor en la versión 6.0 anuncian por todo lo alto que puedes enviar un archivo por BT y que es lo último de lo último.
Antes de que nadie responda... Que son 13 ya por dios...
¿Tanto trabajo cuesta sacar un software en condiciones? Vamos a ver, que todo lo que sea mejorar está bien, pero es que parece que nos toman el pelo. Ahora en la 3.1 que si añaden una opción a safari para pishing creo que es. Vamos a ver si me parece bien, pero vaya, ponla en la 3.0. Y así con todo. ¿Que pasa? Que claro, que es que si no no cumplen los tiempos, es que sino hay más retrasos... La firmware 3.0 de echo no deja de ser básicamente lo que se le pidió a Apple desde la 1.0 que integrara!! Bueno no, aun no hay Flash...
Que las mejoras son buenas, que las nuevas funciones son buenas, que el software necesita tiempo para crearse y más aun para probarse... pero no he conocido jamás nada que necesite de tantas actualizaciones tan frecuentemente para que funcione bien. Pero si hasta mi equipo se actualiza menos frecuentemente...
Pues nada, otra versión más, la número 13, para añadir la protección de Pishing y arreglar los fallos que han cometido en la 3.0 de velocidad, rendimiento y consumo de batería. Y eso sin pensar en lo que añadirán aun en la versión 4.0, que creerme, llegará algun día para implementar:
Bluetooth de verdad
Flash
VPN IPSec no solo para Cisco
IMAP IDLE
SyncML
Pestañas para Safari
...
En fin... esto es el cuento de nunca acabar. A lo mejor en la versión 6.0 anuncian por todo lo alto que puedes enviar un archivo por BT y que es lo último de lo último.
Antes de que nadie responda... Que son 13 ya por dios...
Suscribirse a:
Entradas (Atom)
Entradas
