2012-04-28 29 views
11

Tengo un par de aplicaciones móviles nativas de Android e iOS que escribí que se conectan directamente a un servidor XMPP que tengo. Empujan y extraen datos en tiempo real a través de XMPP. También uso algunos de los XMPP XEP extensions. Para otras operaciones, tengo una aplicación django que se ejecuta en el mismo servidor que todas las aplicaciones móviles consumen a través de una interfaz HTTP REST. Utilizo Celery y Redis para el lado django para realizar algunas operaciones de forma asíncrona (como hacer escrituras pesadas por lotes en mi db).Empuje del servidor en tiempo real con Socket IO (o Strophe.js), XMPP y Django

Todo esto funciona bien y dandy. Hurra.

Pero ahora quiero escribir un front-end web para todo esto, así que comencé a investigar mis opciones y bueno, hay tantas maneras de despellejar al gato que quería verificar primero con la comunidad SO.

La idea de tener una biblioteca js que me proporcione una API unificada para las comunicaciones de socket (es decir, probar diferentes implementaciones de sockets web o volver al flash) me atrae, por eso menciono Socket IO. La idea de tener que ejecutar un servidor nodejs, bueno, no tanto (una cosa más para aprender), pero si tengo que hacerlo, definitivamente lo haré. Sé que algunas personas usan gevent as a replacement of the node server. Otros, deciden escribir un small nodejs which they connect to the rest of their stack. Probablemente haría esto.

Otra opción es utilizar una biblioteca js XMPP como Strophe, que no creo que tenga flashback. Además, necesitaría investigar qué significa esto para mi servidor.

He leído varias respuestas de Stackoverflow sobre cómo hacer cometa y django, de ahí que parezca que hay varias opciones.

La pregunta es:

Si yo quiero tener la ventaja de comportamiento Socket IO (con los retrocesos) y quiero enviar datos en tiempo real para el cliente Web (que se está alimentando al servidor a través de XMPP), y usar Django, ¿cuál es mi mejor opción?

Actualización: El servidor XMPP que utilizo es ejabberd, que también es compatible con BOSH. Me doy cuenta de que podría usar Strophe.js y, por lo tanto, mi comunicación pasaría por un tipo de conexión http larga de sondeo en lugar de websockets. Por lo que puedo decir, hay algunos XMPP over Websockets open source library, pero AFAIK la comunidad no es tan activa como la de SocketIO.

Actualización 2: Los navegadores que necesito admitir son solo navegadores modernos. Supongo que esto significa que Flash Fallback no será tan importante, lo que me está inclinando hacia strophe.js.

+1

Hay implementaciones de servidor socket.io en otros idiomas que js. El nodo es solo el servidor de referencia. Tengo un servidor socket.io usando go-socket.io escrito en Go. Python tiene TornadIO2 que usa tornado en su pila. – jdi

Respuesta

5

No estoy seguro de por qué necesitaría Flashbackback si vas a hacer BOSH (XEP-0124, XEP-0206), que es lo que hace strophe.js. Si no necesita soportar IE7, puede hacer CORS desde strophe.js, y ni siquiera necesita un proxy para el mismo origen. IE6 funcionará porque es inseguro, e IE8 + admite una forma de CORS que apenas funciona.

Para obtener información de Django través de XMPP a su cliente, establezca una conexión componente (XEP-0114) a su servidor a través de su favorito Python XMPP library, como SleekXMPP de su aplicación Django. Haga arreglos para que la conexión tenga una vida relativamente larga, para el rendimiento (es decir, no cree una nueva para cada conexión de cliente). Enviar protocolo según sea necesario.

No mencionó qué servidor XMPP está utilizando.Los servidores XMPP que no admiten BOSH son cada vez menos frecuentes, pero si tiene uno, puede necesitar Punjab como un proxy BOSH-to-XMPP, o puede cambiar a un server más reciente, como Prosody.

+0

Estoy usando ejabberd, que ya admite BOSH, así que supongo que no necesito el proxy. No necesito soportar IE6-IE7 y es mi elección si también saco IE8 de la ecuación. – rburhum

8

Creo que una vez que te ensucies las manos con algún nodo, encontrarás que desviarse de Node para socket.io va a ser mucho más difícil. Hay módulos xmpp muy fáciles de usar en el nodo listo para funcionar (vea https://github.com/astro/node-xmpp). Recuerde, el nodo es todo javascript, por lo que probablemente ya esté familiarizado con la programación.

Personalmente, he tenido algunos problemas de pérdida de memoria usando el nodo 0.6 o superior. El nodo 0.4 funcionó sin esos problemas. Si eres nuevo en github (como lo era antes de jugar con Node), aquí tienes cómo ir con un servidor de nodos.

Conseguir Nodo

  1. Ingrese a su máquina Linux y el directorio favorito (voy a suponer /)
  2. git clone https://github.com/joyent/node.git
  3. cd/nodo
  4. -l git tag (esto listará todas las versiones disponibles del nodo)
  5. git checkout v0.6.16 (esto borrará la versión 0.6.16 del nodo, puede reemplazar eso con v0.4.12 por ejemplo si usted tiene problemas de memoria)
  6. ./configure
  7. hacen
  8. make install

que necesitará ciertas herramientas de desarrollo para construirlo como g ++, pero en este momento usted tendrá un trabajo node comando.

módulos de nodo Instalación como XMPP

nodo tiene una buena cantidad de módulos donde la mayoría de las cosas que ya han sido escritas para usted. Hay un servicio de búsqueda en http://search.npmjs.org o puede acceder a todos los módulos directamente desde su shell utilizando el comando npm. NPM es una herramienta de nodos para instalar y administrar módulos de nodos. Puede escribir npm search xmpp para buscar todos los módulos xmpp, por ejemplo. Para instalar una biblioteca básica de xmpp para el nodo, debe hacer npm install node-xmpp. Por cierto, la mayoría de las páginas del módulo del nodo github incluirán instrucciones en el archivo readme de la página principal.

Mantener Nodo Ejecución en producción

Esto me echó cuando empecé a cabo. Si tiene algún error que no sea capturado, el nodo simplemente morirá. Entonces, puede 1. Asegúrese de que no haya ningún error o que todos estén atrapados (es improbable porque incluso el propio Nodo generará un error) 2. Utilice el controlador uncaughtException para detectar estos problemas. Se podría utilizar un código como éste en su programa

process.addListener("uncaughtException", function (err) { 
    util.log("Uncaught exception: " + err); 
    console.log(err.stack); 
    console.log(typeof(this)); 
    // maybe email me? 

}); 

ser extra y uso seguro siempre

Incluso con el tema uncaughtException su programa en la producción podría morir. Se está agotando la memoria, segfaults, quién sabe qué. Ahí es donde vale la pena usar algo como el maravilloso módulo Node llamado "Forever" (ver https://github.com/nodejitsu/forever).Puede escribir npm install forever -g para instalarlo para siempre. Tenga en cuenta la opción -g que coloca para siempre en el directorio del módulo de nodo GLOBAL. Sin -g pone el módulo de nodo en el directorio de trabajo actual. A continuación, podrá escribir algo así como (suponiendo que su programa de nodo se llamó my_program.js) forever start my_program.js y luego el programa Forever se asegurará de que si se muere se reinicie.

2

Estamos utilizando push en tiempo real también con Django y Apio. Cuando primero creé la arquitectura, también investigué mis opciones. Eventualmente, decidí que preferiría centrarme en hacer la aplicación correcta en lugar de enredarme con el trabajo de Devops. Existen varios servicios que ofrecen tecnología de inserción en tiempo real alojada que se puede integrar fácilmente con cualquier aplicación.

Elegí PubNub y no podría estar más feliz. Soportan socket.io para el lado del cliente y tienen una lib de Python que uso de los trabajadores de Django y Apio. También tienen SDK que puedes usar desde aplicaciones móviles nativas.

Sé que ya tiene una configuración en funcionamiento. Pero estoy apostando a que el tiempo que le tomará reemplazar su configuración actual con una solución alojada de este tipo sería menor que el tiempo que le llevará encontrar una buena solución para lo que está buscando e implementarlo. También tenga en cuenta los costos de mantenimiento en el camino (especialmente si opta por una lib que no se mantiene bien).

Cierto, pagará por el servicio, pero el precio es muy razonable y obtendrá un servicio sólido con bonitas ventajas como la colocación.

No estoy afiliado a esa empresa, solo soy un cliente satisfecho. Hay other similar services out there.

+0

El problema es que cada cliente puede potencialmente enviar 1 msg por segundo y, a lo sumo, 1 msg por segundo (eso es solo si guardo, optimizo y compacto los mensajes del servidor en 1).Dado que esta será una parte fundamental de mi infraestructura, preferiría no subcontratarla a otra empresa. Sin embargo, su enlace a la pregunta sobre la quora dio enlaces a varias opciones autohospedadas. ¡Gracias! – rburhum

4

En primer lugar, divulgación completa: trabajo para una empresa llamada PubNub, que voy a mencionar en breve.

Hay toda una gama de servicios de mensajería bidireccional alojados (a veces llamados IaaS - Infraestructura como servicio) que creo que vale la pena considerar. Ellos son Pusher, Firebase, Flotype, PubNub y otros. Estoy razonablemente seguro de que podría usar cualquiera de ellos para lo que quiere lograr. Firebase tiene una base de datos incorporada que se conecta directamente con su servicio, que es una característica muy buena, pero probablemente no sea útil para su caso de uso particular (supongo que ya tiene una base de datos en su back-end).

No puedo hablar demasiado sobre nuestros competidores, pero por lo que usted quiere una biblioteca de JavaScript en la interfaz que se comunica con su servidor Python, nosotros (PubNub) proporcionamos a very similar api in both languages y que se comunican en el mismo bus de datos en la nube . Para que pueda enviar mensajes con Python y atraparlos con JavaScript, o viceversa. Incluso escribimos un PubNub-hosted version of socket.io, que podría usar en lugar de nuestra api de JavaScript vainilla, y aún así vincularlo a su back-end de Django en aproximadamente 10 líneas de código.

Finalmente, lo bueno de usar un IaaS (o al menos nosotros, una vez más no estoy seguro acerca de los otros) es que manejamos ese complicado problema de escala para usted. Si llega al punto de un millón de usuarios simultáneos y necesita enviarles algo en tiempo real, verá que no hay problema.

Cuestiones relacionadas