附近的连接2.0:广告商重新启动，但是Discoverer使用旧的广告商ID进行连接 [英] Nearby Connections 2.0: Advertiser restarts, but Discoverer connects using old Advertiser id

问题描述

我发现了一个有趣的结果

I caught an interesting result

• 广告商将其端点ID"wjys"广告化了
• 发现者请求连接到"wjys"
• 广告商重新启动(stopAllEndpoints，与GoogleApiClient断开连接)
• 广告商发布了新的端点ID"PChU"
• 发现者再次发现广告商(id = PChU)
• 发现者使用旧ID(wjys)进行onConnectionInitiated
• 两个设备都接受
• 令人惊奇的是，即使Discoverer使用旧的Advertiser id(wjys)发送和接收消息，这两个设备仍然可以通信.

此行为是错误吗?

推荐答案

那是一个错误.我已在内部提交票证以解决问题.如果您停止刊登广告，那么看到旧广告的任何人都不应与之建立联系.让我们知道您是否还遇到其他类似的奇怪情况！ :)

That's a bug. I've filed a ticket internally to get it fixed. If you stop advertising, you should not be connectable by anyone who saw the old advertisement. Let us know if you catch any other weird edge cases like this! :)

要了解为什么会发生此错误，以下是有关Connections如何工作的一小部分: 端点ID作为广告的一部分发送，并且在Discoverer端形成id-mac地址对.当Discoverer被告知"requestConnection"时，它将尝试连接到与端点ID关联的Mac地址.如果设备已经停止发布广告，发现者将无法连接，但是发现者将在内部重试几次以确保确定.如果广告商足够快地重新启动广告，则它可以再次变为可连接状态，并且发现者的重试可能会成功(因为Bluetooth mac地址永远不会旋转).即使广告不同，也是这样.

To understand why this bug happens, the following is a small part about how Connections works: The endpoint id is sent as a part of the advertisement, and it forms an id-mac address pair on the Discoverer side. When the Discoverer is told 'requestConnection', it tries to connect to the Mac address associated with the endpoint id. If the device has already stopped advertising, the discoverer will fail to connect, but the discoverer will retry internally a few times just to make sure. If the advertiser restarts advertising quickly enough, it becomes connectable again and the discoverer's retry may succeed (because the Bluetooth mac address never rotates). This is true even if the advertisement is different.

这篇关于附近的连接2.0:广告商重新启动，但是Discoverer使用旧的广告商ID进行连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！