Visit forum
Forum search "MasterThesisAtTribler"
Discuss "MasterThesisAtTribler"

Do your MSc thesis assignment within the Tribler team ?

Please contact Tribler coordinator Dr. J.A. Pouwelse on the 9th floor of EWI or via email.

Possible topics

We are a group conducting experimental P2P research. All members of the Tribler team have at some point to show that their algorithms work, what their performance is, and how they can be improved. All possible tasks expand the existing work or ongoing research with operational Python code. Here are some ideas:

• Create a real-time text/video/audio edit and sharing tool scalable to millions of users by using P2P technology to create a blend of SubEthaEdit, Google.Wave, and Twitter. hardcore researchers only
• TCP rate control implementation in user space with Python on top of UDP message transfers. hardcore developers only
• Port Tribler to NetworkMediaTank? Media Player box and devise an intuitive remote control interface. example NMT extension project.
• Software engineering excellence and stability: system testing, test code coverage, structural bug hunting. Ensure our P2P multimedia engine is stable for years and suitable for standardisation in HTML5 and DVB and Television inclusion. Move beyond unit testing. Cooperation of P2P team with software engineering department, Dr. Martin Pinzger.
• Port the live Bittorrent streaming code of Tribler to a TV settop box, such as this Open Source Hardware platform with an ARM9 multimedia core.
• Extend HTML5 with deep integration of our Tribler P2P engine in Firefox. The new HTML5 video element supported in Firefox would then be able to download using P2P by expanding our BrowserPlugin. This mean a web page can contain both server-based pictures and video and swarm-based multimedia content.
• The task is to build a proof-of-principle blogging tool which merges the best of Bittorrent with the web, called BittBlogg. Key is that BittBlogg uses a zero-server P2P architecture to download HTML and publish content. BittBlogg can read both existing blogs on central web servers and Bittorrent-based blogs using simple screen scraping techniques and P2P downloads. BittBlogg consists only of three screens, main keyword search page (like Google frontpage), search results, and actual blog posts. A first prototype would use the simple WxHTML function to display the blog posts. A more advanced prototype would use the Webkit lib to render HTML, load pictures, and execute JavaScript.
• Create a stunning real-time visualisation of Bittorrent swarm dynamic such as Digg example other examples
• P2P Widgets: The Internet is your Operating System and provides you the code to execute
• Live playlists which download Bittorrent content on-demand
• Craft a P2P Radio by generalizing the Video-on-Demand features and expanding with Last.fm functionality
• Scientific document search and publications e.g. uses Tribler to discover .pdf files and supports keyword search with a simple interface such as http://scholar.google.com/, http://citeseer.ist.psu.edu, and the richer http://www.citeUlike.org.
• Running Tribler from a USB stick with crypto and modify Tribler to transfer Bittorrent messages only inside HTTP GET image.jpg requests plus stenography
• Create a modified user interface for a TV screen, remote control operation, and PS3 hardware
• Numerous attempts have been made to use P2P to enhance web browsing. The task is to generalize our running code for acceleration of Web 2.0 multimedia content towards any URL. This is done by linking browser caches with P2P and clustering various URLs into a single Bittorrent swarm. For this the Tribler software must be linked inside a browser plug-in.
• Chat integration using Jabber and XMPP to strengthen the social network features. The challenge is to craft a zero-server implementation by making the central chat server redundant. Enable Tribler client to talk to the other client supporting chat. Existing XMPP Python code: here1, here2, and here3.
• Emotion-based video content retrieval.
• Effective and scalable real-time recommendation. The overlay network of Tribler is founded on the concept of user similarity. The currently implemented function is too computationally expensive and does not perform well because of sparse data. Can you develop a fast, scalable and function method to derive the similarity between Tribler peers and the available content? Similarity Project
• Expanding the P2PSimulator with ideas such as emperical datasets, novel algorithms, tagging, etc.
• P2P GeoWidget?: create a generic module for P2P map reading by P2P caching of Google Maps. Uses P2PWidgets as the application framework. Usefull for offline map reading on mobile nomadic devices (iPhone, G1, ..) and as a building block for other widgets using maps.
• Automatic Debugging of Tribler software
  Software pervades in every aspect of our society. A sharp contrast to the potential blessings of this development is the looming software complexity crisis. At present, complex systems already require millions of lines of code. It is becoming apparent that under the current traditional IT paradigms this huge complexity makes it impossible to deliver software that provides system capability, correctness, and availability, at any reasonable cost. Moreover, there will not be enough skilled IT professionals to design, test, debug, install, configure, operate, diagnose, and maintain such complex systems, assuming such tasks will stay within human ability to begin with. A good example is software debugging of complex software, where a huge amount of resources are spent to uncover defects. A novel approach to software debugging is to use software fault localization (SFL) tools that aid the developer in finding the root-causes of failures. Although SFL is still in its infancy, recent results have shown its great promise as a technique to automatically track down software bugs, providing the developer with a list of the software localtions that are suspect. The aim of the MS project is to assess the value of SFL for the Tribler software stack. Tasks involve automatically instrumenting the software stack, running the stack with known faults thus obtaining profile data, analyzing the profile data using SFL algorithms to see if the faults can be localized, and analyzing the reasons behind the measured debugging performance.

Planning and additional information

More information: TUDelft info page

As Tribler is an experimental research group an msc thesis project usually follows this pattern: detailing of a new idea or problem description, detailed design of a novel solution/algorithm, implementation and performance evaluation. Generic planning for a 9 month timeline:

  Month 1  One page problem description read all relevant literature (seperate literature study?)
           This text will grow and be included in the final thesis
  Month 2  Development of possible solutions
  Month 3  Details of possible solution or perhaps proof-of-principle prototype
  Month 4  Several pages with final architecture and design
           This text should be in a suitable format as a thesis chapter
  Month 5  Development of a prototype and determine which performance graphs can be generated
  Month 6  Development of a prototype and initial writing of implementation thesis chapter
  Month 7  Performance measurements
  Month 8  Expand thesis + detailed measurements
  Month 9  Final thesis writing

Literature research project planning (in Dutch)

Mogelijke Onderzoekstaak planning

Wk_0 Kick-off meeting orientatie Afstuderen:
 Student geeft cijferlijst van behaalde vakken;
 Docent stelt 3 verschillende opdrachten voor;
Wk_1 Focus meeting:
 Student geeft gemotiveerde keuze voor 1 opdracht en
 start literatuur onderzoek;
 Docent geeft meer vakinghoudelijke informatie
Wk_3 Onderwerp afbakening:
 Student overlegt een lijst met gevonden literatuur;
 Docent bepaalt of het onderwerp te breed of te smal is.
Wk_5 Draft literatuurlijst:
 Student heeft uitgebreide literatuurlijst gevonden en gelezen;
 Docent geeft feedback over taxonomie en prioriteiten.
Wk_7 Draft literatuur classificatie:
 Student heeft complete literatuur ingedeelt en weet wat de
 onopgeloste problemen zijn;
 Docent geeft feedback en vertaling naar hoofstukken.
Wk_9 Draft van onderzoeksverslag
 Student overlegt een compleet literatuurverslag en
 "research challenges" sectie;
 Docent geeft feedback en verbeterpunten
Wk_10 Inleveren onderzoeksverslag
 Student levert verslag in en geeft aan welk
 gevonden probleem intressant is voor afstuderen;
 Docent evalueert de afgelopen 10 weken.