The Sorry State of Peer-to-Peer iOS-to-Android connectivity(blog.moritzhaarmann.de)
blog.moritzhaarmann.de
The Sorry State of Peer-to-Peer iOS-to-Android connectivity
http://blog.moritzhaarmann.de/blog/2014/04/27/sorry-state-of-p2p/
4 comments
The popular game app "Spaceteam" does an amazing job of real time p2p communication between iOS and Android devices. It would be great if the developer could release some sort of open-source library for those connections so other people could build on his/her work.
Hey! That was our doing. :-) Apportable (Winter 2011) worked to bring Spaceteam over to Android and we had to face this problem head on. Bluetooth LE does work for Android <-> iOS but it requires a really new Android device with the right hardware, otherwise the safest option is Wifi. A lot of code involved. We open sourced the code we wrote to run on the Android side: https://github.com/apportable/Bluetooth
Thanks for the reply, and great work! This is why I love Hacker News.
This is the main area where I suspect Google's greater reliance on clouds leads them to castrate their operating systems. Last time I checked Chrome OS still didn't even support Bonjour mDNS. (Still the case, and it's related to this first mentioned in 2009: https://code.google.com/p/chromium/issues/detail?id=13573 )
The Android stuff alone is an inconsistent trainwreck (because not all hardware supports all options on a given version of the OS either) and it took them a long time to get there.
Apple really have been leading the sane local peer-to-peer world ever since Bonjour first appeared, and the new developments have just extended their lead.
It will be interesting to see just how this difference affects the nature of their respective wearables.
The Android stuff alone is an inconsistent trainwreck (because not all hardware supports all options on a given version of the OS either) and it took them a long time to get there.
Apple really have been leading the sane local peer-to-peer world ever since Bonjour first appeared, and the new developments have just extended their lead.
It will be interesting to see just how this difference affects the nature of their respective wearables.
FWIW Java based mDNS libraries works fine on stock Android. I believe mDNS is the standards body name for the protocol that Bonjour uses.
Zeroconf (Zero Configuration Networking) is the standards body name. mDNS is one of 3 components that Zeroconf uses, the other two being local link addressing and DNS service discovery.
jMDNS works fine on Android but it is a 3rd party dependency you have to add and it is slow to start up.
Android 4.1 started shipping their own native Zeroconf implementation (Network Service Discovery) which kind of works, but is buggy as hell.
jMDNS works fine on Android but it is a 3rd party dependency you have to add and it is slow to start up.
Android 4.1 started shipping their own native Zeroconf implementation (Network Service Discovery) which kind of works, but is buggy as hell.
Yeah, kind of. Now that they've rolled some of it into the OS things are better, but in the bad days before 4.0 you'd get devices hard wired to discard any broadcast or multicast packets while the screen was off and so on. Manufacturers had a distinct tendency to mess with anything not explicitly used in the OS.
Google aren't helped when people like Samsung decide to redefine the bump to file transfer to mean NFC to initiate WiFi Direct, not what everyone else had deployed which was Bluetooth, and without the fallback position of making that work. That's the curious thing with Android, they did in many ways engage in the wider world hoping for a bit more wider co-operation (at least within the OHA), but you'd be hard pressed to find an area of the OS anyone other than Google had a positive impact on, but there is plenty of the reverse going on.
Google aren't helped when people like Samsung decide to redefine the bump to file transfer to mean NFC to initiate WiFi Direct, not what everyone else had deployed which was Bluetooth, and without the fallback position of making that work. That's the curious thing with Android, they did in many ways engage in the wider world hoping for a bit more wider co-operation (at least within the OHA), but you'd be hard pressed to find an area of the OS anyone other than Google had a positive impact on, but there is plenty of the reverse going on.
> but in the bad days before 4.0 you'd get devices hard wired to discard any broadcast or multicast packets while the screen was off and so on.
Shitty networking stacks abound all because everybody is trying to get an edge in battery life.
Shitty networking stacks abound all because everybody is trying to get an edge in battery life.
> Apple really have been leading the sane local peer-to-peer world ever since Bonjour first appeared, and the new developments have just extended their lead.
It's not hard to be a 'leader' when there's only 5 or so products to communicate with.
Clearly they don't support anything other than this, and so calling it a 'lead' is hilarious when you have to have everyone you might want to communicate with buy the same product as you.
What rot.
It's not hard to be a 'leader' when there's only 5 or so products to communicate with.
Clearly they don't support anything other than this, and so calling it a 'lead' is hilarious when you have to have everyone you might want to communicate with buy the same product as you.
What rot.
My Android immediately becomes the remote control of my Sonos system whenever I approach my house, so it seems to me that Android's network service discovery is adequate for at least some purposes, whether it uses mDNS or not (I'm pretty sure Sonos uses multicast HTTP, FWIW.)
Android doesn't resolve names like machinename.local though. At least not for me - I hit this problem on a Nexus 7 just this weekend. I ended up putting the IP address in. Perhaps it is application specific, though name resolution seems like something that'd be baked in at a lower level than that. Anyway I tried in Firefox where it attempted to resolve www.machinename.local, and also a VNC application which just timed out.
I imagine that allowing multicast resolution system-wide is fraught with security problems, and most Android phones are whored out to random wifi networks all over the world.
Last time I checked iOS still lacks a TAP device.
Castration indeed.
Castration indeed.
I'm guessing the downvoters have no clue what TAP is or why it is relevant to peer-to-peer.
Either that or they just think this is some critique of their beloved Apple.
I'm referring to the TUN/TAP driver.
All BSD's have it (/dev/tap).
And to easily do encapsulation, which is very handy for VPNs and peer-to-peer, you need it.
OSX has it. iOS does not.
So, downvoters, why is TAP missing from iOS?
Why is iOS crippled? Or "castrated" to use the parent's terminology.
I've got peer-to-peer that relies on TAP. Not a problem with any BSD or Linux or even OSX.
The exception is iOS. Why?
Either that or they just think this is some critique of their beloved Apple.
I'm referring to the TUN/TAP driver.
All BSD's have it (/dev/tap).
And to easily do encapsulation, which is very handy for VPNs and peer-to-peer, you need it.
OSX has it. iOS does not.
So, downvoters, why is TAP missing from iOS?
Why is iOS crippled? Or "castrated" to use the parent's terminology.
I've got peer-to-peer that relies on TAP. Not a problem with any BSD or Linux or even OSX.
The exception is iOS. Why?
WebRTC works pretty well on Android.
But apparently Apple has kept it out of iOS Safari and doesn't allow other browsers to implement it?
But apparently Apple has kept it out of iOS Safari and doesn't allow other browsers to implement it?
As far as I am aware, Apple does not seem to have a policy preventing this type of work. There was a fairly well-publicized release of an experimental codebase from Ericsson:
http://labs.ericsson.com/apps/bowser,
which has since been retired (although as far as I know, not due to any conflict with Apple):
http://labs.ericsson.com/blog/retiring-bowser.
http://labs.ericsson.com/apps/bowser,
which has since been retired (although as far as I know, not due to any conflict with Apple):
http://labs.ericsson.com/blog/retiring-bowser.
Apple needs to allow serious browser competition on iOS. But of course they won't until more developers and users start asking them for it.
Forgot about that one, thank you. Another one on the list, unfortunately.
WebRTC does not currently exist on the desktop Safari either. I'm sure if a 3rd party wanted to implement WebRTC in a browser for iOS, they are probably welcome to do so.
That's a different layer - it runs on top of an already established network. This is about establishing some kind of connection.
WebRTC also requires a central server for discovery (typically overy HTTP I think?). It maybe possible to replace that with Bluetooth LE, but then the WebRTC connections to each other will need to run over an TCP network.
WebRTC also requires a central server for discovery (typically overy HTTP I think?). It maybe possible to replace that with Bluetooth LE, but then the WebRTC connections to each other will need to run over an TCP network.
This ongoing attempt by Apple to hobble iOS is why I've decided that my next device would be an Android device. I'll have access to filesystem, I can run an SSH server on my phone which means I basically can do pretty much everything I need to spend less time "managing" my content without having to buy into an whole eco system of Apple devices. E.g. i can push new music files automatically to my phone via a script), access newer photos/videos taken on my phone on various trips and sync them back to my computer (without having to rely on cloud etc).