Mensajería privada utilizando sockjs-tornado

He implementado la función de chat usando sockjs-tornado y pude almacenar los mensajes en RethinkDB.

¿Podría ayudarme, por favor, en cómo establezco un canal privado para mensajes en sockjs-tornado? (Quiero decir conversación privada / uno a uno)

A continuación se muestra la función on_message en el código del lado de mi servidor:

def on_message(self, message): str=message mg=str.split('#:#') sender=1 # This is the sender user id receiver=2 #This is the receiver user id - I need to implement session variables to have these id's so that I can use it here this way ts=r.expr(datetime.now(r.make_timezone('00:00'))) connection = r.connect(host="192.xxx") r.db("djrechat").table('events').insert({"usrs":mg[0],"msg":mg[1],"tstamp":ts,"snder":sender,"rcver":receiver}).run(connection) log.info(message) self.broadcast(self.participants, '{} - {}'.format(self.stamp(),message)) 

Actualmente esto se está transmitiendo a todos los clientes conectados. Puede ser que deba tener un ID de canal y enviar un mensaje solo a los dos clientes que tendrán el mismo ID de canal, pero ¿cómo lo implemento o hay alguna solución mejor para esto?

En el lado del cliente, tengo a continuación javascript –

  function connect() { disconnect(); conn = new SockJS('http://localhost:8080/chat', ['websocket','xhr-streaming','iframe-eventsource','iframe-htmlfile','xhr-polling','iframe-xhr-polling','jsonp-polling']); //log('Connecting.....'); conn.onopen = function() { // log('Connected. (' + conn.protocol + ')'); log('Connected.'); }; conn.onmessage = function(e) { log(e.data); }; conn.onclose = function() { log('Disconnected.'); conn = null; }; } 

Estoy usando python 3.4 – Django 1.8.4 y Rethinkdb

Mi respuesta supone que todos los clientes en la solución actual se conectan a un servidor SockJS con un nombre de canal que se usa para la difusión de los mensajes de chat (o algo parecido a este escenario). Además, asumo que el viaje de ida y vuelta cuando un usuario envía un mensaje del cliente es:

 [Sender (Client)] ------- Message (POST) --> [App Server] --- Message --> [Database] | Message v [Receiver(s) (Client)] <-- Message (WS) -- [SockJS Server] 

Existen múltiples soluciones a este problema. Solo delinearé el que creo que es el más simple y robusto aquí:

  • Permita que cada usuario se suscriba a un canal por usuario (privado) además del canal de difusión en el chat. Si implementa esta solución, el único cambio adicional es hacer que el servidor de aplicaciones tenga conocimiento de los mensajes privados que deben enviarse únicamente al canal privado del receptor.

Otra solución poco más compleja y poco elegante sería crear canales ad hoc para cada par privado cuando sea necesario. Sin embargo, ¿cómo conseguiría que el User B suscriba al canal privado (recién creado) cuando el User A quiere chatear con el User B ? Una forma sería transmitir una solicitud para que el User B conecte a ese canal, pero eso le diría a todos los demás clientes (a nivel de código) acerca de este chat privado que tendrá lugar; y si alguno de esos clientes se ve comprometido, esa información puede ser mal utilizada para, por ejemplo, espiar o estrellar a la parte privada.

Consejos adicionales

También me gustaría mencionar que desde que escribí mi sockjs - ejemplo de implementación de respuesta de las salas , he cambiado mi propia architecture para (aún) usar SockJS en la parte frontal, pero con RabbitMQ usando el complemento Web-STOMP en la parte posterior fin. De esa manera,

  1. el cliente sigue utilizando sockjs-client con stomp-websocket en el navegador,
  2. todo el código de back-end para manejar la multiplexación de front-end podría eliminarse ,
  3. el back-end (basado en RabbitMQ) es rápido y realmente robusto ,
  4. el cliente envía un mensaje al servidor de aplicaciones back-end, que a su vez
    1. persiste el mensaje en la base de datos, y
    2. actúa como cliente del servidor RabbitMQ y (1) transmite el mensaje a todos los usuarios conectados, o si el mensaje es privado (2) envía el mensaje a un solo destinatario a través del propio canal privado del destinatario, tal como se indica en el esquema anterior. solución sugerida.

Toda la nueva solución se coloca detrás de HAProxy, que finaliza las conexiones WebSocket cifradas con HTTPS y SSL / TLS.

Si bien sockjs-tornado no implementa una cosa como los canales, ni las habitaciones, hay un ejemplo múltiple de cómo se podría implementar eso. También mire sockjs – ejemplo de implementación de salas . La solución se basa en un mensaje estructurado: en el mensaje se envía información adicional, nombre del canal.