EE579: Wireless and Mobile
Networks Design Laboratory
Final Project Report on What’s
Playing?
Ameya Pethkar, Himanshu Gupta and
Omkar Chavan
MS in Electrical Engineering
University of Southern California
{ pethkar, himanshg, ochavan
@usc.edu }
1.
Abstract
This report
explains the design and architecture of our peer-to-peer multimedia sharing
android application “What’s Playing?” We are all familiar with Google and use
it daily for our day-to-day search spanning a wide range. But sometimes people are curious to know
their friend’s preferences, likes/dislikes in songs, videos etc. Most of the
applications in android market so far are mostly dedicated media players or
online radio or dedicated torrent clients meant for file sharing. Also most of
the free applications come bundled with advertisements which can be annoying at
times. Our application aims at incorporating file sharing functionality into an
android application focused on sharing of multimedia such as Songs, Images and
Videos in the same private network.
2.
Introduction
Music is enjoyed
by people of all ages widely. There are various ways of file sharing viz:
Bluetooth and over the Web. But the file sharing over Bluetooth is limited by
the transfer speeds and range whereas the latter approach requires availability
of Internet. What’s Playing? enables users to share their files with
other users on the same private network without the need for Internet and
allowing for decent transfer rates. This scenario can be further visualized as
follows: A student in a university using this application can share files with
other users using the same application. This is because all the users are
connected to the same private network. Our implementation requires the use of a
centralized server (Laptop) whose IP address has been hard-coded into the
application. The server serves the purpose of storing dedicated user database
containing the names of files shared by a particular user and also offering an
online storage facility to users to store files on the server.
The android
application provides many features which are discussed in detail in further
sections. The main graphical user interface offers three options viz: the user
to register with the centralized server, sign in to go online and lastly an
option to work offline. After a user goes online or prefers the offline option
he is presented with a second graphical interface providing a wide range of
features such as: Find Friends Online, My Favorites, Request a File, My
Downloads, etc. to name a few. This report is further arranged as follows:
Section 3 discusses some related work/applications available in the android
market, Section 4 details the Server Architecture, Section 5 explains the
Android Application Architecture and a detailed explanation of the features with
appropriate images, Section 6 documents the known bugs and issues in the
implementation followed by a discussion about Future Improvements in Section 7
and Conclusion in Section 8.
3.
Related Works
There are thousands of applications related to music in more ways than
one and a few torrent applications in the Android market. It was impossible to
review them all hence a selective applications were short-listed and reviewed
to observer their functionalities and features. Some of the music applications
we reviewed were: Shazam, Digitally Imported Radio, Pandora for Android,
Grooveshark for Android and AudioGalaxy. Some of the applications and their
functionalities are as follows:
·
Shazam provides a short review audio clip to users
before downloading a particular tune by connecting to cloud.
·
Digitally Imported Radio and Pandora both are online
radio applications with a wide variety of music genres to choose from.
·
Grooveshark is an online library of music files
which can be searched and played, however the application requires a $9 monthly
fee for unrestricted access.
·
AudioGalaxy provides streaming music from a user’s
computer to his Android device over the internet.
Some of the torrent applications for android include aTorrent which is a
peer-to-peer bit torrent application, aDownloader which uses specific torrent
search engine website to search for torrents and tTorrentLite which has a
maximum download speed of 250 kb/s in the free version. However the popular
utorrent desktop P2P client is available as utorrent Remote which is actually
just an android application allowing a user to control and keep track of his
torrents on his desktop machine.
The most common trait observed in these applications is that since all of
these are free versions, they come tied with annoying adverts and/or restricted
functionality like in case of Grooveshark and tTorrentLite. And we also came
across a multimedia sharing application called iMediaShare which allows users
to share multimedia from handsets or web based social media to other media
devices such as internet enabled TVs or PS3 etc.
Hence it can be seen that a vast majority of the application come with
restricted functionality or require the availability of internet. There has
been no attempt made at making an application like ours.
4.
Server
Architecture
The centralized
server (Laptop) serves to store a dedicated user database on it. The server is
passive open listening for incoming connections on port 9777 from android
powered clients. It is multi-threaded to be able of handling multiple
connections from multiple clients. The figure below shows the visual
representation of the system.
Figure showing
the Visual Representation of the system
The figure below
shows the functional representation of the actual process happening at the
server.
Figure showing
Functional Representation of the Server
The packet
format used for information exchange between the server and clients is as
follows:
From above image
we can see that the packet consists of different fields which are as follows:
·
API_TYPE:
This indicates the type of message coming to the server. The message could be
REGISTER to register with the server, GET LIST OF FRIENDS to request for list
of online users, etc.
·
TOTAL_LEN:
This indicates the total length of the packet.
·
MSG_LEN:
This indicates the actual length of message to the server.
·
Message:
This is the actual message coming to the server (String in this case).
Based on the
message, corresponding actions are executed at the server end. This handling
has been done in the public void run( )
method in the Server.java file. The
different types of messages and corresponding actions are as follows:
·
REGISTER
causes the server to create a text file named RegistrationDetails to
store user details such as username, email address and password in it. If this
file already exists then these details are appended in it.
·
LOGIN
causes the server to validate the incoming user in the Registration text file
and store the user details such as username, email address and IP address to a
text file called LoginDetails. If such file already exists then the
information is appended in it.
·
GET
LIST OF FRIENDS message causes the server to return the list of all online
users to the requesting client.
·
REQUESTED
to search for a specific user from the list of online users. This option allows
us to find upto three friends and returns the usernames, email addresses and IP
addresses to the requesting client(s).
·
GANG
to search a friend from a list of close friends (My Gang) who are online.
·
END
to terminate the connection between the server and client (mobile device).
·
LOG
OFF removes the entry of that particular client from the list of online users.
·
CALL
is to send a requested file from the server to the requesting client.
·
LOCK
is to lock that particular client’s account to restrict access.
·
Share
is to add file names in the list of files shared.
·
COMPLETED
populates the filenames text file with the complete list of shared files of a
particular user.
·
QUERY
is to search for a specific file on the server and returns list of user(s)
having that file.
·
FILES
is used to obtain the list of files shared by a particular user.
·
STORE
is used to store a file from a particular user to his online database i.e. in
the Files sub-directory under the parent directory bearing the user email
address.
·
SEARCH
allows a user knowing the email address and password of other user to find out
the files shared by that particular user.
·
HELLO
are the keep-alive messages sent out the mobile devices and used to
maintain a fresh list of online users in the server.
5.
Android
Application Architecture
This section explains the android application design and architecture
along with the features in detail. There are various interfaces in our android
application. The first graphical user interface (GUI) presented to user on
starting the application is as shown below:
It provides the three options:
·
Register:
To register a user with the centralized server. This is a one-time registration
process.
·
Go
Live: This option is to sign into the centralized server and go online.
·
Invisible:
This option is to allow users who prefer to work offline (i.e. without signing
in the centralized server) and still use the application.
On selecting the Register Option the user is provided with a prompt to enter his details such as
Name, email address and password as shown below:
After the registration is completed, an online storage for the user is
created on the server and correspondingly folders favorites and MyDownloads
are created in the phone as shown in the figure below. MyDownloads is a
folder where the requested files will be downloaded and favorites is a
folder containing the files shared by the user with others.
As seen from the left-side figure, we can see that under the parent
Directory folder we have folders named: john@usc.edu, max@usc.edu and
omkar@usc.edu which are the online storage for those users. Furthermore we can
see under omkar@usc.edu we have two files stored under the Files subdirectory and also a
FileNames.txt file containing the list of files shared by that particular user.
Also it can be seen from the right-side figure that we have favorites and
MyDownloads folders created in the phone for sharing files and storing of
downloaded files respectively.
Selecting the GoLive option prompts a user for his details to login and go online as shown in
the figure below. These details are validated by the Server with the contents
of Registration.txt file and only after that the user goes online.
After a user goes online or prefers to work offline he is presented with
a second interface as shown below with various features to select from.
The different features on the second interface are as follows:
·
Friends Online: Finds Online Friends.
·
My favorites: contains the files shared by that user
with others.
·
Request a file: Provides option to a user to request
a particular file from other peers or from server.
·
Search Online: Look for a particular file online on
the internet.
·
Wi-Fi Direct: Directly download a file from a peer
if you know his IP address.
·
Add Friends: Add People to your Friend Network (My
Gang)
·
My Downloads: Shows a list recent downloaded items
·
Log off: Logoff from the Server.
Friends Online: This
allows a user to find his friends who are currently online. A user can find
upto three users based on a Search by Name or can see all online users by selecting
the Show Me All or can also find his friends by selecting the Show My Gang
option as shown in the figures below:
Figure showing the Search by Name option to find a specific user online
Figure showing the Show Me All option which gives list of all online
users
Figure showing Show My Gang option which only shows online friends from
the user’s list
In all these three cases the server returns the requesting client with
the list of online users. This list is populated in the client and on selecting
any particular user gives the option of Request, Cancel and Send a File as
shown in the figure below:
My favorites: Selecting
this option gives a second interface providing a user facility to Lock his
account to restrict access, My Files which shows files shared by the user
arranged as Songs, Videos and Images and Selecting any one option shows files
of that category shared by that user. The last option is used to send the list
of files shared by the user to the server.
In the image above we can see that the user is sharing Tulips and
Chrysanthemum image files with other peers. The “Send file names to server”
should be performed first by all users before users can request for list of
files shared by other peers.
Request a File: This
provides a client to request for a file from peers or to download it from server
directly. Both options require the file name to be inputted by the client.
On requesting a file an informative progress bar shows the file being downloaded
and also from where/whom the file is being downloaded i.e. from server or from
other peer.
We can see the file decibel.mp3 being downloaded by the peer from the
database of user ameya on the centralized server. This is because of the
Download from Server option was selected and correspondingly file(s) were
requested from the Server.
Search Online: This
option is used to search for a file directly on the internet by launching the
web browser.
WiFi Direct: This is
slightly a misnomer and should not be confused with the actual WiFi Direct by
Google in Android version 4 onwards. This option merely gives the client to
directly connect to his peers if their IP addresses are known to him and
download the required files. The figure below demonstrates the WiFi Direct
facility.
Add Friends: This is used
to add specific users to your friend circle. This is similar to the Google Plus
feature of arranging people in circles. This requires you to provide the Name
and Email address of the user you want to include in your friend circle.
My Downloads: This shows a
list of all the recently downloaded files by that user.
Log Off: This option
logs off the user from the centralized server. The logged off user is removed
from the list of online users.
File Transfer between peers:
When actual file is being requested or sent by a peer, the message is
actually being transferred in byte format. Following is the Format which is
been used in the project for transfer of the file between client and server or
among peers.
·
Message Type: Use to identify whether message is
requested or directly sent
·
Filename Length: Indicates the length of the
filename which represents it.
·
Filename: The
actual name of the file. This is a String field.
·
File Size: The actual file size
·
Actual File: Actual file to be sent
The transfer of the files can be done in various ways such as: it can be
a request by a peer or it can be sent to a peer. The following block diagram
shows how peers connect with each other to get a particular file. Each of the
to and fro connections is a socket connection.
Following are the various scenarios for file transfer:
·
A peer sends a file directly to other peers after
searching for which peers are online in the server.
·
A peer sends a file to the server for storing it in
its database in the server so that some other peer can get the file when it is
offline.
·
A peer requests for a file from the friends which
are online or searches for a file to check if it is available with other peers.
In either case the request is sent to the server and server replies back with
the list of users along with their IP addresses so that peers can directly
connect and get the file.
·
A peer will request for a file from database of the
other peer in the server.
Maintaining status of mobile users in the Server:
It is very important for the server to keep track of which user(s) is/are
online all the time. This is to ensure that for any request for list of online
users, consistent data is sent to the requesting user.
This is done in two ways:
·
Login and Logoff.
·
timeCheck class implemented in the Centralized
Server.
Login and Logoff:
In this method, when the user(s) logs in the application its online
status is sent to the server and server adds the user(s) in the list of online
users. The user can go offline by selecting the Log Off option. This is
similar to using instant messenger chat services such a GTalk or Yahoo
Messenger.
timeCheck class implemented in the Centralized
Server:
There is a possibility that when the user comes online, the application
may get closed due to some unexpected reason. And there is high possibility
that the server will send stale data to other peers and the connection with
this user which was shown online will fail.
To circumvent this issue we have implemented Hello messages in our
application which are handled at the server end. When a user comes online for
the first time, it starts sending Hello messages to the server and
correspondingly the server maintains a list of online users which is updated at
every 5 minutes interval. The Hello messages are sent by the user every
minute and it is a background process. We have used a hashMap data structure
with the email address of the user as the key and the timer count as the value.
Hence if a Hello message is not received in the stipulated 5 minute interval to
the server then the list of online users is updated with a fresh list of online
users those from whom hello messages are being received.
6.
Known Bugs and
Issues
This section documents the known bugs and issues encountered while
developing this particular application.
·
The file size is restricted to 10MB. This is because
if the size is greater than 10 MB then the android application crashes with out
of memory error. This might be because Java is not able to assign that much
memory in the heap. One solution to this is to split the file in smaller size
chunks.
·
The second issue is that whenever a file is being
sent or requested by a peer we don’t have any appropriate popup message or
progress bar and the file transfer happens without the user knowing about it.
We tried using Broadcast Receiver to solve this problem but it caused the
entire application to hang and thus force close it.
·
Like in many applications involving use of a
centralized server, in our application also the IP address of the server has
been hardcoded hence every time one needs to change the IP address when
connected to a different private network. This could be solved by asking server
IP address at the time of Registration.
·
Lastly, the entire project has to be loaded into
following path only C:/EE579/workspace. The Directory path can also be set or created once the server starts
i.e. create a Directory in the path where the entire project is loaded.
7.
Future
Improvements
Some of the future improvements which we have thought of while developing
this application are as follows:
·
Load Balancing: Downloading the same file from
several users rather than just one user at a time.
·
Data Transmission rates to be varied depending on
the signal strength, number of packets dropped etc.
·
Additional Feature: To have an in-app Instant Chat
Messenger
·
Personalizing the application according to a user's
preferences.
·
Sending a file to multiple users at a time.
·
Incorporating Wi-Fi Direct feature to use the
application’s features with it thereby reducing the dependency on centralized
server.
8.
Conclusion
We have successfully developed a multimedia sharing android application
with peer-to-peer as its underlying principle. The entire design has gone
through several modifications and testing phases before actually implementing
them in the project. The initial design was based on using the WiFi Direct
technology in Android version 4 but later it was modified to exploit transfer
over sockets thereby allowing us to make an application equipped with file
transfer capability to users connected on the same private network. In the
given academic time frame we have attempted and succeeded in creating an
android application which allows users to share his/her favorite files with
other peers which is in contrast to stand-alone media or online radio player applications
or for that matter torrent application which are purely for any type of file
transfer.
9.
Acknowledgements
We would like to express our gratitude to Professor Bhaskar
Krishnamachari for giving us this opportunity of developing this particular
project and also for his constant encouragement, support and guidance which
helped us develop the application in a better way and adhering to the widely
practiced industry standards and styles. We are also greatly indebted to our
parents back home for their constant love and support which has helped us steer
through these semesters at USC. We would also like to thank our Teaching
Assistant for the course Maheswaran Sathiamoorthy for being accessible even
during hours other than his office hours. We would also like to thank Suvil
Singh Deora for his assistance in the MikroTik router assignment and the entire
ANRG group for their love and support.
Last but not the least we cannot thank Music enough for being the one
faithful companion during our late night developing, coding and testing phases.
10. References
·
http://stackoverflow.com/questions/3295200/alertdialog-builder-using-layout-how-do-i-get-values-of-edittexts
·
http://stackoverflow.com/questions/3426917/how-to-add-two-edit-text-fields-in-an-alert-dialog
·
http://blog.sptechnolab.com/2011/02/01/android/android-custom-listview-items-and-adapters/
·
http://developer.android.com/guide/index.html
·
For Multi-Threaded Server:
http://edn.embarcadero.com/article/31995
·
http://www.makeuseof.com/tag/5-music-apps-android-device/
·
http://www.androidauthority.com/best-bittorrent-clients-for-android-38700/