8

我试图想出在一个简单的游戏中进行一些随机匹配的最佳方法。

在使用 Adob​​e Cirrus 试验 netStreams 时，我可以使用 Cirrus 轻松设置直接连接、发送数据、文本、视频、声音，这一切都很棒。我发现建立一个简单的 P2P 连接很容易，而且它就像我需要的那样工作。

但我真的很想实现一个仅使用 cirrus 的随机匹配功能，所以一切都是 p2p ......

我将如何去抓住同一组中的随机同伴......这与其他人没有直接联系？

一些想法：

-我在想也许我可以使用对象复制......当有人连接到 GroupSpecifier 时，我可以将另一个对象推送到这个具有本地 peerID 及其状态的共享数组中。然后我可以在他们在游戏中时更改数组。但是我担心如果此人只是关闭网络窗口，则无法保证他们的条目会被删除。

-我还考虑过只在包含nearID的组中发布“帖子”，其他同伴可以得到帖子……那些不在游戏中的人会尝试直接连接回来。然后那一侧将连接到它们。因此，它们将彼此直接连接。但后来我觉得如果可能有 100 多个“可用”的人......得到这个帖子......然后他们都尝试连接到一个人，那么它可能会导致问题。

-另外，我想过只做 sendToNearest ......但这不是匹配人的最佳方式......因为我认为你只能有这么多邻居......如果组中有 1000 人。您只能连接到实际上认为是您的邻居的几个对等方，对吗？然后基本上你可能最终只匹配相同的 5-10 人，或者在技术上被认为是邻居。

4

1 回答 1

1

我认为在匹配节点时没有任何方法可以避免超时和重试，因为 1）存在未知且可变的网络延迟，以及 2）连接可能在未知时间加入和离开。

因此，任何尝试连接到另一个节点的节点都必须保留以下有状态参数：

  • 我与另一个节点匹配
  • 我有一个未完成的比赛请求
    • 我未完成的比赛请求是节点 X

如果前两个中的任何一个为真，它必须拒绝传入的匹配请求（除非传入的请求来自节点 X，并且我对同一节点有未完成的请求）。如果两者都为假，它可能只会请求匹配。

此外，一旦匹配，他们可能需要轮询他们的伙伴或观察断开消息并做出适当的响应（返回匹配阶段或退出，无论应用程序需要什么）。

在这种情况下，您至少可以通过创建一种排序算法来减少同步节点所需的网络流量，以便所有节点提前知道他们的最佳匹配是谁，并尝试使用最小的网络流量（没有广播发布消息，不是随机尝试）。

关键是 peerID，NetGroup 中的每个节点都会自动获取它。当一个节点收到一个 NeighborConnect 消息时，它还包含邻居节点的唯一 peerID。换句话说，每个节点都有一个唯一的名称（这恰好是一个很大的随机数）并且知道所有其他节点的唯一名称。

这个 peerID 很长，大概是 256 位。您可以使用它创建一个排序顺序——可能类似于：将前 32 位视为一个 int，将远程节点 peerID 与您自己的 peerID 进行异或，然后将远程节点从最低到最高排序。

所以现在每个节点对于他们将要连接到谁都有大致相同的想法（即使会有差异，例如，基于通过组传播的断开/连接消息）。节点将遍历排序列表尝试连接到它们的最佳匹配，可能在失败的连接尝试之间有一些随机超时。

这可能不是理想的解决方案 - 可能存在更好的解决方案，但我认为它比随机尝试节点或使用广播消息要好。

于 2012-04-17T19:11:27.620 回答