PubNub在两个私有频道之间发布消息

RT *_*ger 18 pubnub

我正在使用Php和MySQL.

我刚刚注册了pubnub push API,并使用Pubnub提供的PHP Push API成功完成了我的第一个推送通知.我是这个实时技术的新手,所以我想出了一些让我很难理解的问题.我已经google了很多次搜遍了stackoverflow.我在其他地方没有得到任何相关的建议或问题,所以我在这里写下我的问题,寻求你的建议和专业知识帮助.

Pubnub说每个客户创建两个以上的频道并不是一件好事.因此,在我的应用程序中,我需要创建两个以上的频道来收听我网站上发生的任何通知,但我会像Pubnub建议的那样为每个登录用户提供两个频道.

  1. 登录用户收听Channel1-Public
  2. 登录用户监听私人UsersOwnDynamic-Channel以接收相关的通知,仅对他有意义.

仅供参考:PubNub中的此链接说明了如何创建LongChannel名称以避免Channel Snooping

我的问题如下:
A.每次登录网站时,我是否总是要创建一个新的私有动态频道名称.如果是这样,其他用户如何知道如何向我的私有频道发送通知.或者,我只需要在数据库表中只存储一个静态频道名称,以便其他经过身份验证的用户将查询该表并获取我的私有频道姓名给我发送通知.如果是这种情况,你不觉得黑客是否掌握了某些用户的私人频道名称,他们是否能够收听该频道?

B.我正在使用PHP和MySQL,所以我仍然无法想出办法或想出一个解决方案来向另一个用户的私人频道发送消息.
让我们举一个简单的朋友请求系统的例子.
- UserA向UserB发送好友请求.
- UserB正在监听他自己的动态专用通道名称DynamicPrivateChannelB
(UserA如何找到UserB的私有通道名称?我认为唯一的方法是UserB的私有通道应该存储在每个数据库表中登录用户查询.我在想正确的方法吗?)

<?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') ) 
                    );
?>
Run Code Online (Sandbox Code Playgroud)

C.如果我们始终生成动态专用通道名称,则存储在数据库表中,每当生成新的动态通道名称时进行更新.我认为这会导致问题,因为一些消息将无法传递,因为新的动态专用通道名称将取代旧的.

D.所以,我有很多通知发送到单个频道,如新朋友请求,新私人消息回复,新礼物请求和许多其他类似.如何将所有这些数据发送到频道以及如何查找和解析传入的新通知数据.我知道JSON是要发送的格式,但我不确定发送的格式.

根据此链接,单个Pubnub通道最多只能包含100条消息.这是否意味着如果200个消息一次出现在一个通道中,前100个消息将被传递,剩下的消息是否在队列中?如果10,000条消息一次出现在一个频道上怎么样?所有剩余的消息是否都在队列中?如果是这样,它如何实时传递给订户?

让我举一个我想要实现的简单场景.

  • UserA已通过身份验证并登录到网站.
  • UserA生成自己的动态通道名称UserAx732dsw3efsdfsdfsdf
  • UserA开始收听他新创建的频道UserAx732dsw3efsdfsdfsdf
    (现在,userA应该开始接收来自其他人的消息)


- UserBuserA发送私人消息.
(现在,只有用户A应该得到他关于新悄悄话专用通道通知,怎么能用户B120系统找出路名UserAx732dsw3efsdfsdfsdf因为,这是一个专用通道,通过动态生成的用户A,无论是系统用户B已经进入到同样的事情也发生在userB上,如果userB应该被任何其他实体或系统再次通知,应该有办法找出userB的动态通道名称.

另一个问题是这个场景是,如果用户每次登录网站都动态生成频道名称.发送到动态频道的所有消息会发生什么?pubnub会将所有创建的频道名称保存在他们的服务器上吗?有没有办法一个系统或用户可以找出一个频道名称是否仍然是自己的,并且至少有一个用户正在收听该频道?

我很想知道这个,因为我有以下几个概念:

  • UserA凌晨1点登录网站时创建dynamicChannelA.
  • UserA开始向他的动态频道dynamicChannelA发送大量通知推送
  • 现在,UserA凌晨1:30从网站注销,仍然会向其dynamicChannelA推送通知的许多其他用户会发生什么事情,因为下次UserA 登录网站时,UserA将会收听不同的动态频道名称.UserA将不会收听他以前的频道dynamicChannelA.


我正在考虑使用从数据库表中检索特定用户的通道名称的方法.是否有任何方法或方法可以防止未经授权的频道订阅?因为任何人都可以订阅频道名称,如果他们有订阅密钥和频道名称,无论频道名称有多长.我只是好奇,因为所有订阅都发生在客户端,订阅密钥和通道名称是可见的.

小智 30

没有一种方法可以解决您遇到的问题.我们的客户使用各种各样的设计模式来处理它们.我自己也遇到了构建PubNub应用程序的这类东西,我会尽我所能帮助你.

Pubnub说每个客户创建两个以上的频道并不是一件好事.因此,在我的应用程序中,我需要创建两个以上的频道来收听我网站上发生的通知,但我会像Pubnub建议的那样为每个登录用户提供两个频道.

登录用户侦听Channel1-Public Logged in用户侦听私人UsersOwnDynamic-Channel以接收相关通知,仅对他有意义.

这是一个很好的方法,也是我们许多大规模客户的方式.全球频道和私人用户专用频道.

一个.

每次登录网站时,我是否总是要创建一个新的私人动态频道名称.

不一定,虽然这是一个好方法.您可以PUBNUB.uuid()在客户端使用JavaScript来执行此操作.或者,使用PHP生成服务器端并将其呈现给客户端.也许您可以将其设置为cookie,以便客户端始终可以访问它.

如果是这样,其他用户将如何知道如何向我的私人频道发送通知.

他们可以从PHP服务器获取id; 通过全球频道或用户自己的私人频道,他们正在收听.

或者,我只需要在数据库表中只存储一个静态通道名称,以便其他经过身份验证的用户将查询该表并获取我的私有通道名称以向我发送通知.

你也可以这样做.您可能拥有的用户可以发送的全局频道与他们正在收听的全局频道不同.只有服务器具有订阅密钥.因此,经过身份验证的用户向服务器发送消息,告知其"我需要相应的用户密钥",然后服务器执行查询并在该用户专用信道上发回消息.

如果是这种情况,你不觉得黑客是否掌握了某些用户的私人频道名称,他们是否能够收听该频道?

如果您在全局发送通道上隐藏订阅密钥,则只有服务器可以在该通道上看到聊天.

B.

我使用PHP和mysql,所以我仍然想不出办法或想出一个解决方案来向另一个用户的私人频道发送消息.让我们举一个简单的朋友请求系统的例子. - UserA向UserB发送好友请求. - UserB正在监听他自己的动态专用通道名称DynamicPrivateChannelB(UserA如何找到UserB的私有通道名称?我认为唯一的方法是UserB的私有通道应该存储在每个数据库表中登录用户查询.我在想正确的方法吗?)

这与您之前的问题非常相似.没有办法做到这一点,但我上面概述的设计模式应该有效.回顾一下这种设计模式:

服务器端

  • 在Global-user-send-channel上侦听用户消息.服务器是唯一具有此订阅密钥的实体
  • 可以查询db以获取用户ID,然后随意发送到各种ID
  • 也可以发送所有客户端都在监听的全局用户接收频道.服务器是唯一具有此发布密钥的实体.

客户端

  • 收听全球用户接收频道.这就是大规模服务器广播的方式.无法在此频道上发送(仅限订阅密钥)
  • 在Global-user-send-channel上发送服务器消息.无法接收此频道(只有发布密钥)
  • 收听私人用户频道.这是用户获取私人消息的方式.它也可以用于客户端到客户端的通信.
  • 通过使用存储在服务器上的私有每用户密钥附加所有私有消息来防止滥用,并在初始页面加载期间提供.这样,客户端就知道声称来自服务器的消息是否合法.

C.

如果我们始终生成动态专用通道名称,则存储在数据库表中,每当生成新的动态通道名称时进行更新.我认为这会导致问题,因为一些消息将无法传递,因为新的动态专用通道名称将取代旧的.

如果您在生成新频道名称时要小心,这应该不是问题.请记住,客户总是可以在全球用户发送频道上说'嘿,我在这里!这是我的身份.让我更新'.我通常设计我的应用程序让客户端每隔30秒左右自动喊出这个.

D.

所以,我有很多通知发送到单个频道,如新朋友请求,新私人消息回复,新礼物请求和许多其他类似.如何将所有这些数据发送到频道以及如何查找和解析传入的新通知数据.我知道JSON是要发送的格式,但我不确定发送的格式.

JSON适合发送和接收.我这样做的方法是拥有一个名为"name"的属性,它定义了它的消息类型.例如:

{
    "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" 
             }
}
Run Code Online (Sandbox Code Playgroud)

你实际上可以使用你想要的任何格式,但是当它通过PubNub推送时我们将它包装在JSON中(通常这意味着只包含在引号中).

希望这可以帮助!

新问题

根据此链接,单个Pubnub通道最多只能包含100条消息.这是否意味着如果200个消息一次出现在一个通道中,前100个消息将被传递,剩下的消息是否在队列中?如果10,000条消息一次出现在一个频道上怎么样?所有剩余的消息是否都在队列中?如果是这样,它如何实时传递给订户?

100条消息限制与PubNub.history有关.如果有人订阅了200条消息,他们将收到所有200条消息.

(现在,只有userA应该在他的私人频道上收到有关新私人消息的通知,userB或系统如何找到频道名称UserAx732dsw3efsdfsdfsdf,因为这是一个由userA动态生成的私有频道,系统或用户B都没有访问过同样的事情也发生在userB上,如果userB应该被任何其他实体或系统再次通知,应该有办法找出userB的动态通道名称.

这个问题没有一个通用的解决方案,但我要做的是让服务器在页面加载时生成唯一的id,并在初始HTTP请求时将其呈现给客户端.

另一个问题是,这种情况是,如果用户每次登录到网站时都动态生成频道名称.发送到动态频道的所有消息会发生什么?pubnub是否将所有创建的频道名称保存在其服务器上?

您不必每次都动态生成.你可以....但你也设置了一个具有该唯一ID的cookie,或者从数据库中提取它并在页面加载时将其呈现给客户端(这就是我要做的).我们不保存频道名称.

系统或用户是否有任何方法可以确定某个频道名称是否仍然存在,并且至少有一个用户正在收听该频道?

不是开箱即用,但你可以很容易地实现这一点.只需让您的服务器发送ping并设置您的客户端,以便在他们正在收听时始终响应ping.

现在,UserA在凌晨1:30从网站注销,仍然会向其dynamicChannelA推送通知的许多其他用户会发生什么事情,因为下次UserA登录网站时,UserA将会收听不同的动态频道名称.UserA不会收听他以前的频道dynamicChannelA.

您可以通过服务器定期(每30秒?)ping一次,这可以跟踪用户是否还在那里.在接下来的几个月里,我们将推出一个在线API来自动执行此操作,顺便说一句.

我想使用从数据库表中检索特定用户的频道名称的方法.是否有任何方法或方法可以防止未经授权的频道订阅?因为任何人都可以订阅频道名称,如果他们有订阅密钥和频道名称,无论频道名称有多长.我只是很好奇,因为所有订阅都发生在客户端,订阅密钥和通道名称是可见的

主要方式是策略性地支持发布/订阅密钥.你是对的,任何拥有适当细节的人都可以收听 - 这是仅客户系统的一个大问题.目前,您必须想出创造性的方法来解决它.