The following table shows the time plan for the challenge task with the different milestones:
|12.03.||Challenge Task and Scrum (PDF, 2 MB) Introduction|
|19.03.||Work on CT and Scrum Follow-up (PDF, 491 KB)|
|26.03.||Work on CT and Scrum Follow-up (PDF, 711 KB)|
|02.04.||Work on CT|
|16.04.||Work on CT and Scrum Follow-up (PDF, 498 KB)|
|23.04.||Work on CT|
|30.04.||Work on CT and Scrum Follow-up (PDF, 662 KB)|
|07.05.||Work on CT|
|14.05.||Ascension Day / Auffahrt|
|21.05.||Work on CT|
|26.05.||Presentations (room: BIN-2.A.10)|
|28.05.||Demos (room: BIN-1.D.12): challenge award|
The P2P Challenge Task for the FS15 semester is to design and prototypically implement a file system using P2P concepts. The P2P file system shall allow a user to read, write, and delete files. The P2P file system should be accessed using FUSE (file system in userspace). For consistency reasons vDHT should be used and a conflict resolution strategy needs to be implemented (vDHT will be discussed in lecture 6, on 24.03.2015). It can be assumed that the file system runs on a cluster, however, a machine in this cluster can go offline at any time.
The P2P file system should be able to do the following:
- Add, modify, delete, read, move files (basic file system operations)
- Mount file system with FUSE
- Shutdown 10% of the machines with no impact on the file availability
All requirements below must be met in order for the CT to be successfully accomplished.
- 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 using a structured overlay network
- Multiple Peers and Robustness: The solution shall enable access from multiple peers and the solution shall be robust against peer or link failure
- Create, modify, delete, and read files that can be mounted via FUSE
Further requirements are:
- Library and tools: The solution shall be based on libraries and tools which allow for publishing under APL or another comparable open software license
- Application report: The application report shall document the application. The report shall have 5-10 pages.
- The demonstration will run on 10 - 20 Raspberry PI like devices. Make sure your solution works on these devices.
Optional requirements are:
- User access rights and encryption
- Time-based files (self destroying files)
- Support for delta changes when modifying data
- Extend the P2PFS to a distributed revision control system
- The groups shall be balanced. Every group shall have at least one Java expert
- Agile/Scrum: the groups shall use Scrum and agile methods for software development
- Distribute the workload (P2P load balancing) so that each peer gets a fair load of work.
- You can bring your own laptop and/or use computers in room BIN 1.D.12
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 Java7.
- 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. If you prefer other IDEs (e.g. Netbeans or IntelliJ) you may use them but without much support from our side.
- 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 github there are examples of how to use the TomP2P library.
- For FUSE mounting, https://github.com/EtiennePerot/fuse-jna is recommended.
During the challenge task each group get support from their supervisors or if its a Scrum releated issue, from Marc Weber:
|1||Jan Meier, Henry Raymond, Benjamin Bürgisser||TB/AL|
|2||Riccardo Patane, (Michael Spring), Anvar Tukhvatulin, Livio Sgier||TB/AL|
|3||(Samuel von Baussnern), Reto Wettstein, Raphael Matile, Christian Tresch||TB/AL|
|4||Sven Brunner, Stefan Bublitz, Sacha Uhlmann||TB/AL|
|5||Christine Graff, Doru-bogdan Veres, Eni Duka||TB/AL|
During the challenge task and for the final demo 18 Linux PCs (Intel Core i7-3770, 3.4GHz, 8 GB RAM (DDR3, 1600MHz)) will be available during exercise hours in BIN 1.D.12. Later on, we'll also have 10-20 Raspberry PIs 2. You may also bring your own laptops :)
Challenge task presentations and demonstrations will take place on different dates. Presentations will be on Tuesday May 26th from 12.15 to 13:45, demos will be on Tuesday May 28th 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 will take place in BIN.1.A.10 and demos 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 15-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 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 15-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 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 2014" award.
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.
|Group #||Supervisor||Report||Source Code|