PubNub publica mensaje entre dos canales privados.

pubnub documentation

Question

Estoy usando Php y MySQL.

Acabo de registrarme para la API push de pubnub y he realizado con éxito mi primera notificación push utilizando la API push de PHP proporcionada por Pubnub. Soy nuevo en esta tecnología en tiempo real, así que se me ocurren algunas preguntas que me resultan confusas para entenderme. He buscado en Google muchas veces y he buscado en todo el stackoverflow. No recibí ninguna sugerencia ni pregunta relevante en ningún otro lugar, por lo que escribo mi pregunta aquí en busca de consejo y experiencia.

Pubnub dice que no es bueno crear más de dos canales por cliente. Por lo tanto, en mi solicitud, tengo el requisito de crear más de dos canales para escuchar las notificaciones que ocurren en cualquier lugar de mi sitio web, pero voy a usar dos canales para cada usuario que inicie sesión como sugirió Pubnub.

1. Los usuarios registrados escuchan a Channel1-Public
   
2. Los usuarios registrados escuchan el canal privado UsersOwnDynamic para recibir notificaciones relacionadas y solo para él.

FYI: Este enlace en PubNub dice acerca de la creación de nombres de LongChannel para evitar la indagación del canal.

Mis preguntas se dan a continuación:
R. ¿Siempre tengo que crear un nuevo nombre de canal dinámico privado cada vez que inicie sesión en el sitio web? De ser así, ¿cómo sabrían otros usuarios cómo enviar una notificación a mi canal privado? O, solo necesito tener un solo nombre de canal estático almacenado en la tabla de la base de datos, para que otros usuarios autenticados consulten la tabla y obtengan mi canal privado. Nombre para enviarme notificaciones. Si este es el caso, ¿no crees que si un pirata informático consigue algún nombre de canal privado de ciertos usuarios, podrán escuchar ese canal?

B. Estoy usando PHP y MySQL, por lo que todavía no puedo pensar en una manera o encontrar una solución para enviar mensajes a canales privados de otro usuario.
Tomemos un ejemplo para un sistema simple de solicitud de amistad.
- UserA envía una solicitud de amistad a UserB.
- UserB está escuchando su propio nombre de canal privado dinámico llamado DynamicPrivateChannelB
(¿Cómo encontrará UserA el nombre del canal para UserB que es privado? Creo que la única forma de hacerlo es que el canal privado de UserB se almacene en una tabla de base de datos para que todos los usuarios que inician sesión consulten. ¿Estoy pensando de la manera correcta?)

<?php
//first way. How can i possibly achieve this.
$sqlquery = "sent friend request from userA to userB";
require(''Pubnub.php'');
$pubnub = new Pubnub( ''pubkey'', ''subkey'' );
$pubnub->publish( array(
''channel'' => ''how do i find the private channel name for userB to sent this notification?'',
''message'' => array(''friend_request'' => ''A friend request'') )
);
//2nd way ? Is this the right way ?
$sqlquery = "sent friend request from userA to userB";
$privatechannelofuserB = "get the channel name of userB from the db table";
require(''Pubnub.php'');
$pubnub = new Pubnub( ''pubkey'', ''subkey'' );
$pubnub->publish( array(
''channel'' => ''$privatechannelofuserB'',
''message'' => array(''friend_request'' => ''A friend request'') )
);
?>

C. Si siempre estamos generando nombres de canales privados dinámicos, almacenándolos en la tabla de base de datos, actualizando cada vez que se generan nuevos nombres de canales dinámicos. Creo que causará un problema porque algunos mensajes no se entregarán cuando los nuevos nombres de canales privados dinámicos reemplacen a los antiguos.

D. Por lo tanto, tengo muchas notificaciones para enviar a un solo canal, como la solicitud de Nuevos amigos, Nuevas respuestas de mensajes privados, Nuevas solicitudes de regalos y muchos otros similares. ¿Cómo envío todos estos datos a un canal y cómo averiguar y analizar los nuevos datos de notificaciones entrantes? Sé que JSON es el formato para enviar, pero no estoy seguro sobre el formato de envío.

Según este enlace , un solo canal de Pubnub puede contener solo hasta 100 mensajes. ¿Significa que si llegan 200 mensajes a la vez a un solo canal, los primeros 100 se entregan y el resto está en cola? ¿Qué tal si 10.000 mensajes llegan a la vez a un solo canal? ¿Todos los mensajes restantes permanecen en cola? Si es así, ¿cómo se entrega al suscriptor en tiempo real?

Déjame darte otro escenario simple que estoy tratando de lograr.

• UserA se autentica y se registra en el sitio web.
  
• UserA genera su propio nombre de canal dinámico, UserAx732dsw3efsdfsdfsdf
  
• UserA comienza a escuchar su canal creado recientemente UserAx732dsw3efsdfsdfsdf
  (Ahora, el usuario A debería comenzar a recibir mensajes de otros)
  

- UserB envía un mensaje privado a userA .
(Ahora, solo el usuario A debe recibir una notificación en su canal privado sobre el nuevo mensaje privado, ¿cómo puede el usuario B o el Sistema averiguar el nombre del canal UsuarioAx732dsw3efsdfsdfsdf porque este es un canal privado generado dinámicamente por el usuario A , ni el Sistema ni el usuarioB han accedido a Esto también está sucediendo para el usuario B , si el usuario B debería ser notificado por otra entidad o por el sistema nuevamente, debería haber una manera de averiguar el nombre del canal dinámico del usuarioB .

Otro problema es que este escenario es que, si un usuario está generando dinámicamente el nombre del canal cada vez que inicia sesión en el sitio web. ¿Qué sucederá con todos los mensajes que se enviaron al canal dinámico? ¿Pubnub guarda todos los nombres de los canales creados en su servidor? ¿Hay alguna forma en que un sistema o un usuario pueda descubrir si un nombre de canal aún es propio y al menos un usuario está escuchando el canal?

Tengo curiosidad por saber esto debido a los siguientes conceptos que tengo:

• El usuario A crea dynamicChannelA cuando inicia sesión en el sitio web a la 1AM .
  
• El usuario A comienza a recibir una gran cantidad de notificaciones para su canal dinámico dynamicChannelA
  
• Ahora, UserA se desconecta del sitio web a la 1:30 AM , lo que sucederá con los muchos otros usuarios que todavía están publicando notificaciones a su dynamicChannelA porque la próxima vez que UserA inicie sesión en el sitio web, UserA escuchará diferentes dinámicas. Nombre del Canal. El usuario A no estará escuchando su canal dinámico dynamicChannelA .

Estoy pensando en usar el método para recuperar el nombre del canal de un usuario en particular de la tabla de la base de datos. ¿Hay algún método o forma de evitar la suscripción no autorizada del canal? Porque cualquiera puede suscribirse al nombre del canal si tiene la clave de suscripción y el nombre del canal, sin importar cuánto tiempo sea el nombre del canal. Tengo curiosidad porque todas las suscripciones están ocurriendo en el lado del cliente y la clave de suscripción y los nombres de los canales están visibles.

Answer 1

No hay una única manera de abordar los problemas que te has encontrado. Nuestros clientes han utilizado una amplia variedad de patrones de diseño para lidiar con ellos. Yo mismo me he encontrado con este tipo de cosas creando aplicaciones de PubNub y te ayudaré tanto como pueda.

Pubnub dice que no es bueno crear más de dos canales por cliente. Por lo tanto, en mi aplicación, tengo el requisito de crear más de dos canales para escuchar las notificaciones que ocurren en cualquier lugar de mi sitio web, pero voy a usar dos canales para cada usuario que inicie sesión como sugirió Pubnub.

Los usuarios registrados escuchan a Channel1-Public Los usuarios registrados escuchan el canal privado UsersOwnDynamic para recibir notificaciones relacionadas y solo para él.

Esta es una buena manera de hacerlo, y la forma en que muchos de nuestros clientes a gran escala lo hacen. Un canal global y un canal privado, solo para usuarios.

A.

Siempre tengo que crear un nuevo nombre de canal dinámico privado cada vez que inicie sesión en el sitio web.

No necesariamente, aunque esta es una buena manera. Puede usar PUBNUB.uuid() en JavaScript en el lado del cliente para hacer esto. O bien, genérelo del lado del servidor usando PHP y renderícelo al cliente. Tal vez podría configurarlo como una cookie para que el cliente siempre tenga acceso a ella.

Si es así, ¿cómo sabrían otros usuarios cómo enviar una notificación a mi canal privado?

Podrían obtener los ID del servidor PHP; ya sea a través del canal global o del propio canal privado del usuario, que están escuchando.

O, solo necesito tener un nombre de canal estático almacenado en la tabla de la base de datos, para que otros usuarios autenticados consulten la tabla y obtengan mi nombre de canal privado para enviarme las notificaciones.

Podrías hacerlo de esta manera también. Es posible que el canal global que los usuarios pueden enviar sea diferente al canal global que están escuchando. Solo el servidor tiene esa clave de suscripción. Por lo tanto, los usuarios autenticados envían un mensaje al servidor que le dice "Necesito las claves de usuario adecuadas", luego el servidor realiza una consulta y envía un mensaje a ese canal privado de ese usuario.

Si este es el caso, ¿no crees que si un pirata informático consigue algún nombre de canal privado de ciertos usuarios, podrán escuchar ese canal?

Si retiene la clave de suscripción en el canal de envío global, solo el servidor puede ver la conversación en ese canal.

SEGUNDO.

Estoy usando PHP y mysql, así que todavía no puedo pensar en una manera o encontrar una solución para enviar mensajes a canales privados de otro usuario. Tomemos un ejemplo para un sistema simple de solicitud de amistad. - UserA envía una solicitud de amistad a UserB. - UserB está escuchando su propio nombre de canal privado dinámico llamado DynamicPrivateChannelB (¿cómo el Usuario A encontrará el nombre del canal para el UsuarioB que es privado? Estoy pensando que la única forma de hacerlo es que el canal privado del UsuarioB se almacene en una tabla de base de datos para cada inicie sesión para que los usuarios consulten. ¿Estoy pensando de la manera correcta?)

Esto es muy similar a tu pregunta anterior. No hay una sola manera de hacerlo, pero el patrón de diseño que describí anteriormente debería funcionar. Para recapitular este patrón de diseño:

Lado del servidor

• Escucha en Global-user-send-channel para mensajes de usuario. El servidor es la única entidad que tiene esta clave de suscripción.
• Puede consultar la base de datos para obtener los ID de usuario y luego enviarlos a los diversos ID a voluntad
• También puede enviar en el canal de recepción de usuario global, que todos los clientes están escuchando. El servidor es la única entidad que tiene esta clave de publicación.

Lado del cliente

• Escucha en el canal de recepción de usuario global. Así es como se consigue la difusión masiva del servidor. No se puede enviar en este canal (solo tiene clave de suscripción)
• Envía mensajes de servidor en Global-user-send-channel. No se puede recibir en este canal (solo tiene clave de publicación)
• Escucha en el canal de usuario privado. Así es como el usuario recibe mensajes privados. También puede usar esto para la comunicación de cliente a cliente.
• Prevenga el abuso agregando todos los mensajes privados con una clave privada por usuario almacenada en el servidor y provista durante la carga de la página inicial. De esa manera, un cliente sabe si un mensaje que dice ser del servidor es legítimo.

DO.

Si siempre estamos generando nombres de canales privados dinámicos, almacenando en la tabla de la base de datos, actualizando cada vez que se generan nuevos nombres de canales dinámicos. Creo que causará un problema porque algunos mensajes no se entregarán cuando los nuevos nombres de canales privados dinámicos reemplacen a los antiguos.

Si tiene cuidado cuando genera nuevos nombres de canales, esto no debería ser un problema. Tenga en cuenta que el cliente siempre puede decir en el canal de envío de usuarios globales. ¡Hola, aquí estoy! esta es mi id mantenme informado''. Por lo general, diseño mis aplicaciones para que los clientes griten esto cada 30 segundos aproximadamente.

RE.

Por lo tanto, tengo muchas notificaciones para enviar a un solo canal, como la solicitud de nuevos amigos, las nuevas respuestas de mensajes privados, las solicitudes de nuevos regalos y muchos otros más. ¿Cómo envío todos estos datos a un canal y cómo averiguar y analizar los nuevos datos de notificaciones entrantes? Sé que JSON es el formato para enviar, pero no estoy seguro sobre el formato de envío.

JSON es bueno para enviar y recibir. La forma en que lo hago es tener una propiedad llamada "nombre" que define qué tipo de mensaje es. Por ejemplo:

{
"id" : "blah_blah_unique_id", // sender_client_id
"name" : "friend_request", // type of message
"data" : { // the data itself
"requested_friend_id" : "blah_blah_some_other_unique_id"
}
}

Puede usar el formato que desee, pero lo envolveremos en JSON (normalmente eso significa solo entre comillas) cuando pase a través de PubNub.

¡Espero que esto ayude!

Nuevas preguntas

Según este enlace , un solo canal de Pubnub puede contener solo hasta 100 mensajes. ¿Significa que si llegan 200 mensajes a la vez a un solo canal, los primeros 100 se entregan y el resto está en cola? ¿Qué tal si 10.000 mensajes llegan a la vez a un solo canal? ¿Todos los mensajes restantes permanecen en cola? Si es así, ¿cómo se entrega al suscriptor en tiempo real?

El límite de 100 mensajes se refiere a PubNub.history. Si alguien está suscrito y llegan 200 mensajes, recibirán los 200 mensajes.

(Ahora, solo el usuario A debe recibir una notificación en su canal privado sobre el nuevo mensaje privado, ¿cómo puede el usuario B o el Sistema averiguar el nombre del canal UsuarioAx732dsw3efsdfsdfsdf porque este es un canal privado generado dinámicamente por el usuario A, ni el Sistema ni el usuarioB han accedido a Esto también está sucediendo para el usuario B, si el usuario B debería ser notificado por otra entidad o por el sistema nuevamente, debería haber una manera de averiguar el nombre del canal dinámico del usuarioB.

No hay una solución única para esta pregunta, pero lo que sí haría es que el servidor genere esa identificación única en la carga de la página y la represente al cliente en su solicitud HTTP inicial.

Otro problema es que este escenario es que, si un usuario está generando dinámicamente el nombre del canal cada vez que inicia sesión en el sitio web. ¿Qué sucederá con todos los mensajes que se enviaron al canal dinámico? ¿Pubnub guarda todos los nombres de los canales creados en su servidor?

No tienes que generar dinámicamente cada vez. Podría ... pero también configura una cookie con esa identificación única, o la extrae de la base de datos y la presenta al cliente cuando se carga la página (eso es lo que haría). No guardamos los nombres de los canales.

¿Hay alguna forma en que un sistema o un usuario pueda averiguar si un nombre de canal aún es propio y al menos un usuario está escuchando el canal?

No fuera de la caja, pero podría implementarlo fácilmente. Simplemente haga que su servidor envíe un ping y configure a sus clientes para que respondan siempre a los pings si están escuchando.

Ahora, UserA se desconecta del sitio web a la 1:30 AM, lo que sucederá con los muchos otros usuarios que todavía están publicando notificaciones a su dynamicChannelA porque la próxima vez que UserA inicie sesión en el sitio web, UserA escuchará diferentes dinámicas. Nombre del canal. UsuarioU no escuchará su canal anterior dynamicChannelA.

La forma en que puede evitar esto es hacer pings periódicos (¿cada 30 segundos?) Desde el servidor, que pueden realizar un seguimiento si los usuarios siguen allí. En los próximos meses lanzaremos una API de presencia para hacer esto automáticamente, por cierto.

Estoy pensando en usar el método para recuperar el nombre del canal de un usuario en particular de la tabla de la base de datos. ¿Hay algún método o forma de evitar la suscripción no autorizada del canal? Porque cualquiera puede suscribirse al nombre del canal si tiene la clave de suscripción y el nombre del canal, sin importar cuánto tiempo sea el nombre del canal. Solo tengo curiosidad porque toda la suscripción está ocurriendo en el lado del cliente y la clave de suscripción y los nombres de los canales son visibles

La forma principal es retener estratégicamente las claves de publicación / suscripción. Tiene razón en que cualquier persona con los detalles adecuados puede escuchar: este es un gran problema de los sistemas solo para clientes. Por el momento, tendrás que encontrar formas creativas para solucionarlo.