发现 WiFi Direct 服务 - Windows <=> Android

Question

长话短说

我正在尝试使用 WiFi 直接服务从 Windows 10 计算机发现（Android）设备 - 但在我看来，Windows 和 Android 不同意此处的标准。

当我编写 Wifi Direct Services 或 Wifi Direct Advertisement 时，我指的是具有 WiFi Direct 功能的设备可以广播它提供的服务的功能，因此潜在的同行可以在建立任何连接之前扫描可用的设备/服务。

有没有人在 Windows-Android 差距上取得任何成功？

所以我一直在这方面工作，搜索文档和示例。

使用这个适用于 Android 的服务发现示例，我已经成功地让两个 Android 设备在进行任何实际的 WiFi 直连连接之前找到彼此并列出它们的可用服务。

它的工作方式是，想要查找其他设备（服务）的设备将广播探测请求。发布服务的设备随后将看到这些探测请求并以探测应答进行响应。探测答案包括通知第一设备有关可用服务的 Bonjour（类似）信息。这是（类似于）主动扫描。

我一直在使用Microsoft的WiFi Direct Services示例项目（和其他项目）——但没有取得巨大成功。Windows 能够看到 Android 设备，但

基本上我的结论（有点猜测）是 Windows 10 使用被动扫描，因此（错误地？）对 Android 设备的探测请求做出反应（当 Windows 应该实际发送探测请求本身并对探测响应做出反应时）。

我很难形成一个明确的问题，抱歉，但是

Answer 1

仅供发现此问题的任何人参考，您链接的 Windows API 使用名为Wi-Fi 对等服务 (P2P) 的Wi-Fi 联盟标准，用于探测请求和响应中的服务发现。当探测请求帧中包含匹配的哈希值时，将通过探测响应帧通告和发现服务。还可以通过 P2P 类型的 ANQP/GAS 帧发现服务。

Android API 使用 Wi-Fi 联盟Wi-Fi 点对点 (P2P)标准中定义的服务发现。这是一种早于 P2P 的服务发现形式。它使用 Bonjour 或 UPnP 类型的 ANQP/GAS 帧。

这两种方法都是有效的并且基于标准，但它们彼此不兼容。您（可能）最接近兼容性的方法是使用 Wi-Fi Direct 并且不使用服务发现（您基本上只能在发现时看到设备名称，而不是“服务”）。