Sobre las prioridades de jabber

Contenido archivado

El contenido de la web se encuentra archivado y no se podrá crear nuevo contenido. Más información.

Enviado por ZaZ el 21 January, 2005 - 18:13.

Tagged:

El foro de JabberES

Buenas, aki viene mi primer mensaje al foro. La verdad es k tp sé mucho de jabber. Bien, sin extenderme quiero comentar el tema prioridades. Es un aspecto que se agradece muchísimo, el poder conectar dsd varios puntos a la misma cuenta. Pero tengo aquí un par de dudas ya que mi idea seria tener un servidor siempre conectado con prioridad baja y conectarme con otro de vez en cuando y con más prioridad.Pero...

1- resulta que cuando yo conecto con el de prioridad superior, los mensajes no leidos del servidor allí se quedan, así que como función "contestador" no puedo usarlo. Supongo que más k protocolo eso debe ser el cliente. Existe algun cliente k reenvie los mensajes no leidos a la cuenta de más prioridad cuando esta se conecta?

2- No sé, yo lo considero error, pero si tengo transportes activados, lo más lógico seria que cuando el de más prioridad se desconectara recuperasen el estado del servidor. Es decir, yo tengo el servidor en ausente en el transporte MSN, luego conecto con más prioridad en otro y pongo conectado, pero si luego salgo en el servidor me deja el MSN en estado conectado cuando él, aún siendo el de más prioridad en ese momento, está en ausente.

En fin ,no se si me explico bien y tampoco sé si es problema de protocolo o de cliente. De momento estoy con PSI aunque hecho en falta algunas carencias como conectar con el mismo estado anterior.

En fin, saludos a jabberes y a los foreros :D

Comentarios

Prioridades: rápida interpretación del RFC

Enviado por badlop el 22 January, 2005 - 10:39.

La descripción del elemento Priority está en el RFC 3921,
2.2.2.3 Priority, y más adelante se incluyen algunos ejemplos.

La aplicación de esto se describe en
11.1 4. 1.

For message stanzas,

the server SHOULD deliver the stanza to the highest-priority available resource
(if the resource did not provide a value for the element, the server SHOULD consider it to have provided a value of zero).
If two or more available resources have the same priority, the server MAY use some other rule (e.g., most recent connect time, most recent activity time, or highest availability as determined by some hierarchy of values) to choose between them or MAY deliver the message to all such resources.
However, the server MUST NOT deliver the stanza to an available resource with a negative priority;
if the only available resource has a negative priority, the server SHOULD handle the message as if there were no available resources (defined below).

De todas formas te resultará de interés todo el 11.1, porque explica a quién debe, no debe o debería enviar el mensaje el servidor. Ese texto es de obligado cumplimiento para que el programa sea XMPP/1.0, así que clientes, servidores, transportes, deberian implementarlo. Y si no lo hacen correctamente, entonces han de ser corregidos. En tu caso es el servidor quien debe implementarlo, el cliente no tiene nada que ver.

Si he entendido correctamente el RFC, la funcionalidad que deseas podría conseguirse de la siguiente forma:

Conecta el servidor no atendido con prioridad negativa (-5) y recurso "servidor", de forma que su JID completo sea "pepe@mipopo.com/servidor".
Las conexiones que realizes para ver mensajes debes hacerlas con prioridad positiva y un recurso distinto, pongamos "coco", de forma que su JID completo sea "pepe@mipopo.com/coco".

De esta forma lo que deberia ocurrir es:

Los mensajes enviados a pepe@mipopo.com/servidor los recibe inmediatamente el servidor no atendido a pesar de tener prioridad negativa
Los mensajes enviados a pepe@mipopo.com/coco los recibes inmediatamente en coco.
Los mensajes enviados a pepe@mipopo.com los recibes inmediatamente en cualquier conexión que tenga prioridad positiva.
Los mensajes enviados a cualquier JID que no esté disponible con prioridad positiva se almacenan sin recurso y se enviarán a la primera conexión que se realize a ese JID, sin importar el recurso.
En el RFC no se describen las condiciones para recuperar esos mensajes, pero parece lógico que si la nueva conexión aparece con prioridad negativa no deberían enviársele mensajes almacenados.
Puedes cambiar la prioridad de una conexión sin desconectar, en cuyo caso el servidor debería actuar como si realizaras una conexión nueva con esa nueva prioridad.

Si usas el servidor ejabberd has de saber que están revisando el caso de prioridades negativas porque parece que hay un error.

Del tema del transporte a MSN no tengo ni idea de cómo está el asunto.

gracias por tu ayuda pero...

Enviado por ZaZ el 5 February, 2005 - 11:25.

Lógicamente usando prioridad negativa en el servidor y sobreentendiendo que el transporte, pongamos por ejemplo el de msn, enviase la información a pepe@mipopo.com y no a pepe@mipopo.com/servidor debería funcionar. Mi sorpresa fue ver que los transportes probados de msn no me permiten la prioridad negativa, directamente no registran el servicio y no me dejan conectar. Es una lástima, quizás se solucione en versiones posteriores de los transportes.
Por cierto, alguien sabe de algun cliente que me permita conectar con el último estado usado? es para que siempre se conecte ausente aún reiniciando el cliente.
Ah!, y encuentro a faltar algun cliente que imponga su estado cuando otro con más prioridad lo ha cambiado y se ha desconectado. Es para dejar el servidor en ausente y aunque conectase con más prioridad y cambiase el estado, este volviera a ponerse ausente cuando cierre el cliente con más prioridad.

Salu2 a todos :D