Challenge Task 2016

This semester's challenge task (CT) is the design and implementation of a fully-distributed, P2P Video and Voice over IP application. The system will be similar to a video and VoIP application such as Skype, where users are able to call other application's users. The application should have the notion of a contact list composed of friends. A friend is defined as being another application's user that accepted to appear within a respective user's contact list -- therefore the friendship is bi-directional, meaning that users should send requests to other users asking permission to be added. Once the permission is granted, the specific user becomes available in the contact list. Moreover, a user should be able to chat with one or more friends (supporting group chat) when the respective users are online. In order to achieve this, the user's contact lists as well as the user's status (online or offline) should be stored in a distributed manner. Optionally, the application should be able to support offline messages, meaning that offline users are able to receive either chat or short voice messages when they go online (at any time). Another optional task is to build a fully decentralized VoIP-out service that works with Bitcoins. Each student's group is free to decide about specifics of building the P2P VoIP application and how to organize the information within the distributed network.
Challenge task presentation (PDF, 487 KB)
Scrum introduction 1 (PDF, 2 MB)
Scrum introduction 2 (PDF, 601 KB)
Video/Audio Codec, see the AudioVideoExample.java
The TI&M Scrum Garage Tour happens on the 19.05.2016

Requirements

All requirements below must be met in order to not get any grade reduction.

1. Full Decentralization and P2P mechanisms: The solution shall not contain any central elements (besides bootstrapping peers) and the solution shall be based on peer-to-peer mechanisms. Any peer can be used for bootstrapping. The solution shall enable access from multiple peers and the solution shall be robust against peer or link failure.
2. Video call with another peer.
3. Indicate missed calls, asynchronous chat messages, find friends.

Further equirements are:

• The solution may use existing libraries and code, but those must be allowed to be published under APL or another comparable open software license.
• The final report shall document the application.

Assumptions

The following facts may be assumed:

• Every peer bootstraps to a trusted, known peer.
• Up to 25% 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 (Java8), 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/. Features that are of particular interest is the new file notification API built into Java8.
• The assistants know Eclipse well and the use of Eclipse is 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.
• 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.
• Opus Library

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.
• Do not miss the opportunity of discussing details with your group supervisor, he might give you good hints.

Groups and Support

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

Presentation and Evaluation

Challenge task presentations and demonstrations will take place on May 26th from 14.00 to 16:00. On these dates, the groups will present and demonstrate their results, which will be evaluated by a jury. Presentations and demos on dates will take place at room BIN.1.D.25.

• Each group will have ~30 minutes for presenting their design and to demonstrate the working application (roughly 15 min presenting and 15 min demo). The presentation shall include slides. A white board and a flip chart can be used additionally (possibly we can organize a second screen). For the demonstration, you must run at least four instances (peers) on different machines. You can use your own laptops or borrow Odroid C1s or laptops from the CSG. Most of the demonstration, though, will be done using the machine connected to the projector(s), so more people can see what is going on. Ideally, it is 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 time 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 VoIP calls, contact list storage, and chat messages 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, how the application deals with users being online or offline, and how two users are connected to establish VoIP calls. 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, reliability of calls and chat messages), 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 2016" award.

Result

Winner CSG-award: Andreas Knecht, Oliver Leumann, Alireza Amiraghdam, Marc Heimgartner

Winner TI&M-award: Fabian Hegglin, Stefanie Ziltener, Stephan Mannhart

Reports and Source Code

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

Group 1: report (PDF, 538 KB) / source code (ZIP, 476 KB)

Group 2: report (PDF, 2 MB) / source code (ZIP, 961 KB)