CSL374 Winter 2012: Assignment on P2P Bluetooth transfers
In this assignment, we want to study the dynamics of content distribution in a peer-to-peer manner via Bluetooth on mobile devices. But rather than actually transfer content, we will simulate content distribution on contact traces of Bluetooth interaction between devices. In the first part of the assignment, you will write a simple Bluetooth device discovery application that will record contact times with other Bluetooth devices. And in the second part, you will simulate content transfer on these contacts to examine statistics such as the time taken to distribute files to all the devices, or to 80% of the devices, etc.
Use the javax.bluetooth package to write an application on your Blackberry and Nokia phones to record other Bluetooth device IDs you encounter throughout the day. You should leave the application running at all times to record Bluetooth contacts, and upon each contact you should register it immediately to an HTTP application over GPRS as follows:
The server will record the timestamp at the instant you make this invocation. This will thus serve as a crowd-sourced repository to maintain Bluetooth contact times between pairs of devices. You can query the database as follows:
for a CSV of all entries
for a CSV of contacts made by the device specified
for a CSV of contacts made between the pair of devices specified
Plenty of examples are available online to write Bluetooth device discovery applications. Take a look at the javax.bluetooth package's LocalDevice class to get an instance of a discovery agent. Then implement the DiscoveryListener interface to capture callbacks upon any device discovery. Note that each Bluetooth device has a unique ID. Also note that if you run a discovery again and again, you will keep re-discovering the same device. You should however add only one contact entry per device pair per 5 minute period, ie. add another entry only if you discover the same device after 5 minutes.
Deadline: You must have verified a demo of your application with the TAs by Apr 18. Start logging contacts from the morning of Apr 19 when you wake up. You will be evaluated on the correctness of readings provided by your device.
Download the entire CSV of all pairs of Bluetooth contacts and analyze the data. To start, you can use the data collected by another batch of students [here].
Deadline: Submit your application code, simulation code, and a report on your findings by Apr 28th.
- Plot the contact frequency of devices against their rank. Is the distribution uniform or highly skewed?
- Which devices come in most contact with other devices? These would be hubs in the network -- if you give your file to these devices, they will likely share it with a lot of other devices.
- Can you find clusters of devices which interact more frequently with other devices in their cluster, than with devices in other clusters? You can do this by forming a graph where nodes represent devices and edge-weights represent contact freqency between pairs of devices. Then use commonly available graph-clustering algorithms to find clusters. Alternatively, just visualize the graph using commonly available graph-visualization tools. Do these clusters occur for devices in the same hostel, or in the same program of study with similar class schedules?
- Suppose that each contact is sufficiently long to transfer an entire file between the pair of devices. Assume that a file originates at some node, and simulate that the file keeps getting copied on to new devices when devices come in contact with a device already marked as having the file. For all devices, find the time taken for the file to get copied on to 50%, 80%, and 100% of the devices. Does this time correlate with the contact frequency of devices, ie. devices which have a higher contact frequency are able to spread the file faster?
- Instead of distributing content to all nodes, if you had to transfer your content to a specific node then suggest a routing heuristic to route the content to the destination. Think of a heuristic which imposes low network overhead (ie. fewer copies of content) yet delivers the content quickly.