The design of our android application started when we got to learn about the new technology that Google and Intel have collectively come up with - Wifi Direct. Wi-Fi Direct is a standard that allows Wi-Fi devices to connect to each other with no need for a wireless access point. This is useful for applications that share data among users, such as a multiplayer game or a photo sharing application. It combines the advantages of WiFi AdHoc connection and Bluetooth connection. Nowadays smartphone have been emulating complete functionality of computers where all the work that needs to be done can be completed when we are on the go. The advantages of Wifi Direct over traditional Bluetooth have motivated us to work with this new technology. Higher transfer speed (30 times faster than Bluetooth) and greater transfer range (100 - 150 m) and better security and authentication are few of the advantages. Brainstorming on how we can use this technology led us to develop an android application that implements P2P file transfer loosely based on BitTorrent. The files were been broken into small chunks where it was advantageous to transfer smaller pieces of the files when we are on the go.


1. TorrentActivity

2. WifiDirectBroadcastReceiver

3. UserInputClass

4. Discovery

5. ServerClass

6. Download Button

7. AeSampleSHA1

8. FileMetaData

9. GenerateFileRequest


1. After enabling Wifi direct and starting the app manually, three tabs which are status, details and mics can be seen.

2. In the status tab, a button named Discover Peers will be available. On clicking the Discover Peers button, the requestPeers() function (which calls the OnPeersAvailable() function) is called in the WifiDirectBroadcastReceiver module. This function gives the available peerlist.

3. Once a peer is available, the peers compare their MAC address with that of the other peer. A Connect button appears on the peer with the lower MAC address and the other peer listens for a connection request in the ServerClass module. On clicking the connect button a socket connection is created between the peers once the connection is accepted manually by the "server" peer.

4. Once the connection is established, a Search button appears. On clicking the Search button, a pop-up appears in which the user can enter the name of the file that needs to be downloaded from the peers.

5. On entering the filename, a download button appears. On clicking the Download button, the file begins to download and also a progress bar showing the download process can be seen. The download button (now seen as the Speed up button) can be clicked multiple times to increase the number of segments being downloaded and hence increase the download speed.

6. The details tab shows the details of the connection and the segments being downloaded. The misc tab shows the files available in the android device and also the downloaded files.

Design Options

While working on the project, we had to make many decision on the best was to execute a certain function. Some of the design decision we took are as follows:

1. File Request Option: The aim of the project was to divide files in segments and have an app which can download different segments of the same file from different phones. Since the file is divided into segments, we had to decide on whether to send the segments sequential or in a random order. We realized that when we send the segments sequential there could be a situation when all the android devices have the first few segments of a file downloaded from an android device having the entire file, and then the this android device goes out of range, all the other android devices in the network will have the same segments. If the segments were sent in random, then different devices will have different segments and hence these devices can exchange the missing segments among them self even in the absents of the main device.

2. The message format was designed with the necessary details which include the message type, offset value, message length and the message. The header size is 12 bytes and the message size is 512 bytes.

3. Another decision we had to make was how to request the required offsets of a file. The two options were by using a bitmap or by sending request for each offset. We observed that all though bitmap sends the request for all the segments once, sending large bitmap for large files would not be feasible. Moreover the delay incurred by sending requests for each segments is less.

4. To download the required segments, we used Get Request and Search Request messages. When a device needs a segment, it sends a Search Request message with the required offset number. If the peer has that particular segment, then the peer replies back with a Search Respond message. On receiving the Search Respond message, the device then sends a Get Request Message to which it gets the segment as a reply.

Future Work / Extensions

Avoid Free-Riding: It so happens that few peers tend to download content from their neighboring peers and never upload any of their content thus making the network redundant. In order to avoid this problem we have come about with a solution. The peers have a seeding to leeching ratio that is associated with each one of them. Based on this ratio we can segregate them into groups and assign bandwidth accordingly in order to increase the fairness in the network.

Syncing Content on the go: Most of the files are downloaded from the internet on our computers/Laptops. In order to continue downloads of the unfinished files, we thought of an idea to get the download completed by downloading the remainder of the files while we are on the go. There could be an application in our computer where we can transfer the unfinished file wirelessly and then download the remainder of the file through the mobile device.


1. Establishing the connection and sockets between peers with Wifi Direct.

2. Peers requesting the filenames of the files that they need.

3. Divided the entire file into smaller segments in order to make the transfer more reliable as in our case we are trying to transfer files in a dynamic environment.

4. Files were transferred successfully among the peers.

5. The GUI that was developed is very user friendly and simple to use

6. We successfully implemented a mechanism where we can speed up the download process by sending a group of file requests with different offset at the same time.

7. The reconnection of devices when they get out of range and get back wasn't happening because of a few bugs present in the

Useful Links

GitHub Repository

Prezi Presentation