NOTICE: This content was originally posted to Google+, then imported here. Some formatting may be lost, links may be dead, and images may be missing.
Seems the situation has broken even more than before. A poster-child case why developing apps for Android is a frustrating affair at the best of times.
If you're a dev working with these sorts things, you might want to give it a read.
Chainfire - Google+ - (dev) Android, Datagrams (UDP), Broadcast, and Multicast…
Here's the weird thing about that.
I wanted to make a TCL/Tk app which would simulate what the Roku Android app does. There is a writeup on their page here about how to control a Roku: http://sdkdocs.roku.com/display/sdkdoc/External+Control+Guide If you notice, the first thing a controller is supposed to do is use SSDP, which is of course multicast in nature. I tried doing what they suggested on that page, setting up a text file to use with netcat, and having Wireshark standing by to see any replies (which incidentally, I don't know why not, they never came). So, seeing this was wrong, I logged into my switch and turned on VLAN mirroring to the workstation with Wireshark running, and fired up the official Roku app on my nakasi KOT49H Nexus 7.
So when the app started up, what did I see? approximately 150 ARP requests, one for each address on my /24 LAN. Yes, I also saw it squirt out 2 SSDP packets. Then for each host it managed to find, it tried a TCP connection to port 8060. It might have stopped at 150 when it managed to connect to my Roku at ".60". But it's almost as if it (or the OS) decided to implement a multicast as unicasts to each host on the network.
It was very strange indeed...especially since the Roku never replied. I wish I could see Roku's sources for the app.
+Chainfire this post showed up in Google now for me. Under "update to website you recently visited".
There Is Another New Update For The Super Su 1.85 To 1.86
You Should Take A Look And Thanks For Posting The Last Update