Cuando se ejecuta un cliente Jabber, ¿qué sucede (o qué debería suceder) al cambiar de red (o cuando se pierde la conectividad y el módem GSM/UMTS se vuelve a conectar)?
¿Puede un cliente móvil de Android Jabber (por ejemplo, Jabiru ) ser inteligente en tales situaciones?
En el peor de los casos que puedo imaginar: al cliente no le importa, se pierde la conexión TCP (sobre TLS) con el servidor de Jabber, el estado de Jabber (que se muestra de forma remota) es falso y hay una ventana de tiempo en la que se pierden los mensajes (de los amigos).
Observé el peor de los casos, por ejemplo, con un cliente Jabber de stock en una computadora portátil que usaba una conexión UMTS poco confiable.
Cuando uso una computadora portátil, puedo proteger fácilmente mi sesión de Jabber de esta manera:
autosshde un sistema con una conexión de red estable y ejecutar directamentescreen -RdscreenPor lo tanto, cuando se pierde la conexión a Internet móvil, la conexión al servidor Jabber sigue funcionando bien. Y autosshse vuelve a conectar automáticamente y se vuelve a adjuntar a la sesión de pantalla en ejecución cuando se activa una nueva conexión móvil.
¿Es necesaria una configuración similar a esta cuando se usa Jabber en un dispositivo Android?
¿O existen extensiones del protocolo Jabber para clientes móviles que realmente ayudan a evitar la pérdida de mensajes, etc. en una situación de encendido/apagado de la red (mientras se está conectado a un servidor Jabber)?
No estoy seguro si esta pregunta está relacionada con el tema de los entusiastas de Android. Pero trabajo con XMPP y Android, así que aquí está mi respuesta:
Como ya dijo Lie Ryan , una transferencia de una celda móvil a otra casi siempre es transparente para la pila TCP en los dispositivos Android. Pero hay situaciones en las que cambiará la IP de su dispositivo Android. Suelen ser conmutadores GSM/UMTS <-> WiFi, lo que hará que el cliente XMPP no pueda utilizar la conexión TCP.
En Android, la biblioteca XMPP estándar que usan la mayoría de los clientes, además de tener la suya propia, es (a)Smack : los clientes que usan (a)Smack con la configuración predeterminada no notarán un cambio de conexión de manera oportuna. Pero hay esperanza: la compatibilidad con XMPP Ping está en Smack Trunk y se enviará con la versión 3.3. La mayoría de las aplicaciones de aSmack ya utilizan una versión de aSmack compatible y solo necesitan implementar las medidas correspondientes.
Por otro lado, es el trabajo de los servidores XMPP configurar su presencia como no disponible (fuera de línea) después de un tiempo de espera (definido por el servidor) para llegar al último cliente del JID en cuestión.
Por lo tanto, no es necesario crear soluciones alternativas si está utilizando un cliente XMPP adecuado, pero es posible que tenga que vivir con situaciones de estado fantasma que deberían resolverse después de unos minutos.
Hay un buen XEP (XMPP Extension) que sería la panacea para las conexiones XMPP móviles: XEP-0198 - Stream Management . Puedes leer sobre esto en el Blog de Ge0rg .
Se está trabajando para (a)Smack . Pero llevará un tiempo hasta que sea estable y también necesitará soporte de servidor para XEP-0198.
No soy un experto en redes móviles, pero AFAIK, la pila TCP debería manejar la transferencia móvil de manera transparente, los programas de aplicación no deberían tener que saber que la capa de red móvil está cambiando de torre celular a torre celular. Desde la perspectiva del programa de aplicación, solo hay una conexión continua.
La única razón por la que puedo pensar en lo que está viendo en el cliente Jabber de la computadora portátil es que no usó keepalive al abrir una conexión TCP de ejecución prolongada. Cuando hay un largo período sin transmisión, uno de los nodos intermediarios en la red (generalmente el firewall) puede decidir terminar la conexión (generalmente para ahorrar recursos para atender otras conexiones activas) y, por lo tanto, el servidor no tuvo la oportunidad. para decirle al cliente que termine limpiamente. No usar keepalive para una conexión de larga duración hará que sea imposible que el cliente detecte que la conexión se ha interrumpido porque la única forma en que un cliente puede detectar una conexión interrumpida es si intentó enviar un paquete y falló permanentemente.
Keepalive hará que la pila TCP haga ping periódicamente al servidor con paquetes ACK de longitud cero, por lo tanto, los nodos intermediarios considerarán que su conexión de larga duración aún está activa y no la terminarán.