Chromecast v2 devices announce their presence using mDNS, and they are discoverable when performing mDNS queries for _googlecast._tcp.
DNS-SD / Bonjour also support the concept of "wide-area discovery", which makes use of standard unicast DNS queries to find devices. This can be useful for more complex networking scenarios - i.e your Chromecast devices may be in one VLAN but your sender devices are in another.
However, when trawling Chromium source I found this code in mdns_api.cc which seems to indicate that the Chrome extension will only search for _googlecast._tcp.local - completely preventing wide-area DNS discovery of other Chromecast devices. Based on anecdotal testing, it seems the Chromecast iOS app and SDK also have this behaviour.
Why does the official discovery mechanism for the Chromecast Chrome extension explicitly only discover link-local Chromecast devices?
They probably didn't do "wide-area discovery" because there are a lot of gotchas in implementing it and there isn't much gain to be had.
Let's suppose that they did implement it (from looking at the spec, it doesn't seem to be technically difficult; seems like it is mostly an edge-case problem).
You'd need:
A domain under your control. Could be a local-only domain.
Not many people do this.
Multiple VLANs that you want to use.
Most homes only have a single VLAN.
A DNS-SD server that supports Wide-Area Discovery.
This is probably the easiest thing to have. Even then, most people wouldn't do it.
A UX flow to input the various WAD servers that you want to ping for devices.
This is the hard part for Google since it needs to be consistent across all SDKs and using a WAD-discovered Chromecast would cause all local-media-server Apps to not work (e.g. Plex).
(1) - (3) are why Google wouldn't make this a priority. Chromecast is, after all, a consumer device and consumers tend to have simple networking situations. (4) is why it isn't low-hanging fruit.
You'd also need to solve a few problems:
What happens when you are connected to a Chromecast on a separate VLAN and then remove it's WAD server?
What if the WAD server goes offline?
What happens when you have multiple Chromecasts with the same name?
What if they also have the same IP address (possible since VLANs can have overlapping IP spaces)?
What happens when a Chromecast is discoverable using WAD but not reachable?
Should they attempt a connection to every single Chromecast you discover to test that it is reachable?
How would you scale this out to work with 100s of Chromecasts in VLANs that could be "far" away?
It is these problems that I think would prevent Google from implementing WAD even if they wanted to.
Related
TASK: I have a task: I need to understand with the help of static network analysis methods which model I am dealing with. I need to try to find out the firmware version, manufacturer, device type. I am interested in solving my problem within the framework of the most popular Internet of Things protocols: LoRaWAN, 6LoRaWAN, Zigbee, Z-Wave.
I found a study Detecting IoT Devices and How They Put Large Heterogeneous Networks at Security Risk that uses ping, nslookup and the web interface of the applications themselves. They had a whole huge network of real smart devices at their disposal. I do not have the opportunity to assemble my experimental stand from real devices. What should I do in this situation?
PROBLEM: How can I emulate the operation of devices, so that later I can communicate with them over the network as with real ones.
Anyone has used DNS-SD to discover the presence of HoloLens' Device Portal on the local network? Though docs claim it does advertise itself, I have found this very unstable and discovery is very random. It does show up for a while and then disappears for hours. Anyone can suggest a reliable way I can detect the presence of HoloLens on my local network?
Looks like HoloLens is not very keen to respond to IPv4 broadcasts; it does, but it'd better not respond at all than respond randomly making it look like it works, when it doesn't. Fortunately it is pretty reliable in responding to IPv6 broadcasts and the response actually includes it's both IPv4 and IPv6 addresses, which solves my problem. Make sure that DNS-SD (MDNS) library you're using supports IPv6.
I use apps that interact with their specific devices. An example is Roku. The device is Roku and I use their Android App. Another is my Denon Audio receiver and it too has an app to control it. I'm looking to write app/hardware service. how does an app detect device on network and vice-versa?
Disclaimer: I don't know what Roku is but what you are describing sounds like service discovery as part of zeroconf.
One relatively known example is DNS-SD. You can think of it as sending periodically multicast UDP messages containing stuff such as "I am at address X and I provide service Y" to some well-known address. Whoever is interested will pick up the information associated.
I want to develop a FirefoxOS privileged app that can send text messages to nearby devices.
Android app can use Bluetooth or Wifi P2P. But FirefoxOS privileged apps cannot use Bluetooth/Wifi API. These are only available for certified apps.
Privileged apps can use TCP socket API. Is this the only way?
Is there any way to get available IP addresses on LAN?
#Kazhik, unfortunately right now, that is the only way to go. And the explanation for that is that by using the socket API you can implement any protocol on top of TCP, such as IMAP, IRC, POP, HTTP, etc., or even build your own to sustain any specific needs you could have.
Since certified apps can only be included by the oem, access to Bluetooth or WiFi information API aren't a viable option now.
At today's date (September 18, 2015) the WebIDE supports installing certified apps in older Firefox OS versions like 1.3 and in physical devices.
I tried installing the Gaia test apps (these are certified) in one Alcatel OT FireC and everything worked perfectly fine ;)
DNS-SD (part of the Zeroconf specification) allows you to broadcast and receive "advertisements" from other devices on the local network. That requires UDP and TCP permissions, which means a "privileged" app, as you thought. That's not a problem, unless you need to distribute the app outside of the Firefox Marketplace.
There's an implementation of DNS-SD for JavaScript at https://github.com/justindarc/dns-sd.js
For compatibility with other messaging apps, you might want to implement XMPP:
http://www.xmpp.org/extensions/xep-0174.html
I am Developing a Java ME Application. Here I am using WiFi Connection. Now My Question is how to get a particular WiFi Connections name using Java ME Code ?
My Requirement is for Nokia E5 Device only.
After doing much research work I found that this is not possible in Java ME Technology to fetch the WiFi Connection's Name.
However Similar Library would be com.nokia.multisim.networkid which returns Network ID and Network Short Name.
I Dont Think so it is 100% possible in J2ME and even though if it has worked and there is no guarantee that it will work on all J2ME devices which has Wifi connectivity.
most appropriate answer i have found , please go through it once.
" Much as I hate to put you through all that grief and then not have a simple answer, I don't have a simple answer.
The reason for that is because Java's networking model is based on TCP/IP, and the TCP/IP architecture is based on the idea that applications will neither know nor care about the hardware details of networking. A typical mobile device may contain several different network interfaces (WiFi, Bluetooth, Infrared, USB cable, and so forth), but when an app wants to contact another network node, the app doesn't know which of these interfaces is actually being used. And in fact, if the OS wants to do so, it can use more than one (in parallel) and/or switch interfaces in and out, based on routing criteria such as best measured data rates. Rather like how cell phones route phone calls.
So basic Java/JME won't know anything about WiFi.
However, there is an extension, specified as JSR 309 (http://jsp.org) that looks like it may help. It supports learning about and controlling the network interfaces themselves. The problem is that not all devices will implement this extension, so it will depend on what device(s) you are supporting. "