Deep under the Apple's Multi-peer Connectivity Framework
Apple introduces its Multi-peer Connectivity Framework(abbreviated as MC below) in iOS 7. Recently, our team just brought an idea of using it in one of our apps, and as a developer with years of network management experience, by reading through the reference document and playing with code, what really interested me is the technology underneath this MC API/Framework, especially the newly introduced peer-to-peer Wi-Fi, which is suitable for zero-configuration, high-speed data transferring between iOS devices.
Before it, some background on Apple's attempts with peer-to-peer connectivity.
From a historical point of view, the MC is an upgrade over old GameKit(abbreviated as GK below) Framework. As it names, GK is mainly used in games, but Apple decided to put a simple peer-to-peer(p2p) connectivity API in it to ease game data exchanging. With this API, it hides all the dirty network protocol/configuration/hardware from developers, and developers can just request to find a peer, connect to it, and sent the data in just a few steps. No socket programing, no TCP/IP programing, whatever you named it in old days if you try to send data over the network. But, you have to lose something for it. For iOS developers, there is no direct way to activate/deactivate, config the network hardware, network protocol stack in anyway.
Underlying the GK connectivity API, Apple actually puts Wi-Fi and Bluetooth working together, seamlessly. If all peer devices are connected to the same Wi-Fi network, it will just use the Wi-Fi network for peers discovery and data transferring; if they is no Wi-Fi network available, the devices' Bluetooth adapter is activated, creating a virtual TCP/IP(v4) network over Bluetooth(Bluetooth PAN). Actually, our app's first demo is built on GK, and our usage of it is solely to bring up the TCP/IP network. Then, we can play with TCP/IP network and socket communication directly, whatever we want.
Back to MC connectivity, from peer-to-peer to multiple peer, this is obvious an upgrade, and it seems Apple clearly understands this part is of great use, and should no longer be hidden in the GK framework. In fact, there is a whole new session on this topic in 2013's WWDC, and my adventure of it begins there.
From the official reference:
The Multipeer Connectivity framework provides support for discovering services provided by nearby iOS devices using infrastructure Wi-Fi networks, peer-to-peer Wi-Fi, and Bluetooth personal area networks and subsequently communicating with those services by sending message-based data, streaming data, and resources (such as files).
As mentioned above, we are already quite familiar with Wi-Fi network and Bluetooth PAN in GK, and MC and GK have quite a similar design, but what is the role of peer-to-peer Wi-Fi here?
First, let's test the transfer speed with GK/MC using different combinations of network devices, and see if there is any hint of peer-to-peer Wi-Fi.
Device A: iPad 4, iOS 7.0.4
Device B: iPhone 5s, iOS 7.0.4
Test steps: using GK to create an active session, once the opposite peer connected, send 1MB data to it, timing the transfer and then we got the speed; repeat these steps with MC API.
Test 1, Bluetooth enabled, Wi-Fi turned off:
GK speed: ~20KB/s
MC speed: ~20KB/s
Test 2, Bluetooth enabled, Wi-Fi turned on, but not connected to any Wi-Fi network:
GK speed: ~20KB/s
MC speed: ~200KB/s
Test 3: Bluetooth disabled, Wi-Fi turned on, but not connected to any Wi-Fi network:
GK speed: NA, can not discover peers.
MC speed: ~200KB/s
From 20KB/s to 200KB/s, the speed boost is a strong evidence of using Wi-Fi signal to transfer data instead of Bluetooth; and when Bluetooth is disabled at all, MC can still find peers and send data while GK can't, which can only be made possible with peer-to-peer Wi-Fi.
The answer is clear: by using MC, iOS devices can create a virtual network using peer-to-peer Wi-Fi, without the help of any hardware Wi-Fi reuter, Wi-Fi access point, etc.
The the next question is, what kind of network protocol is using on it?
More technically, in the layered OSI model, the Wi-Fi layered is just the physical and the MAC sub-layer (of data link layer), what kind of upper layers are on top this peer-to-peer Wi-Fi network? Is it still a TCP/IP network?
For this part, now I only got some clues, and my guess is yes, but it is a IPv6 network!
Clue 1, by iterating the network devices to check if there is any suspicious physical/virtual network devices.
* AF_LINK, AF_INET, AF_INET6 are all constants defined in <sys/socket.h>, to describe the address family of the device.
Device A, MC activated and paired, Bluetooth turned off:
sa_family: AF_LINK, ifa_name: lo0
sa_family: AF_INET6, ifa_name: lo0
sa_family: AF_INET, ifa_name: lo0
sa_family: AF_INET6, ifa_name: lo0
sa_family: AF_LINK, ifa_name: en0
sa_family: AF_LINK, ifa_name: awdl0
sa_family: AF_INET6, ifa_name: awdl0
sa_family: AF_LINK, ifa_name: en1
device inet interfaces: {
"IPV4:lo0" = "127.0.0.1";
"IPV6:awdl0" = "fe80::875:23ff:feb1:a1ec";
"IPV6:lo0" = "fe80::1";
}
Device B, MC activated and paired, Bluetooth turned off:
sa_family: AF_LINK, ifa_name: lo0
sa_family: AF_INET6, ifa_name: lo0
sa_family: AF_INET, ifa_name: lo0
sa_family: AF_INET6, ifa_name: lo0
sa_family: AF_LINK, ifa_name: pdp_ip0
sa_family: AF_INET, ifa_name: pdp_ip0
sa_family: AF_LINK, ifa_name: pdp_ip1
sa_family: AF_LINK, ifa_name: pdp_ip2
sa_family: AF_LINK, ifa_name: pdp_ip3
sa_family: AF_LINK, ifa_name: pdp_ip4
sa_family: AF_LINK, ifa_name: en1
sa_family: AF_LINK, ifa_name: ap1
sa_family: AF_LINK, ifa_name: en0
sa_family: AF_LINK, ifa_name: awdl0
sa_family: AF_INET6, ifa_name: awdl0
device inet interfaces: {
"IPV4:lo0" = "127.0.0.1";
"IPV4:pdp_ip0" = "10.37.167.92";
"IPV6:awdl0" = "fe80::74f4:6dff:fe8d:98ad";
"IPV6:lo0" = "fe80::1";
}
The device marked in bold, see it?
Clue 2, looking for similar designs. And there is indeed one, named Wi-Fi Direct, now commonly found in Android devices.
More information on it: http://en.wikipedia.org/wiki/Wi-Fi_Direct
Enough fun for today, cheers!
