Question

需要

我有以下情况：

~10万名球员
50位管理员

每个玩家可以与每个管理员进行1：1的对话;在不同的对话中，玩家甚至可以与所有管理员进行1：1的对话。

但是，在任何时候，其中一个对话的管理员可能会邀请另一个（或许多）管理员进入这些数千个对话中的一个。

其他：

使用default:always
使用resend_on_timeout:true进行流管理。
玩家无法向其他玩家发送消息

实施例

假设玩家1有3个有效的单独对话P1:Admin A, P1:Admin G, P1:Admin H
然后，管理员A邀请管理员H进入P1:Admin A对话（管理员H被邀请进入管理员A的对话不会关闭有效的P1:Admin H对话），然后播放器将进行这些有效的对话：
- P1:Admin A + Admin H，P1:Admin G，P1:Admin H

解决方案＃1：Muc Rooms

我正在考虑将所有对话转换为私人不可发现的MUC会议室（当用户想要与管理员聊天时，客户端将发出一个自定义智能，即我将使用的ejabberd模块开发将处理和创建房间，将播放器和管理员自动列入这个新房间。）

对于可能意味着500万MUC房间的示例场景。我知道500万普通聊天是常见的情况，但是有这么多房间可以吗？

解决方案＃2：XEP-0033扩展Stanza寻址

对于这个解决方案，我正在考虑将消息识别为具有扩展元素channel的房间的一部分。通过这种方式，收件人可以进入并进行对话。

但是这没有MUC房间的安全控制，只有白名单的用户可以在频道中进行通话。有没有办法用这种方法克服这种隐私？

使用channel元素的示例：

P1：管理员A +管理员B，房间1

<message to='header.org' from='player1'>
   <addresses xmlns='http://jabber.org/protocol/address'>
     <address type='to'  jid='adminA'/>
     <address type='to'  jid='adminB'/>
   </addresses>
   <channel xmlns='chanel:namespace' id='1'>
   <body>Hi admin A and admin B!</body>
</message>

管理员B，P1：管理员A，仍然是房间1

<message to='header.org' from='player1'>
   <addresses xmlns='http://jabber.org/protocol/address'>
     <address type='to'  jid='adminA'/>
   </addresses>
   <channel xmlns='chanel:namespace' id='1'>
   <body>Hi admin A only on the same room!</body>
</message>

最终解决方案？

考虑到客户端和服务器定制不是问题...... 考虑到所有要求，哪种解决方案最好？还是有其他最佳解决方案吗？

Answer 1

我有类似的设置，这就是我接近它的方式：会话以1：1聊天开始，因为大多数会一直是1：1，但如果管理员想要邀请其他管理员或甚至是其他用户，我将聊天转换为MUC会议as described in XEP-0045。

这些会议室是hidden and members only，但它们并不持久（在最后一位乘客退出后被销毁）。

如果您打算仅使用自定义客户端，则多播策略（XEP-0033）也可以。如果您使用现有客户，您将无法控制房间。

在ejabberd中有数以百万计的私人MUC房间或动态的XEP-0033对话：什么是最好的？

需要

实施例

解决方案＃1：Muc Rooms

解决方案＃2：XEP-0033扩展Stanza寻址

最终解决方案？

1 个答案: