Metodos y funciones bosh
// iniciar conexion con example.com
var conn = Strophe.Connect(BOSH_SERVICES);
conn.connect(“user@example.com”, “mypassword”, my_callback);
// tetminar conexion
conn.disconnect();
function my_callback(status) {
if (status === Strophe.Status.CONNECTED) {
conn.disconnect();
}
}
var pres1 = $build(“presence”);
var pres2 = $build(“presence”, {to: “example.com”});
var pres3 = $pres();
var pres4 = $pres({to: “example.com”});
var message = $msg({to: “darcy@pemberley.lit”, type: “chat”})
.c(“body”).t(“How do you do?”);
XML producido con la variable message:
<message to=’darcy@pemberley.lit’
type=’chat’>
<body>How do you do?</body>
</message>
Strophe.Connection.sendIQ(iq_stanza, success_callback, error_callback);
Strophe.connection.addHandler(on_message,
null, “message”, “chat”);
crear una biblioteca de cliente que acepte la entrada a través de
métodos estándar (por ejemplo, un enlace web) y retransmite los datos
apropiados al usuario en tiempo real. Normalmente, las aplicaciones web simulan
continuamente las interfaces actualizadas mediante JavaScript asíncrono y XML
(Ajax) para sondear un servidor con frecuencia. En este modelo, la página web
de la aplicación contiene JavaScript, que hace repetidas solicitudes a una
devolución de llamada del servidor en segundo plano. Aunque la capacidad de
respuesta de las aplicaciones Ajax es adecuada en muchas situaciones, esta
técnica tiene inconvenientes
XMPP, sus orígenes y por qué es un protocolo adecuado para comunicaciones web en tiempo real. facilitar la comunicación en tiempo real, así como también instalar soluciones de terceros ya hechas.
Para facilitar la entrega de mensajes, cada usuario del cliente XMPP debe tener un identificador único universal. Por razones heredadas, estos se denominan ID de Jabber o JID.
Los JID también pueden tener un recurso adjunto
nodos de cliente y servidor
John.doe@somecorp.com/Work
jid : identificador
@somecorp.com :es la dirección del servidor XMPP para SomeCorp
podría usarse para enviar datos a sus herramientas relacionadas con el trabajo. Estos permiten una mayor granularidad de direccionamiento más allá de un identificador para una entidad XMPP
tres amplias categorías de comunicación
- Mensajería, donde los datos se transfieren entre las partes
- Presencia, lo que permite a los usuarios transmitir su estado en línea y disponibilidad
- Solicitudes de información / consulta, que permiten a una entidad XMPP realizar una solicitud y recibir una respuesta de otra entidad
Cada uno de ellos se entrega a través de una estrofa XML completa: un elemento discreto de información expresado en XML.
llamados stanzas o etiquetas xmpp
from="[server]" id="[unique ID over conversation]"xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams" version="1.0"
estas se tranfieren mediate flujos o corrientes llamados Stream
<stream:stream from="[server]" id="[unique ID over conversation]"xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams"version="1.0">
La transferencia de datos a través de XMPP tiene lugar a través de secuencias XML, que operan en el puerto 5222 de forma predeterminada.
Una vez que se establece la comunicación, el cliente puede enviar un mensaje a otro usuario con el elemento de mensaje
stanzas de mensajes son las stanzas más útiles para proporcionar interfaces web en tiempo real
<message from="sendinguser@somedomain" to="recipient@somedomain" xml:lang='en'> <body> Body of message </body></message>
formato de publicación Atom basado en XML
Cada elemento está contenido dentro de un elemento, luego colectivamente dentro de un elemento pubsub, y finalmente como una stanza de información / consulta. En el Listado 3 (tomado de la especificación XMPP publish-subscrib
<body xmlns='http://jabber.org/protocol/httpbind' xmlns:xmpp='urn:xmpp:xbosh' xmlns:stream='http://etherx.jabber.org/streams' xmpp:version='1.0' authid='17706909560506767636' sid='d75c330c192019919f0cf8950c39180d69f87695' wait='60' ver='1.11' polling='2' inactivity='30' hold='1' xmpp:restartlogic='true' requests='2' secure='true' maxpause='120' from='im.rtedesw29.com'/>
2. enviar presencia. / Stophe.connection.send(xml);
3. query para roster. / roster como una consulta al servidor.
Eventos:
- Timed
- Stanza
Ejemplos:
$('#send').click(function ({ // build stanza; //send message}))\
escuchadores:
Add a stanza handler for the connection.
Strophe.connection.addHandle(
on_message // handler escuchador
, null, // ns name space
message, // name nombre stanza
chat // type tipo stanza
);
funtion on_Mensaje(){
// extract mensaje
// mostrar texto del mensaje en el chat
return true;
}
IQ STANZA
Strophe.connection.addHandller(
on_iq_version, //evento que queremos en este caso solicitamos una version
jabber:iq:version // Colocamos el tipo de namespace.
iq // nombre del evento
get // tipo de solicitud al servidor
);
Uno o unos pocos editores que transmiten a muchos suscriptores de solo lectura es el territorio central del pubsub. A diferencia de MUC, los suscriptores no publican y no reciben información sobre otros suscriptores. Las implementaciones de
Server tienden a tener un control de acceso mucho más flexible para pubsub.
Solo cargas útiles personalizadas, no hay mensajes de chat estándar.
Opcionalmente tiene persistencia completa del artículo.
Un nodo se puede administrar como una lista de elementos (es decir, agregar / eliminar con notificación) en lugar de una simple transmisión.
Las suscripciones pueden persistir estando fuera de línea.
https://www.ejabberd.im/faq/tcp/index.html
https://www.ejabberd.im/node/1093/index.html
https://github.com/processone/ejabberd/issues/1643
Comentarios
Publicar un comentario