2012-05-31 7 views
10

Experimento un comportamiento bastante extraño con smack para crear un pequeño cliente/bot XMPP. Configuré la conexión, así como ConnectionListener y ChatManagerListener. Esto funciona bastante bien y luego puedo chatear con mi aplicación que se ejecuta en un dispositivo portátil.Smack Client: el usuario aún está "en línea" aunque se ha cancelado la conexión

Para probar el comportamiento en la conexión perdida he enchufado el cable de ethernet del dispositivo portátil. Esperaba que el cliente XMPP perdiera la conexión y que el usuario se establecerá 'fuera de línea' en la lista de amigos de los usuarios. Lo que ocurre es que este usuario todavía se muestra como "en línea" y ConnectionListener de mi cliente no activa nada, ya sea connectionClosed o reconnectionFailed o de lo contrario.

Cuando vuelva a enchufar el cable de ethernet, a veces es como si la conexión hubiera estado activa todo el tiempo. Los mensajes fuera de línea se manejan y puedo volver a chatear como antes. Otras veces mi cliente es totalmente inaccesible y está fuera de servicio, parece que todos los oyentes se han ido ... Pero no se escuchan exclamaciones.

Ese es un comportamiento bastante extraño e incontrolable que haría inutilizable todo el cliente para mí, ya que no puedo estar seguro de que el cliente volverá a aparecer después de que se haya iniciado la conexión.

¿Alguien más ha experimentado tales problemas o tiene alguna pista de lo que (no) está sucediendo?

Si es necesario, puedo proporcionar mi código, pero en realidad solo copie & pegue de la documentación de Smack.

Respuesta

8

En este momento está describiendo dos efectos diferentes aquí. Vamos a empezar con el que está nombrado en el título de tu pregunta: El usuario se asume en línea por el servidor incluso si la conexión es abrupta, y por lo tanto impuro, abortada. La razón es simplemente que el servidor aún no ha notado la desconexión del cliente, ya que no hubo una terminación limpia de la secuencia de stanza XMPP. La mayoría de los servidores XMPP comprueban a los clientes con un ping cada X minutos. Si un cliente no responde, se supone que está desconectado y se muestra fuera de línea (si fue el último recurso conectado para ese JID). Eso no ha sucedido aquí y no es raro. Porque a veces quieres tener tiempos de espera prolongados (media hora o más).

Lo mismo ocurre con el otro lado. Smack también envía XMPP pings cada X minutos si se usa PingManager o PingManagerWithAlarmManager (para Android). Si hay algún problema con el socket usado, se lanza una excepción.

Espero que pueda orientarlo en la dirección correcta. Debe resolver por sí mismo por qué la conexión no finaliza con una excepción en su caso.

Una última cosa: una conexión TCP puede sobrevivir fácilmente incluso si el cable Ethernet está enchufado y vuelve a conectarse. Hay muchos tiempos de espera en varias capas del modelo OSI: NAT, TCP, XMPP, etc.

+0

Gracias por las aclaraciones, podrían ayudarme. Tal vez sea más paciente y espere más de 1-2 minutos antes de volver a enchufar el cable. De todos modos, el problema de los oyentes a veces se mantiene sintonizado y, a veces no es todavía un misterio. Pero creo que voy a abrir otra pregunta para eso. – signpainter

+2

Me gustaría agregar que este comportamiento de TCP no es un error, sino una gran característica que pocas personas parecen apreciar.No necesitar volver a conectarse y realizar la configuración de flujo de XMPP bastante costosa le ahorra muchos viajes de ida y vuelta. Lo que probablemente desee es que el sistema operativo le informe acerca de la pérdida y la reanudación de la conectividad para que luego pueda verificar si la conexión sobrevivió. Si lo hizo, corre como si nada hubiera sucedido, de lo contrario vuelve a conectar. La reconexión XEP-0198 también es increíble. – Zash

0

podrá hacer uso también de manera explícita el método disconnect() a finalizar su conexión, de lo contrario el servidor tendrá que hacer ping periódicamente y se dan cuenta que han pasado sin conexión

Cuestiones relacionadas