0

我的聊天应用程序的主要用例是一位代理通常会与一位客人交谈。最多我计划支持低个位数的客人和代理，但使用这样的功能会非常少。更重要的是，发送者不需要接收他们自己的消息，因为 HTTP 状态会确认收到消息。

我正在考虑将 PubNub 用于“仅推送”。因此，每个客户端将通过 HTTP (PUT/POST) 向应用程序 Web 服务器发送消息，并且仅通过其自己的 PubNub 订阅通道接收消息。

当 Web 服务器应用程序接收到 HTTP 聊天消息时，它会映射消息发送到的客户端并将消息发布到这些特定客户端的通道。所以一个循环调用PubNub.publish(client_channel_id, the_message).

这样，每个客户端必须只订阅一个通道而不是多个通道，并且每个客户端只接收为其指定的消息（即没有全局通道，也没有客户端过滤）。

（我也在考虑使用 Redis 来保存哪些客户端在哪些房间聊天的地图。因此，每次 Web 应用程序收到聊天消息时，它可能（使用本地缓存）必须首先签入 Redis 以映射消息的目的地渠道...）

潜在问题

  • 在服务器范围内使用单个 PubNub 连接可能无法很好地扩展。连接池可能会更好。由于我们只是广播这些连接而不是订阅，所以它应该很简单，对吧？

你能看到这个设计的任何其他潜在问题吗？其他的建议？

4

1 回答 1

0

您在此处描述的方法非常适合安全地创建聊天应用程序。我建议为每个用户会话创建一个随机生成的通道，以提供额外的安全性，而不是使用诸如user_id_1234 之类的通道。每次用户登录时，都会生成一个新的频道名称，例如：YTM0NZomIzI2OTsmIzM0NTueYQ，并让经过身份验证的用户连接到该频道。因此，在 Redis 中，您将拥有一个与用户对象关联的简单键/值。可能是一个带有关键字段pubnub_channel的 HKEY，它会更新每个新的会话 ID。 http://redis.io/commands/hset

于 2012-05-29T03:37:53.660 回答