Nearby Connections 2.0：混合不同的策略？
Nearby Connections 2.0: Mixing different strategies?
我一直在试验新的 Android Nearby Connections v2.0 API，并且对用于广告和发现的连接策略有一些疑问。这些问题涉及奇怪的边缘情况，可能不容易回答。但是，当我在另一个 post 的评论中提到这些潜在问题时，Nearby Connections 开发人员要求我针对这些问题创建一个单独的问题。这个问题涉及我想到的一些奇怪的（但有些不自然的）边缘情况（但是普通开发人员做普通事情不太可能遇到）。
The documentation 包含这个有点模棱两可的声明："Nearby Connections supports different Strategies for advertising and discovery." 最初，我将其解释为意味着我们可以 select 两种可用的连接策略之一，并将其用于两个广告和发现。由于连接策略定义了特定节点的（本地）连接拓扑，因此我们需要对广告和发现使用相同的连接策略是有道理的。
然而，人们也可以将模棱两可的陈述解释为可以（从字面上）使用不同的策略进行广告和发现。这看起来很荒谬，但似乎没有任何机制可以真正强制策略相同。由于 startAdvertising() 和 startDiscovery() 都采用 "strategy" 参数，因此很有可能向每个参数传递不同的策略。
注意：我已经通过实验找到了上述问题的答案。如果广告商和发现者使用不匹配的策略，则永远不会到达发现者的 onEndpointFound 回调（所以我猜较低级别的代码必须意识到存在不匹配并且永远不会发送它）。
另一个问题：异构网络（混合策略）是否可能？由于连接策略会影响两个连接节点之间使用的通信方式（P2P_CLUSTER 使用低带宽进行小数据传输，P2P_STAR 同时使用蓝牙和 Wifi 热点进行更高带宽），这似乎是为了对于要连接的两个节点，两者都需要使用相同的策略。
如前所述，实验表明两个节点确实需要使用相同的策略才能连接。但是，我可以想象另一种边缘情况，其中设备 A 使用 "Cluster" 策略连接到设备 B，切换策略（同时保持连接打开），并使用 "Star" 策略连接到设备 C。这行得通吗？我不知道。由于我当前的测试程序在配置更改后重新启动，因此我需要编写新代码来测试这种边缘情况（而且我还有很多我宁愿编写的其他代码）。但是 Nearby Connections 开发人员有兴趣了解潜在的边缘情况，所以我在这里提到这一点。
这些问题是在我尝试调试其他连接问题时出现的。为了使我的实验程序更加通用，我为连接策略添加了一个设置选项，另一个设置选项控制程序是应该只做广告，还是只做发现，或者两者兼而有之。然后我必须决定当这些设置改变时会发生什么。
仅停止 advertising/discovery 然后使用请求的策略重新启动指定的内容是否就足够了？但是，如果先前策略遗留下来的任何现有连接会发生什么情况呢？这个答案似乎并不明显。
也许这些问题只会出现在像我的测试程序这样的人为场景中（我写它只是因为我试图了解其他连接问题）。在最终产品中，我可能只会选择一种策略并始终如一地使用它。如果 Nearby Connections 是开源的，我只会查看该代码以了解在这些奇怪的边缘情况下可能会发生什么。但是由于我无法查看源代码，所以很高兴看到更多关于预期行为的文档
是的，您回答了自己的问题。您必须在广告商和发现者方面匹配策略。不然你永远也发现不了广告机
至于在流程中间切换策略，这是明确不允许的。当您开始广告/开始发现时您仍然与以前的策略有联系时，您会收到错误消息。
我一直在试验新的 Android Nearby Connections v2.0 API，并且对用于广告和发现的连接策略有一些疑问。这些问题涉及奇怪的边缘情况，可能不容易回答。但是，当我在另一个 post 的评论中提到这些潜在问题时，Nearby Connections 开发人员要求我针对这些问题创建一个单独的问题。这个问题涉及我想到的一些奇怪的（但有些不自然的）边缘情况（但是普通开发人员做普通事情不太可能遇到）。
The documentation 包含这个有点模棱两可的声明："Nearby Connections supports different Strategies for advertising and discovery." 最初，我将其解释为意味着我们可以 select 两种可用的连接策略之一，并将其用于两个广告和发现。由于连接策略定义了特定节点的（本地）连接拓扑，因此我们需要对广告和发现使用相同的连接策略是有道理的。
然而，人们也可以将模棱两可的陈述解释为可以（从字面上）使用不同的策略进行广告和发现。这看起来很荒谬，但似乎没有任何机制可以真正强制策略相同。由于 startAdvertising() 和 startDiscovery() 都采用 "strategy" 参数，因此很有可能向每个参数传递不同的策略。
注意：我已经通过实验找到了上述问题的答案。如果广告商和发现者使用不匹配的策略，则永远不会到达发现者的 onEndpointFound 回调（所以我猜较低级别的代码必须意识到存在不匹配并且永远不会发送它）。
另一个问题：异构网络（混合策略）是否可能？由于连接策略会影响两个连接节点之间使用的通信方式（P2P_CLUSTER 使用低带宽进行小数据传输，P2P_STAR 同时使用蓝牙和 Wifi 热点进行更高带宽），这似乎是为了对于要连接的两个节点，两者都需要使用相同的策略。
如前所述，实验表明两个节点确实需要使用相同的策略才能连接。但是，我可以想象另一种边缘情况，其中设备 A 使用 "Cluster" 策略连接到设备 B，切换策略（同时保持连接打开），并使用 "Star" 策略连接到设备 C。这行得通吗？我不知道。由于我当前的测试程序在配置更改后重新启动，因此我需要编写新代码来测试这种边缘情况（而且我还有很多我宁愿编写的其他代码）。但是 Nearby Connections 开发人员有兴趣了解潜在的边缘情况，所以我在这里提到这一点。
这些问题是在我尝试调试其他连接问题时出现的。为了使我的实验程序更加通用，我为连接策略添加了一个设置选项，另一个设置选项控制程序是应该只做广告，还是只做发现，或者两者兼而有之。然后我必须决定当这些设置改变时会发生什么。
仅停止 advertising/discovery 然后使用请求的策略重新启动指定的内容是否就足够了？但是，如果先前策略遗留下来的任何现有连接会发生什么情况呢？这个答案似乎并不明显。
也许这些问题只会出现在像我的测试程序这样的人为场景中（我写它只是因为我试图了解其他连接问题）。在最终产品中，我可能只会选择一种策略并始终如一地使用它。如果 Nearby Connections 是开源的，我只会查看该代码以了解在这些奇怪的边缘情况下可能会发生什么。但是由于我无法查看源代码，所以很高兴看到更多关于预期行为的文档
是的，您回答了自己的问题。您必须在广告商和发现者方面匹配策略。不然你永远也发现不了广告机
至于在流程中间切换策略，这是明确不允许的。当您开始广告/开始发现时您仍然与以前的策略有联系时，您会收到错误消息。