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.
Enables Wifi Direct and initializes the necessary intents for Wifi Direct.
In this class, the names of the files that are present in the android device are stored in a list. This is done only once, i.e., when the app is started. Also a SHA1 value for each of these files is calculated.
The Discover Peers button is initialized in this class. On clicking the Discover Peers button, the discoverPeers() function is called which discovers the peers.
This class contains different functions for the different events of Wifi Direct like change in wifi state, change in peers, Search request, Get request etc. The functions are called depending on the type of intent received by the Broadcast Receiver.
When there is a change in peers, then the requestPeers() function is called to get the current list of peers.
When peers are available and on clicking the connect button, the MAC address are compared, and the peer with the greater MAC address sets up the socket connection and the other peer waits for a socket connection in the ServerClass module. This happens in the OnPeersAvailable
When a Search request is received, the name of file is searched for in the file list and if the file is present a Search response message is sent back using SendMessage function.
When a Get request is received, the specified offset of a file is send using the SendFile function.
This class performs two functions which are the write module and the user search input module.
This class consists of a pop-up window which appears when the Search button is clicked. In this pop-up window the user can input the name of the file to be downloaded.
This class also contains a function called SendMessage, in which the message format is built and a function called SendFile in which the file offset number is added to the message format.
In this class, the group owner connects to a peer by creating a socket connection on a specific port number. The socket connection is competed once the other peer accepts the connection.
In this class, the socket connection is accepted and different functions are called depending on the intent received.
6. Download Button
The Download button is created in two cases which are when no file is being downloaded then it is created when a new request is received from the user. If a file is being downloaded and device receives a new request, it is created when all the other files ahead.
This classis used to convert the SHA1 value of the files to a string.
This class creates a Metadata file for the file that needs to be downloaded
This class is used when a new file offset is to be requested from a peer. The offset are generated in a random order.
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.
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
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