Local Data Transfer¶

This is a survey of p2p data transfer methods that exist on mobile devices, and can be setup by an app.

The mechanisms have been divided into two groups, to avoid confusion. The first group is protocols which are suitable for transferring files. The second is means by which to initiate connections, using any of the protocols from the first section.

Protocols/Technologies for transferring files¶

Bluetooth¶

Wifi¶

• QR URL
• bonjour .local domain names
• captive portal splash page
• manually typing simplified IP, i.e. http://10.3.2.1:8080

Using existing wifi¶

• check if device is already associated with a wifi AP
• use that IP, and include name of wifi AP for other users

Setting Up An Access Point on the Device¶

• Paik style

Desktop Wifi Sharing¶

• make a desktop app that can download, verify APKs
  • HTTPS pin
  • GPG keys included
• it then makes a simple webserver to share them
• generates QR code of URL for scanning

Adhoc Wifi¶

Mesh¶

Wifi Direct¶

• Hans tried this and failed to get anything working, so this is punted as too difficult to be useful

NFC data transfer¶

Technically it is possible to transfer data via NFC, but it is not recommended. I presume it is due to the low bandwidth, but perhaps it is also due to lack of error correction or other requirements that make file transfer suitable. Most NFC software implementations (e.g. AndroidBeam, S-Beam) use NFC to bootsrap a more suitable connection such as bluetooth or wifi (see below).

Methods of initiating/bootstrapping p2p connections¶

NFC and QRCode's are both means to the same end - encode a small amount of information, transfer it between two devices in the easiest way possible, and use that information to initiate a connection between two devices. Whether the resulting connection is via Bluetooth, WiFi, WiFi-Direct, should be somewhat inconsequential to the users. In fact, most of us had a bit of trouble wrapping our head around the actual mechanism Android Beam uses, because it does such a good job of abstracting the underlying protocol. This is in stark contrast to, e.g. Bluetooth, where users are made accutely aware that they are initiating a two way communication channel with another device, which then sends data to them using the Bluetooth protocol.

NFC¶

• Android Beam (Uses NFC to initiate a Bluetooth connection)
• S-Beam (Uses NFC to initiate a WiFi-Direct connection)

QRCode¶

QRCodes are usually used to encode a URL. Although the URL doesn't have to be a http:// URL (it could equally be an fdroid:// or some other custom scheme), it is probably good practice to do so. The reason is that for an fdroid:// URL to work, the device scanning the barcode requires F-Droid to be installed.

However, if you use a URL such as http://10.0.0.10:8888/fdroid/repo, then if F-Droid is installed, it will be able to handle that URL, and if not, the user will be able to be shown a webpage served from that location, showing further information on how to connect.

Simulating p2p connection over HTTP¶

When using WiFi to transfer data between devices, we opt for HTTP, because the client already knows how to understand this, and it is a ubiquitos standard. One downside of HTTP is that it is a stateless, client-server protocol. That is, once you ask to download a file, the server generally doesn't then have the capability to request information back from the client (Yes, websockets, long-polling, etc exist to achieve this goal, but I'm referring to the general usage of HTTP).

• Device A: starts a swap
• Device A: shows a QRCode with it's IP address (along with a queyr parameter that indicates it is willing to accept repositories from clients - "http://10.0.0.10:8888?connect_back"
• Device B: scans the QRCode
• Device B: uses info from code to setup repository of Device A
• Device B: also POSTs to the URL of Device A telling it Device B's willingness to swap: "http://10.0.0.10:8888" with the POST params [ swap_available : "http://10.0.1.20:7777" ].
• Device A: uses info from POST request to setup repository of Device B