Challenge Task 2017

This semester's challenge task (CT) is the design and implementation of a fully-distributed, P2P messaging application. The system will be similar to a instant messaging application such as Bleep, Signal, or Telegram, where users are able to message 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 messages when they go online (at any time).  Each student's group is free to decide about specifics of building the P2P messaging application and how to organize the information within the distributed network.
Challenge task presentation (PDF, 494 KB)
Scrum introduction (PDF, 2 MB)

Scrum, part 2 (PDF, 525 KB)

Scrum, part 3 (PDF, 525 KB)

The TI&M Scrum Garage Tour happens on the 11.05.2017

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. Send messages, notarial certify with a notary service , only some  messages need certification.
3. Business case , find and implement an interesting business case.

Further requirements 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 online 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 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.
• Ethereum is the most popular public blockchain for smart contracts. The supervisors use familar with geth
• Java material:Java Tutorial, Java ist auch eine Insel, Java API, Eclipse Dokumentation.

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 June 1st 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 in room BIN.1.D.25 / BIN.1.D.12.

• 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 machines 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 messages, 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 send messages. 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 (fulfilment 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  prize and the "P2P Challenge Champion 2017" award.

Result

Winner CSG-award: tba

Winner TI&M-award: tba

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 / source code

Group 2: report / source code