Distributed Media
Player
Ran Margolin
[email protected]
Dan Waxman
[email protected]
Supervisor
Ittay Eyal
[email protected]
Software Systems Lab
Department of Electrical Engineering,
Technion - Israel Institute of Technology
1
Table of contents
INTRODUCTION
3
OBJECTIVES
WORK SUMMARY
3
4
TECHNOLOGY OVERVIEW
6
ABOUT JAVA
ABOUT MYSQL
ABOUT JMF – JAVA MEDIA FRAMEWORK
6
6
7
BIRDS VIEW OF THE SYSTEM
8
APPLICATION OF “THREE TIER ARCHITECTURE” IN DMP:
9
PRESENTATION TIER
11
LOGIC TIER
12
DATA TIER
19
CONCLUSION
21
APPENDIX A – THE LOG STRUCTURE
22
APPENDIX B - USER GUIDE
24
_
25
REFERENCES
29
2
Introduction
The Distributed Media Player (hereinafter DMP) is a distributed platform for playing media files
concurrently (using auxiliary synchronization moduls) throughout a network of computers.
Concurrent playback being, playback of a song on multiple computers within a reasonable
difference as to not be detected by the human ear.
The DMP software is located locally on each member computer, allowing each member identical
privileges and control. The members share a shared media library, which enables each user to
play songs which are not necessary located locally, throughout the network.
The DMP utilizes Java Media Framework, MySQL database and Java libraries.
Objectives
The main goal of the project is to create a distributed media player which will enable users to
play media files simultaneously on a network of computers. A user would be able to control the
media player of all connected computers and play songs which are not necessary located locally
on his computer but on some computer which is connected to the network.
Sub Objectives:
1. Create a synchronized clock between the network members - In order to create
simultaneous playback we assumed that if all the computers connected to the network
shared a common clock, we would be able to synchronize the playback start time
according to that clock (this assumption proved to be false and is further discussed in
the Conclusion chapter)
2. Create a platform to play the media files.
3. Create a user friendly GUI.
4. Create a shared command Log which details the various commands issued by the network
members- this insures identical behavior of each of the network computers.
5. Create a database of available media files.
6. Connect the synchronized clock with the media player to enable simultaneous playback.
Our personal goals in this project
1. Familiarize with Java programming language.
2. Learn about writing network applications.
3. Learn and implement software design patterns such as the observer or decorator
design patterns.
4. Handle problems that arise with concurrency in software systems.
3
Work Summary
Requirements Definition
The first stage of the project included learning the DMP’s requirements, and thinking of the best
solutions for the problems which arose from these requirements.
Following are the some of the main subjects we have dealt with:
Newcomers that join the network
Issue: Updating the other members of the network regarding the joining of a new network
member.
Solution: Constant synchronization using directed connection between pairs of network
members, of all known network members.
Disconnections at various scenarios (temporary/permanent)
Issue: Connection hang-up can occur during a file transfer, message transfer etc.
Solution: Reconnection tries (in case of member disconnection), checking an updated member
status (to check whether the disconnection is permanent or temporary).
Corrupt file transfers
Issue: failed file transfer in the network.
Solution: Repeated file transaction.
Clock synchronization
Issue: Synchronization between all the network members’ local times, assure that concurrent
events occur simultaneously (or reasonably close) between the network members.
Solution: The 'Network Clock Time' (henceforth NCT) is a counter maintained by each of the
network members. The clock is constantly synchronized between the network members (no
‘reference clock' present in the network). The importance of the NCT is not to indicate the 'realworld' time, but rather to synchronize events between the users.
Distinguishing between network users
Issue: When commands are issued by multiple users at the same time, a strict command
execution ordering is needed. In order to define such ordering between users, a method to
distinguish between users is needed, or in other words, a unique ID for each user.
Solution: Each user’s unique ID is their local MAC address, which is unique for each network
card.
Synchronization between users
Issue: Multiple users can update the common playlist, an issue that can be the origin of
complicated collision.
4
Solution: Maintain local logs which are synchronized between users via direct member to
member connection. At any given time these logs should be identical throughout the network.
Implementation
We implemented both NCT & DMP using the Java language. The IDE used for writing &
debugging was Eclipse. In addition to JMF & MySQL technologies (further discussed in the next
chapter), we used the visualswing4eclipse plug-in in order to create the DMP GUI.
Testing & Debugging
During our testing & debugging we tested the DMP using at most 3 computers with various
versions of windows (Windows7, Windows Vista & Windows XP).
5
Technology Overview
About Java
“Java technology's versatility, efficiency, platform portability, and security make it the ideal
technology for network computing... Java has been tested, refined, extended, and proven by a
dedicated community. And numbering more than 6.5 million developers, it's the largest and most
active on the planet. With its versatility, efficiency, and portability, Java has become invaluable
to developers.” (http://www.java.com)
About MySQL
“MySQL is a database management system.
A database is a structured collection of data. It may be anything from a simple shopping list to a
picture gallery or the vast amounts of information in a corporate network. To add, access, and
process data stored in a computer database, you need a database management system such as
MySQL Server.
MySQL is a relational database management system.
A relational database stores data in separate tables rather than putting all the data in one big
storeroom. This adds speed and flexibility.
MySQL software is Open Source.
Open Source means that it is possible for anyone to use and modify the software. Anybody can
download the MySQL software from the Internet and use it without paying anything. If you wish,
you may study the source code and change it to suit your needs.
The MySQL Database Server is very fast, reliable, and easy to use.
MySQL Server works in client/server or embedded systems.
The MySQL Database Software is a client/server system that consists of a multi-threaded SQL
server that supports different backends, several different client programs and libraries,
administrative tools, and a wide range of application programming interfaces (APIs).
We also provide MySQL Server as an embedded multi-threaded library that you can link into your
application to get a smaller, faster, easier-to-manage standalone product.
6
A large amount of contributed MySQL software is available. “
(http://www.mysql.com/)
About JMF – Java Media Framework
“The Java Media Framework API (JMF) enables audio, video and other time-based media to be
added to applications and applets built on Java technology. This optional package, which can
capture, playback, stream, and transcode multiple media formats, extends the Java 2 Platform,
Standard Edition (J2SE) for multimedia developers by providing a powerful toolkit to develop
scalable, cross-platform technology. “
(http://java.sun.com/javase/technologies/desktop/media/jmf/)
7
Birds View of the system
The DMP architecture is known as the “Three Tier Architecture” and is formed by usage of
several layers interfacing between them.
The following diagram shows the responsibility and example of the separated layers:
(Definitions taken from http://en.wikipedia.org/wiki/Multitier_architecture)
8
Application of “Three Tier Architecture” in DMP:
Presentation Tier
In our project, the presentation tier consists of the GUI. The GUI allows the users to add new
members to the DMP network, to control playability (play, stop, seek, pause, etc.), view the
current network time (NCT) and keep informed as to the status of the player.
Logic Tier
In our project, the Logic Tier is consists of the Controllers.
The types of controllers are as follows:
DMP Core Controller:
 The Core Controller, in charge of connecting all the DMP elements.
 All data to/from the GUI passes through it.
Synchronizing Controllers:
 In charge of synchronizing, either by initiating or by accepting a remote request.
 Elements which are synchronized through the network consist of the NCT, Neighbor List,
Song List and Log.
Media Player Controller:
 In charge of the actual playback and other various commands performed by the media
player.
Data Controllers:
 Connect between the different clients and the actual implemented data storage.
 Data storages include data types stored in the RAM, text files & SQL.
Data Tier
In our project the Data Access Layer consists of:
 Neighbor List- List of all connected computers in network & their synchronized status.
Due to its constant changing nature and small amount of information, this data is stored
in the RAM.
 Song List- List of all available songs throughout the network.
Due to its large quantity of data (each Song contains a list of all the users which own it),
this data is stored on the hard drive. In addition, in order to simplify access and store
the data in an efficient manner, MySQL database was used.
 Log- A record of all commands issued by all network users.
The Log stores all commands issued from all the network members. This can amount to
a lot of data, which therefore has to be stored on the hard-drive. In order to make the
9
Log readable and make use of Java’s text file editing methods, a Text file was used to
store the commands.
10
Presentation Tier
The presentation tier connects between the user's commands and the DMP’s logic tier. The
presentation tier was implemented using Java’s Swing library & Eclipse’s visualswing4eclipse
plugin.
The presentation tier offers the user control over the DMP and informs him of the DMP’s
current status in a comfortable graphic interface.
(See Appendix B – User Guide, for information on how to operate the GUI).
11
Logic Tier
The logic tier can be divided into two modules which act independently, Distributed Media
Player (DMP) and Network Clock Time (NCT).
Brief Overview of NCT & DMP
NCT
The 'Network Clock Time' (NCT) is a counter maintained by each of the network members. The
clock is constantly synchronized between the network members, and there is no ‘reference
clock' present in the network. The importance of the NCT is not to indicate the 'real-world' time,
but rather to synchronize events between the users.
The objective of the NCT is to assure that concurrent events occur simultaneously (or reasonably
close) between the network members.
The problems arise from the fact that an upper bound cannot be assumed for the propagation
time of a message sent through the network. Therefore a method to estimate the message
propagation time is used.
We assume that the network lines are symmetrical (or close enough i.e. propagation time for A
B is equal to AB). In addition the NCT is never set backwards (except for reset).
DMP
The DMP is the core software. It utilizes the NCT in order to synchronize the playback timing.
The DMP contains a similar Neighbor List to the NCT Neighbor List, maintains the network song
library, (implemented later on in the Data Tier using MySQL database) and it maintains the
command Log.
Other than the basic API used to communicate with the NCT (current time, notified when time is
changed due to time synchronization and adding a user to the NCT network), the DMP and NCT
are independent. This allows, if wanted, to replace the NCT with a different implementation
(possibly better) of a synchronized clock.
The NCT’s logic tier consists of:
 Core Controller- Connects between the NCT elements and offers functionality to
external clients (such as current time and notification in case of time update).
 Clock Controller- A clock with millisecond resolution.
 Synchronization Controller- In charge of time and neighbor list synchronization (either
initiated or remotely requested).
 Neighbor List Controller- Offers access and maintenance to a list of all users connected
to the network.
12
The DMP’s logic tier consists of:
 Core Controller- Connects between the DMP elements including the GUI. The DMP core
controller connects to the NCT core controller.
 Synchronization Controller- In charge of time synchronization (either initiated or
remotely requested).
 Media Player Controller- in charge of the actual playback and other various commands
performed by the media player.
 Neighbor List Controller- Offers access and maintenance to a list of all users connected
to the network.
 Song List Controller- Offers an abstraction to the SQL database which stores all the
songs available throughout the network.
 Log Controller- Offers access and maintenance to a record of all commands issued by all
network users.
The NCT can run independently of the DMP and maintains its own network users. The DMP
connects to the NCT and receives time related data (current time and notification of time
update due to synchronization).
The DMP in addition informs the NCT of every user in the DMP network, thus maintaining two
identical (although independent) networks, DMP & NCT.
Synchronization Process
The synchronization process is done by each network member, which operates a local Listen
Server. The listen server receives requests from remote users, and directs the requests to the
suitable controller which handles them.
NCT
NCT Synchronization Process:
The NCT’s Listen Server is designated for receiving time synchronization requests and Neighbor
List synchronization requests.
Upon receiving a request, the Listen Server identifies the type of the request, and passes the
request to the appropriate controller.
Possible requests are as follows:
 Neighbor List synchronization request: Request to synchronize the list of users currently
in the NCT network between two users.
 Time synchronization request: Request to synchronize the current NCT time between
two users.
13
Neighbor List Synchronization Algorithm
The synchronization of the Neighbor List is simply done by exchanging the local lists between
two members through a TCP connection and then locally synchronizing the two (Union).
Time Synchronization Algorithm
Overview:
The time synchronization algorithm was developed in order to prevent skews between the
network members as much as possible.
We assume that the network lines are symmetrical (or close enough), i.e. Propagation time for
AB is equal to AB. In addition the NCT is never set backwards (except for reset).
The Algorithm:
The NCT synchronization is done in at least in 4 stages and at most in a determined max number
of stages:
Let A and B be members in the network (A - Initiator).
1.
Member A sends NCT_SyncMsg1 to B, containing:
[ <CurrentNCTtime_A> - <EstimatedMsgPropagation(A,B)> ]
<CurrentNCTtime_A> - Current NCT time of member A.
< EstimatedMsgPropagation(A,B)> - Estimated propagation time of message sent from A
to B. Set to minimum propagation time .
2.
Member B receives NCT_SyncMsg1 and performs the following:
a.
Calculates current estimated time by A
CurrentEstimatedNCTCurrentNCTtime_A + EstimatedMsgPropagation(A,B)
b.
B is set as a reference clock if CurrentEstimatedNCT < CurrentNCTtime_B, else A
is set as a reference clock.
c.
Sends NCT_SyncMsg2 to A containing:
[ <CurrentNCTtime_B> - <EstimatedMsgPropagation(B,A)> - <A/B> ]
NCT_SyncMsg1 - message sent from A.
<CurrentNCTtime_B> - Current NCT time of member B.
< EstimatedMsgPropagation(B,A)> - Estimated propagation time of message
sent from A to B. Set to minimum propagation time .
<A/B> - Whether A or B is the reference clock.
3.
Member A receives NCT_SyncMsg2 and performs the following:
a.
Calculates current estimated time by B
CurrentEstimatedNCTCurrentNCTtime_B + EstimatedMsgPropagation(A,B)
b.
If (CurrentEstimatedNCT > CurrentNCTtime_A & B reference clock)
Set CurrentNCTtime_A CurrentEstimatedNCT
Set B as reference clock.
14
c.
Else if (CurrentEstimatedNCT < CurrentNCTtime_A & B reference clock)
Set A as reference clock.
Else if (A reference clock)
Keep CurrentNCTtime_A.
Send NCT_SyncMsg3 to B containing:
[ <CurrentNCTtime_A> - <EstimatedMsgPropagation(A,B)> - <A/B> ]
NCT_SyncMsg2 - message sent from B.
<CurrentNCTtime_A> - Current NCT time of member A.
< EstimatedMsgPropagation(A,B)> - Estimated propagation time of message
sent from A to B. Set as (time between messages divided by 2)
<A/B> - Whether A or B is the reference clock.
Stage 3 continues (interchanging between A and B) until a member receives a message
containing the same member as a Reference Clock as the previous message (in this case the
member sends a sync success message), or a max threshold number of messages were sent (an
error message is sent).
Sync Success Message : <SyncSuccess>
Error Message: <SyncError>
15
DMP:
DMP Synchronization Process & Data transfer:
The DMP’s Listen Server is designated for receiving messages.
Upon receiving a message, the Listen Server identifies the type message, and passes the
message to the appropriate controller.
Possible messages are as follows:
 Neighbor List synchronization request: Request to synchronize the list of users currently
in the DMP network between two users.
 Song List synchronization request: Request to synchronize the list of songs currently
available throughout the DMP network. Thus creating a shared song library.
 Log synchronization request: Request to synchronize the command Log between two
users.
 Command issue: Command issued by a remote user. No synchronization is performed
here apart from forwarding the command to the Log Controller to be added to the local
Log.
 Song request: Request to send a song which is missing locally on the requested
computer, in order for it to be played.
Neighbor List & Song List Synchronization Algorithm
The synchronization of the Neighbor and Song List is simply done by exchanging the local lists
between two members through a TCP connection and then locally synchronizing the two
(Union).
Log Synchronization Algorithm
The synchronization of the Log is done by exchanging a snapshot of the local Log text file. Each
user then uses the temporary Log file (snapshot of the remote user’s Log) to synchronize the
local Log by creating a union of the two.
Command Issue Algorithm
A command can be issued by the local user or by a remote user. If the command is issued locally
(through the GUI) it is passed to the Log controller, if the command is issued remotely, the
Listen Server passes the command to the Log controller. So the two scenarios are similar.
Due to the nature of a distributed program, conflicts can occur when two users issue commands
at the same time. This is solved by using a strict ordering algorithm:
Log Ordering Algorithm
Each command is assigned an Entry ID which determines its placement in the Log.
In addition to the Entry ID, the initiating user’s MAC address (which is unique) is added to the
command as well (For further details as to Log structure refer to appendix A)
16
If the command is received from a remote user, it already has an Entry ID and only needs to be
placed in the appropriate place in the Log. If the command is issued locally, the command’s
Entry ID needs to be determined.
Entry ID Determining:
If a command is issued locally, an Entry ID is given to the command by locating the last
command listed in the local Log and incrementing its Entry ID.
Inserting Command into Log:
The command is sorted primarily according to the value of Entry ID and secondly according to
value of initiator (the user who issued said command) MAC address (which is unique). This
assures that even if two commands are issued exactly at the same time by two different users,
even though they will both receive the same Entry ID, their ordering in the Log is arbitrary, but
well defined.
Song Request Algorithm
When a song is played throughout the network, each system assures that the song is located
locally. In case the song is not located locally, an owner is retrieved from the Song List (refer to
the Data tier for more information as to the structure of the Song List) and a request is issued to
that user, who in return sends the desired song back through the TCP connection. The Song is
then stored in a temporary folder, which, when exiting the DMP program, will be deleted.
Media Player Controller:
Initially, we have chosen to use VLC media player. The following bullets detail the reasons as to
why we switched to JMF:
 Insufficient API status details – The API didn’t return any indication of command
execution/completion.
 VLC does not support any way to listen to controller events.
JMF (our chosen platform) supports controller listener. This way we can get info on commands
status. Although it still incorporates the issue of unknown command execution latency, it
produces better implementation methods to the project’s algorithms.
The DMP Media Player is implemented using JMF – Java Media framework.
The basic operation of the media player is to receive commands which were entered into the
Log, and operate accordingly. The commands are interpreted from Log command format into
the player format.
In addition to playing the media files, the Media Player Controller is also in charge for
synchronizing the play time of the song, in order for it to play simultaneously with the other
network member’s media players.
This time synchronization is done according to the NCT.
17
The following synchronization methods are performed in order to assure playback with
minimum latency between users:
 Start playback according to NCT time – Initially assumed that if playback starts at the
same moment for all users, then the playback will be simultaneous. This proved
problematic and wrong. It was problematic because, even with the NCT which is
synchronized with a millisecond resolution, we were unable to assure playback start
time, due to the nature of the JMF which is not real-time oriented. An attempt to solve
this problem was to calculate an average time between “play command issues” and
“play events” (using the previously described JMF controller events), and use this time
to predict the lag time and adjust the wanted seek time (taking into the account the
computational lag).
In addition this assumption was wrong, due to the fact that the playback is not done
according to the computer’s internal clock, thus the playback rate changes according to
computer load and hardware. (This problem is further discussed in the Conclusion
chapter)
 Adjust song location (seek time) in case of NCT synchronization during playback – In
case of an NCT update, the current seek time is adjusted as well. Again, due to the
nature of JMF not being real-time oriented, there was no way of assuring an exact seektime. Therefore this method is only performed if a “big enough” NCT update is done.
 Iterative Seek Time Algorithm (optional)– Even with the predicted lag time a close
enough seek time was not achieved. To solve this problem an iterative method was
used. After each seek (including initial play command), an indication of the current seek
time is retrieved. The current seek time is compared to the wanted seek time and a seek
time difference is calculated. If the seek time difference is “big enough”, a seek
command is issued again while taking into the account and compensating the seek time
difference. This is performed repeatedly until the seek time difference is “small
enough”.
18
Data Tier
The modules that are included in the Data Tier (for both the NCT and DMP) are:
o NCT Neighbor List
o DMP Neighbor List
o Song list
o Log
o Song
o User
Each of the above has a controller or an abstraction which allows easy access.
DMP & NCT Neighbor List & User:
The Neighbor List contains user information of the users which are connected to the NCT or
DMP network.
o
o
A User object contains the following attributes:
o User’s IP address & port - Allows communication initiation.
o User’s synchronization state – Whether this user was synchronized with during
current synchronization iteration (after a full iteration is performed, all users in
list are set as not-synchronized). The NCT User refers to Time and Neighbor List
synchronization while the DMP User refers to Neighbor List and Song List
synchronization.
o User’s connectivity state- Each time a user is unavailable, a counter is
incremented. After a certain times of being unavailable the user is deleted from
the list.
The Neighbor List Controller allows to retrieve details regarding a specific user, retrieve
a user which has not yet been synchronized with (in order to initiate a synchronization),
reset synchronization status when all users have been synchronized with (assuring that
all users will be synchronized each iteration) and to perform a union between two lists
(done when synchronizing the Neighbor List between two users).
Song List & Song:
The Song List contains song information of the songs available throughout the network.
o
A Song object contains the following attributes:
o Song File name – Used to refer to the actual media file for playback or to send
to a remote user.
o MD5 hash key- Used to differentiate between songs (especially songs with same
name).
19
o
o
o
List of owners- A List of Users which own the song. Used to find from whom to
retrieve a song which is unavailable locally.
The Song List Controller offers an easy interface to the MySQL database which stores all
the Song details. It allows to add new songs, add new owners to existing songs and
perform a union between two lists (done when synchronizing the Song List between two
users).
The Song List Controller, keeps a record of all temporary songs retrieved from remote
users, and deletes them upon exiting the DMP software.
Log:
The Log contains a record of all commands issued locally or remotely.
o
o
The Log controller offers an easy access to the text file implementation. (Log controller’s
capabilities are discussed in the Logic Tier chapter).
Refer to Appendix A as to the exact structuring of each Log entry.
20
Conclusion
One of the major let downs in our project was our inability to achieve a good enough
simultaneous playback. This was due to the fact that we did not take into consideration the
following issues:
 The time which passes between issued commands to the media player and the
actual playback.
 Machine type & Operating System effects- Playback rate and start time varies
between machine types and OS.
We attempted various methods to create a workaround for this problem (discussed in the Logic
Tier), but the results were still somewhat unsatisfactory.
We believe that in order to create a better DMP, a use of a lower level media player is needed,
one which offers near real-time control.
Another problem which arouse with the JMF, was that it retrieved different song duration for
variable bitrate mp3, between different OS. Therefore all tests we done using constant bitrate
mp3s.
21
Appendix A – The Log Structure
Following is a detailed description of the Log. The log is comprised of text lines. Each line
has the following structure:
Structure
Entry Structure:
<entry serial #> <data>
<entry serial #> -Entry serial number.
<data> - Command or Event, initiated or caused by a network member.
Entry Serial Number Structure:
<Entry ID> <Initiator MAC>
<Entry ID> - Entry's ID is set as the consecutive number with relation to the last entry's <Entry
ID> , inserted in the log (starting at 1).
<Initiator MAC> - Command or Event initiator's MAC number.
Data Structure:
<Dest ID><Event/Command Flag><Issuing ID><Issue Time><Received Time><Event/Command>
<Dest ID> - Destination member's ID. 0 for all members (Events will always be relevant for all ('0') )
<Event/Command Flag> - Flag stating whether the entry is an event ('EVENT') or a command
('COMMAND')
<Issuing ID> - ID number of member issuing the command or initiating the event.
<Issue Time> - 'Clock Time' the event/command was issued. Identical in all local logs.
<Received Time> - 'Clock Time' the event/command was received by the local log. Unnecessarily
identical in all local logs.
<Event/Command> - Content of Event or Command:
Possible Events:
A.
B.
C.
D.
'Member # has joined the network' – Issued by joining member (#)
'Member # has left the network' – Issued by leaving member (#)
'Member # has been disconnected' – Issued by 'Master' member.
'Song xxx starting' – Issued by 'Master' member.
22
E. 'Current_location XXX ' – Issued as a response to Get_Location.
F. 'Member # acting as Master' – Issued by new 'Master'
G. 'Member # playing Song_Name at Seek_Time' – Issued by network member.
H. 'Member # Synchronized Library' – Issued by Master member.
Possible Commands (For further details, see Protocol1.doc):
A. 'lib_sync ()' – The actual list will be held in a different file. The list will
contain for each song: Name of Song and Provider of Song ID# Relevance: ALL
B. 'SendLib(LibFile)' – Has two functions:
a. Member sending library file to master to synchronize with main
library file.
b. Master sending back to all synchronized library file.
C. 'get_songs (missing_song)' – Request for a certain songRelevance: Destination ID#.
D. 'Sync_Time' – Issued by 'Master' member, synchronized by the network.
Relevance: ALL.
E. 'Play/Pause/Seek (song, seek_time, exec_time)' – Issued by 'Master'
member.
Relevance: ALL.
F. 'Next/Previous(curr_location_in_playlist , exec_time)'– Issued by
'Master' member.
Relevance: ALL.
G. 'Get_location()' – Can be issued by any of the network members.
Relevance: Destination ID#
H. 'Get_Control()' – Can be issued by any of the network member.
Member will be granted control and set Master member if:
a. No Master member exist (only member in network) – Issuing
Member takes control immediately.
b. Current Master member is not in the process of issuing a command.
Relevance: Master Member ID
Set_Master(NewMasterID#) – Issued by 'Master' member.
Relevance: ALL
J. Get_Status() – Issued by entering member, wanting to synch t
K. Set_Status(SongName,Current_SeekTime,Execution_Time) – Issued
by Master member, informs requested member who is Master
member, what song is played, at what seek time, and when.
I.
23
Appendix B - User Guide
The Main Window:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Title and Computer name & IP Address.
Menu – Includes DMP, Neighbors & Debug
Library- Lists all songs available in the network
Playlist- Lists the songs which were added to the playlist.
Commands- Shows Last-Executed Command (in Red) and To-Be-Executed Command (in
Black).
The commands are written in Log entry format (see Appendix A for more details).
NCT – Displays the network time (Format HH:MM:SS.mmm)
Neighbors – Lists all users connected to the DMP network
Control Panel- Various controls for the DMP.
Player Status- Displays Status of the Media Player. Possible Status indication are as
follows:
a. Status – DMP loaded and no command has been issued yet.
b. Play – Media Player currently playing a song
c. Stop – Media Player stopped
24
d. Synchronizing – Media Player trying to synchronize play time to the wanted seek
time.
Menu:



DMP
o
Close- Exits DMP but without shutting down MySQL server. This allows faster
Shutdown & Load time.
o Exit – Exits DMP and shuts down MySQL server.
Neighbors
o Add – Opens a window in order to insert a new user’s IP address:
Debug
o View Log- Opens a window which shows the content of the Log text file (used
for debugging purposes only).
Control Panel:
_
1. Toggle whether to use the local synchronization algorithm to assure exact seek time.
This option might cause longer wait time before playback.
2. Local seek skew time (in seconds) – When a seek/play command is issued, the value
displayed will be added in order to compensate for playback start time difference
between different types of computers. +/- will add/decrease 0.1 second from the local
skew time.
25
3. Synchronize seek time – Pressing will cause the local player to attempt to better
synchronize the current playtime (according to current NCT).
4. Play selected file in the Library window and add song to playlist
5. Stop playback & clear playlist
6. Pause playback toggle
7. Play previous song in playlist
8. Play next song in playlist
9. Broadcast current local volume setting to network members. This will cause the entire
network to share the same volume configuration.
10. Adjust local volume. [0-Mute 5-Max volume]
Operations
Some common operating scenarios=
Song Play
Song has been selected & Play button pressed.
The Command has been added to the Commands window as to-be-executed.
26
Command moved to Last-Executed Command, Song added to Playlist and playback has started
27
User Joined Network
1. Previously shown songs which are located locally
2. Songs added to the Library by the remote user who joined the network
3. The remote user’s nickname is shown as well (Moran)
Upon joining, the remote user will start playback and the correct playtime according to the rest
of the network users.
28
References
1. http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf
Time, clocks, and the ordering of events in a distributed system (Leslie Lamport
Massachusetts Computer Associates, Inc.)
2. http://en.wikipedia.org/wiki/Multitier_architecture
Three Tiers Architecture
3. http://en.wikipedia.org/wiki/Observer_pattern
Design Pattern- Observer pattern
4. http://en.wikipedia.org/wiki/Decorator_pattern
Design Pattern- Decorator pattern
5. http://www.eclipse.org
Eclipse IDE
6. http://code.google.com/p/visualswing4eclipse/
visualswing4eclipse plug-in
29