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.
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.
Have any one had any success with this across the Windows-Android gap?
Details on what I have tried
So I have been working a bit on this, searching for documentation and examples.
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.
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. This is (similar to) active scanning.
Enter Windows 10
I have been playing with the WiFi Direct Services example project (and others) from Microsoft - but without the big success. Windows is able to see the Android device(s) but
only if the Android device is in Service Discovery mode (i.e. sending out probe requests)
Windows is only able to see the device, not which services it provides.
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).
So, actual question
I am having trouble forming one clear question, sorry, but
Has anybody successfully made a service discovery between Android and Windows?
Does anybody have any insight into how Windows (10) works here? Can I make Windows use the active scanning mode and parse the service announcements?
Other hints that will help on my way is greatly appreciated :-)
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. 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.
The Android API uses service discovery as defined in the Wi-Fi Alliance Wi-Fi Peer-to-Peer (P2P) standard. This is a form of service discovery that predates P2Ps. It uses ANQP/GAS frames with the type Bonjour or UPnP.
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").
Windows sample: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/WiFiDirect
Android sample: https://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html
I have done this using an Apple Bonjour server running on the Windows side (Bonjour == Apple's implementation of Zero Configuration Networking).
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. 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.
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
Related
Good afternoon, I'm developing a system with a pair of Hololensv2 and an android smartphone using Unity.
In my system the smartphone should send some data to the hololens, more precisely I'm trying to send the location data (GPS) cause in the hololens there's not that specific sensor.
I developed a full functioning UDP solution already, but now I need to build a network free one to be able to use everything outdoor.
The first possibility that came to my mind was to use Bluetooth, connect the 2 devices a send from the smartphone a message to the hololens.
Following this project on GitHub: https://github.com/FlipWebApps/HololensGPS i managed to build a theoretically working Bluetooth receiver on the headset, the problem is that it is a beacon receiver and not all the smartphone can be set as beacons.
Moreover, on Unity, I can't use directly Bluetooth directives but I need to pass through a plugin. I tried 2 already without good results:
https://assetstore.unity.com/packages/tools/integration/ibeacon-15260
https://assetstore.unity.com/packages/tools/network/bluetooth-networking-for-ios-tvos-and-android-124274
While with the first one I didn't get anywhere, with the second one I managed to find, without being able to connect to it, the hololens Bluetooth.
I really feel like I'm missing something...
I don't even know which option would be better between trying to connect the 2 devices directly or to keep trying to set the smartphone as a beacon and the hololens as a receiver...
Any idea/suggestion would be highly appreciated... Thank you all.
It really depends on the type of communication needed across devices, but since your networked version is UDP a one-way broadcast should work. If the Android device is broadcasting a value then the Hololens can just listen, and it should not matter if you have 2 or 200 of them. The trick is that none are 'connected' to the broadcaster, they are just observing.
You would only need to connect the two Hololenses to each other if they provide dependent services. In that case you might consider setting the Android as a WiFi host which would have greater range and is already coded ;)
If there is no need for that level of range or complexity, the Beacon protocol can act like UDP. As Beacons are Bluetooth Low Energy (BLE) you would need to set the Hololens to Observer mode so that it will listen but not connect. A very good explanation on how to do that with BLE on a Pi is here.
I was in the same situation as you, and I solved it using UDP. You need to have two phones, however, since Android phones (and I imagine iOS devices as well) do not make themselves a part of their own WiFi hotspot for security reasons. You have one phone acting as the switch, with its WiFi hotspot enabled. Your second phone connects to that hotspot, and broadcasts its GPS location over UDP. Your Hololens also connects to the same hotspot, and can then receive the UDP messages. All using Unity code, without the need for native Bluetooth plugins.
I haven't been able to find any resources regarding this, so I thought I'd ask here.
I have an iOS app that I am developing, as well as a C# desktop app. I'm currently able to connect the two by creating a Socket Server on the desktop app, and connecting from the iOS app. This works well, but I'd like to do this without requiring the devices being on the same network. Communicating via Usb (lightning port) seems like the logical choice, but I can't find any resources at all about how to do this. Are there any tools or best practices regarding this, or is this even possible?
Thanks!
Peertalk, an open source library allowing to pass TCP connections through the USB connection without being part of the MFI program. PeerTalk uses the iTunes usbmux system to relay TCP connections across the iOS USB connection.
I wasn't able to use Peertalk, since I'm using Xamarin for my project. However, I spent the last week researching and documenting what I learned, and I posted it as a blog post here
http://thecodewash.blogspot.com/2017/05/communicating-with-your-ios-app-over.html
Hopefully this helps others.
I want to allow my IoT device to receive a connection from a remote client without the device being connected to a wired network or a Wi-Fi access point. Bluetooth would be an obvious choice, but my clients might not have Bluetooth.
I thought WiFi Direct might be what I wanted but I see in the release notes for Windows 10 IoT Core build 10586 that
WiFi Direct limitations on IoTCore
1.The IoTCore device has to be the connecting device – it will not work as the advertising device with another device initiating the connection.
This implies that API's like WiFiDirectServiceAdvertiser are out and leaves me wondering what other options there are. If I want to do Wi-Fi it seems that I'll have to try to set up a non-WiFi Direct ad hoc Wi-Fi network. I can't find a .Net UWP API to do this (WiFiAdapter seems to only facilitate connecting to networks that can be scanned for). Is there a way of achieving what I want, perhaps using a non-.Net API that is available on Windows 10 IoT Core?
I'm a noob at Windows 10 IoT, but I have the same need.
I did notice that there's a way to onboard a device using the IoT dashboard, which seems to connect your computer to the device via wifi in order to then join the device to a network.
So possibly there are some API's that can do a similar thing?
I want to create a client and a server program using WCF. The communication between them will be TCP. The client will be a windows form where one can insert the host name and then it will list all the servers running on that machine.
Is there a way to do this? I.e. to browse all the WCF services in the machine host?
WCF Discovery - http://msdn.microsoft.com/en-us/library/dd456782.aspx
Windows Communication Foundation (WCF) provides support to enable services to be discoverable at runtime in an interoperable way using the WS-Discovery protocol. WCF services can announce their availability to the network using a multicast message or to a discovery proxy server. Client applications can search the network or a discovery proxy server to find services that meet a set of criteria.
How to: Programmatically Add Discoverability to a WCF Service and Client - http://msdn.microsoft.com/en-us/library/dd456783.aspx
There's no automatic way to do this. There have been various directory service protocols over the years but they've never really taken off. The one that has had most success overall is known as Multicast DNS or zeroconf. However the Windows APIs don't support it very well. Apple supports it under the name Bonjour and Linux supports it under the name Avahi.
The closest Windows equivalent is UPnP SSDP but after some well publicized security vulnerabilities were found, Microsoft dropped support for it by and large. There was an IPv6 rough equivalent known as PNRP (Peer Name Resolution Protocol) but this has also largely fallen out of use.
So, really your choices are to find an mDns library for Windows or to write your own.
I'm working on a project where a program running on the mobile phone needs to communicate with a program running on the PC it's connected to. Ideally, I'd like to use USB, WiFi, whatever to communicate.
The two programs should be able to communicate things like battery life, text messages, etc... But I can work on that later, I just need to get them to talk.
What's the best way to do this?
Assuming you have a wifi connection, one way for your Windows Mobile program to communicate with your PC would be to use WCF on the .NET compact framework 3.5.
You'd create a new WCF application to run you your PC, and expose an interface exposing functions you want to call from your Windows Mobile Device.
WCF on Windows Mobile requires Compact Framework 3.5 to be installed on your device.
You also need the "Windows Mobile power toys" to be able to generate compatible proxies to call from Windows mobile.
Power Toys for .NET Compact Framework 3.5
Calling the WCF service from your WM Device also requires you to manually set up the binding and endpoint to pass into your web service proxy (with desktop WCF this is done automatically by loading them from a config file).
WCF on Windows Mobile currently only supports the basic http binding (which can be encrypted if you want), but this may be enough for your needs.
"Best" is really subjective and highly dependent on a lot of factors like devices, topology, firewall presence, need for security, etc, etc.
Where do you need the comms to originate and will you have an ActiveSync connection? If the PC initiates the comms and you have ActiveSync, then RAPI is the transport you'd use as it's got all of the infrastructure done and ready.
For anything else you're going to need some form of proprietary protocol and transport mechanism. Typically I write a simple socket protocol with a defined message structure (typically a message ID, CRC, message length and data payload). I then have some base message class that handles the comms and a set of derived messages for each specific command I want. For 2-way stuff that requires a response, I typically create a base Response class and then derive specific response formats from it.
You might try looking into the OpeNETCF.Desktop.Communications library. You can start at http://www.opennetcf.com/FreeSoftware/tabid/84/Default.aspx and follow the links to find the necessary downloads. (I think you may need to get it from their subversion repository).
WIMO is working on WiFi to desktop support and may be done. Might be worth a look at the code either way.
home
source
found this in 2015, so I don't think the answer is going to be relevant for the original asker, but for the record:
Proximity
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh465205.aspx