简体   繁体   English

发现WiFi直接服务 - Windows <=> Android

[英]Discover WiFi Direct Services - Windows <=> Android

Long story short 长话短说

I am trying to discover (Android) devices from a Windows 10 computer, using WiFi Direct Services - but it seems to me that Windows and Android do not agree on the standard here. 我试图使用WiFi直接服务从Windows 10计算机中发现(Android)设备 - 但在我看来,Windows和Android不同意这里的标准。

When I write Wifi Direct Services or Wifi Direct Advertisement, I mean the feature where a WiFi Direct capable devices can broadcast what services it offers, so potential peers can scan for available devices / services before they make any connection. 当我编写Wifi Direct Services或Wifi Direct Advertisement时,我的意思是支持WiFi Direct的设备可以广播它提供的服务,因此潜在的对等方可以在进行任何连接之前扫描可用的设备/服务。

Have any one had any success with this across the Windows-Android gap? 有没有人在Windows-Android差距中取得任何成功?

Details on what I have tried 我试过的细节

So I have been working a bit on this, searching for documentation and examples. 所以我一直在研究这个问题,搜索文档和示例。

Android <-> Android Android < - > Android

Using this Service Discovery example for Android , I have had success with making two Android devices find each-other and list their available service(s) before any actual WiFi Direct connection was made. 使用Android的这个Service Discovery示例 ,我已经成功地让两个Android设备找到彼此,并在任何实际的WiFi Direct连接之前列出他们的可用服务。

The way it works is that a device that want to find other devices (services) will broadcast probe requests. 它的工作方式是想要查找其他设备(服务)的设备将广播探测请求。 A device publishing a service will then see these probe requests and respond with a probe answer. 然后,发布服务的设备将查看这些探测请求并使用探测答案进行响应。 The probe answer include Bonjour(-like) information informing the first device about available services. 探测答案包括Bonjour(类似)信息,通知第一个设备有关可用服务的信息。 This is (similar to) active scanning. 这是(类似于)主动扫描。

Enter Windows 10 进入Windows 10

I have been playing with the WiFi Direct Services example project (and others) from Microsoft - but without the big success. 我一直在玩微软的WiFi Direct Services示例项目(和其他人) - 但没有取得巨大成功。 Windows is able to see the Android device(s) but Windows可以看到Android设备但是

  • only if the Android device is in Service Discovery mode (ie sending out probe requests) 当Android设备处于服务发现模式时(即发送探测请求)
  • Windows is only able to see the device, not which services it provides. Windows只能看到设备, 而不能看到它提供的服务。

Basically my conclusion (a bit of guessing) is that Windows 10 uses passive scanning and thus (erroneously?) reacts to the probe requests of the Android devices (when Windows should actually send out probe requests itself and react to probe responses). 基本上我的结论(有点猜测)是Windows 10使用被动扫描,因此(错误地?)对Android设备的探测请求作出反应(当Windows实际上应该自己发出探测请求并对探测响应做出反应时)。

So, actual question 所以,实际的问题

I am having trouble forming one clear question, sorry, but 我很难形成一个明确的问题,抱歉,但是

  • Has anybody successfully made a service discovery between Android and Windows? 有没有人成功在Android和Windows之间进行服务发现?
  • Does anybody have any insight into how Windows (10) works here? 有没有人对Windows(10)如何在这里工作有任何见解? Can I make Windows use the active scanning mode and parse the service announcements? 我可以让Windows使用主动扫描模式解析服务通告吗?
  • Other hints that will help on my way is greatly appreciated :-) 其他提示将有助于我的方式非常感谢:-)

I have done this using an Apple Bonjour server running on the Windows side (Bonjour == Apple's implementation of Zero Configuration Networking). 我使用在Windows端运行的Apple Bonjour服务器(Bonjour == Apple的零配置网络实现)完成了这项工作。

The catch is that I had to use Mono.Zeroconf library to pull it off http://www.mono-project.com/archived/monozeroconf/ , and it's a little off the well-trod path because the most popular libraries for this on Windows side are client only and do not allow for registration as a service provider. 问题是,我不得不使用Mono.Zeroconf库将其从http://www.mono-project.com/archived/monozeroconf/中删除,并且它有点偏离了良好的路径,因为最受欢迎的库是Windows端只是客户端,不允许注册为服务提供商。 Also, and as an added surprise, the source in this project hadn't been recompiled recently when I found it. 此外,作为一个额外的惊喜,当我找到它时,这个项目的来源最近没有被重新编译。 It works though -- I just had to recompile it to get it working with .Net46. 它工作正常 - 我只需重新编译它以使其与.Net46一起工作。

Anyway, the operative point is that Android's Network Service Discovery is interoperable with ZeroConf as they are both DNS-SD based and I've been quite happy with the results after finding out most android devices don't do MultiCasting 无论如何,操作点是Android的网络服务发现可与ZeroConf互操作,因为它们都是基于DNS-SD的,我发现大多数Android设备不做MultiCasting后我对结果非常满意

Just for some context to anyone finding this question, the Windows API you linked uses a Wi-Fi Alliance standard called Wi-Fi Peer-to-Peer Services (P2Ps) for service discovery in probe requests and responses. 对于发现此问题的任何人来说,只是针对某些情况,您链接的Windows API使用称为Wi-Fi点对点服务(P2P)的Wi-Fi联盟标准,用于探测请求和响应中的服务发现。 A service is advertised and discovered over Probe Response frames when a matching hash is included in a Probe Request frame. 当探测请求帧中包含匹配的散列时,将通过探测响应帧通告和发现服务。 The services may also be discovered over ANQP/GAS frames with the type P2Ps. 也可以在具有P2P类型的ANQP / GAS帧上发现服务。

The Android API uses service discovery as defined in the Wi-Fi Alliance Wi-Fi Peer-to-Peer (P2P) standard. Android API使用Wi-Fi Alliance Wi-Fi Peer-to-Peer(P2P)标准中定义的服务发现。 This is a form of service discovery that predates P2Ps. 这是一种早于P2P的服务发现形式。 It uses ANQP/GAS frames with the type Bonjour or UPnP. 它使用Bonjour或UPnP类型的ANQP / GAS帧。

Both methods are valid and standards based, but they are not compatible with one another. 这两种方法都是有效的,基于标准的,但它们彼此不兼容。 The closest you can (likely) get to compatibility is by using Wi-Fi Direct and no service discovery (you can only see device names essentially at discovery time, rather than a "service"). 您可以(可能)获得兼容性的最接近的是使用Wi-Fi Direct并且没有服务发现(您只能在发现时看到设备名称,而不是“服务”)。

Windows sample: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/WiFiDirect Windows示例: https//github.com/Microsoft/Windows-universal-samples/tree/master/Samples/WiFiDirect

Android sample: https://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html Android示例: https//developer.android.com/training/connect-devices-wirelessly/wifi-direct.html

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM