Overview

• Task Description
• Requirements
• Assumptions
• Libraries and Tools
• Organization
• Initial Steps
• Time Plan and Milestones
• Groups and Support
• Subversion Repository
• Testbed Infrastructure
• Presentation and Evaluation
• Result
• Reports and Source Code

Task Description

This semester's challenge task (CT) is the design and implementation of a fully-distributed, P2P online radio. The system will be similar to a file-sharing application in the sense that people will be able to share music files. The difference is that no user interaction will be required while the radio is playing; the user will provide a starting point (for example, search for a song, an artist, or genre), and the system will starting playing music without user input (though optional input is possible). In order to achieve this, a playlist needs to be built automatically, based on songs that the user will probably like. Songs on the playlist will be downloaded from peers that are sharing them, and played back to the user seamlessly. Each group is free to decide about specifics of building the file sharing/streaming system and how to guess the user taste with a high probability.

Requirements

All requirements below must be met in order for the CT to be successfully accomplished.

• A user interface must be in place, not only to allow operation of the software, but also to visualize the undelying P2P mechanisms (e.g. messages being sent, data stored per node). Groups are, however, free to decide whether they want to implement a graphical user interface or a text-based one.
• The system must be robust to some peers leaving the system, since this is a P2P system.
• The solution shall be based on pure P2P mechanisms, that is, the solution shall not contain any central elements (trackers or servers). Every peer will run the same software and have the same roles.
• The solution may use existing libraries and code, but those must be allowed to be published under GPL or another comparable open software license.
• The final report, consisting of 10-15 pages, shall document the application.

Assumptions

The following facts may be assumed:

• Every peer bootstraps to a trusted, known peer.
• Up to 20% of the peers may fail unpredictably at any time, and the system needs to cope with that.
• Note: Further assumptions can be made according to each group's approach.

Libraries and Tools

The items below represent supporting libraries, tools, or references that are recommended to be taken into consideration.

• Use Java as the programming language. You should use the latest version, as this has usually more useful features than older versions. The J2SE Software Development Kit (SDK) can be downloaded under http://java.sun.com/javase/downloads/.
• The assistants know Eclipse well and the use of Eclipse is highly recommended. The most recent release of Eclipse can be downloaded at http://www.eclipse.org/downloads/. Eclipse is available for Windows, Mac OS, Linux and further platforms. If you prefer other IDEs (e.g. Netbeans) you may use them but without support from our side (i.e. good luck!).
• The use of TomP2P as a P2P overlay technology is highly recommended. TomP2P is an open-source implementation of the Kademlia DHT. More information can be found at http://tomp2p.net/. At http://tomp2p.net/doc/quick/ there is a quick introduction to the TomP2P library.
• Java material:Java Tutorial, Java ist auch eine Insel, Java API, Eclipse Dokumentation.
• A music (e.g. MP3) player, as well as an id3 reading libraries might be useful! Hint! Choose libraries that are stable, run some simple tests to choose the one that does well what you need.

Organization

• The groups shall be balanced. Every group shall have one Java expert. During the challenge task, the group shall meet every week during exercise hours to work on the task and discuss the next steps.
• The groups shall utilize their homework times to work on the CT, besides the exercise time slots assigned on Thursday.
• The groups shall determine and set-up an internal project plan with the overall milestones timings provided here.
• Distribute the workload so that each group member gets a fair load of work (P2P load balancing, no free riding!) and make sure activities can run in parallel (non-blocking).
• You can use your own laptop and/or the computers in room BIN 1.D.12.
• Don't miss the opportunity of discussing details with your group supervisor, he might give you good hints.

Initial Steps

In order to successfully achieve your goal, the following initial steps are recommended.

• Start by understanding what functionality needs to be present in the system.
• Read literature about recommender systems, think about creative ways to guess user preference in a fully-distributed environment.
• Understand how TomP2P works, what P2P methodology is used, how nodes are accessed, and what it can provide. Implement a simple example. This example does not need to be part of the solution; the goal is to get used to the API and see how the framework behaves.
• Research about which libraries can make your life easier.

Time Plan and Milestones

The challenge task includes three milestones on which specific deliverables have to be handed in to the supervisors:

• Milestone 1: Design your application. Specify use case(s), functional requirements, modules. Plan how nodes will communicate. Draw sequence diagrams for communication among nodes and inside nodes, among components. Design the protocol used for inter-peer communication. Present to the supervisor a detailed work plan including approach, task distribution among group members. By then, what and how the task will be done should be clear.
• Milestone 2: Build a UI prototype. Implement and test the P2P functionality, focussing mainly in the file sharing/streaming part. Present a draft report to the supervisor, consisting of a table of contents (ToC) and some bullet points on each section.
• Milestone 3: Continue implementation. Develop and refine the playlist building algorithm. Test and debug your application, make it ready for the demonstration. Hand in the final report, including assumptions, design, structure of code, and installation requirements.

The following table shows the time plan for the challenge task with the different milestones:

Groups and Support

During the challenge task each group will be able to ask questions and get support from their supervisors:

Subversion Repository

An SVN repository will be provided to each group. Each repository contains the suggested libraries and an Eclipse project.

The passwords are to be provided by e-mail.

Testbed Infrastructure

During the challenge task and for the final demo 10 Linux PCs (super fast Pentium 4, 2.8 GHz, 500 MB RAM) will be available during exercise hours in BIN 1.D.12. You may also bring your own laptops :)

Presentation and Evaluation

Challenge task presentations and demonstrations will take place on different dates. Groups 1-3 will present on Tuesday May 29, 2012 from 12.15 to 13:45, while groups 4-8 will present on Thursday May 31st from 14:00 to 15:45. On these dates, the groups will present and demonstrate their results, which will be evaluated by a jury. Presentations on both dates will take place at room BIN.1.D.12.

• Each group will have 10 minutes for presenting the approach chosen and design of the developed application. The presentation shall include slides. A white board and a flip chart can be used additionally.
• After presenting the approach and design, each group must give a 10-minute demonstration of the application. For the demonstration, you must run at least four instances (peers) on different machines. You can use your own laptops or the PCs in the room 1.D.12. Most of the demonstration, though, will be done using the machine connected to the projector, so more people can see what is going on. Ideally, it's the same machine that will run the slide presentation.
• Make sure that everything will work for your demo! Test everything beforehand with given conditions, especially the network. If a group fails to present within its 10-minute window, it will be disqualified.
• Remember that the audience will not only be interested in seeing whether or not your application works, but more specifically how the designed mechanisms for file sharing and recommendations work behind the scenes. So it must be visible what these instances are doing; the UI must clearly show, for example, what messages peers exchange, which keys/values they store and query, and how the recommender system takes the necessary factors into account for building a play list. This can be achieved, for instance, by using a log file and tail -f.
• After the demonstration, each group will be evaluated by the jury.The jury is composed of lecturers and assistants, and each member will cast one vote per group. The following criteria will be taken into consideration: software design and implementation (fulfillment of requirements, overall design, trade-offs considered, scalability, usability, quality of recommendations), team work, presentation and demonstration of the solution. The results of the votes will be collected and disclosed after the last presentation. The winning group will receive a symbolic prize and the "P2P Challenge Champion 2012" award.

Result

Thanks to all participants for the hard work and very interesting presentations and demonstrations. Congratulations to Group 4 for winning the P2P Challenge Champion 2012 award, as well as Group 6 for being the runner-ups!

Reports and Source Code

Please find below the report and source code of each group for download. Source code is licensed under GPL. In case of questions, please contact the respective supervisor.