Language

Search

Welcome to P2PSP Google Summer of Code (GSoC) 2017 project ideas page. We will use this page to develop possible project ideas. Please note that anyone who is interested can participate in this process. You do not have to be a GSoC student or mentor to suggest possible project ideas. If you want to suggest an idea, please, send an email with the subject "GSoC 17 Ideas" to info [at] p2psp.org. You can also join the team at GitHub, chat on Gitter and subscribe to the mailing list.

Explanation: At its current state, the Splitter - which handles the team of peers - needs to be connected using an IP and Port which must be either fixed or previously agreed for both streaming video and peer connection. Which we want to accomplish here is to have a wrapper WebService that can receive the video through an HTTP request - or any other way that can easily get through NATs-, create an Splitter instance and redirect the video to it, assigning a 'friendly URL' to it that can be easily shared. When this URL is visited, it will reply with the IP and port that the peers need in order to connect to the Splitter.

Expected deliverables: A REST web application that will dynamically create Splitters, receive the video and redirect it to the correct Splitter, assign URLs to them and reply to those URL with the IP and port needed to connect to the team that the Splitter runs.

Explanation: We want to offer an evolution of this experiment (https://youtu.be/R7035-XaZd4). A virtual room where friends share videos among them in real time directly over the web browser, with synchronized playback and a video chat at the same time. It is like to be in the same room watching a movie but in a virtual way. Browsers are connected each other over a P2P overlay (using WebRTC), this means that we have a private communication, without going through a server. It's a browser-to-browser connection.

Expected deliverables: A website where an user can share a video with his friends in real time, with synchronized playback and they can have a video chat at the same time. All of this over a P2P overlay.

Explanation: Create a simulator of the P2PSP protocol using Thread and message passing in order to do the prototyping of new strategies easier. If we use Python, we can use Queue class. It’ll be very useful!

Implementation of the Data Broadcasting Set of Rules (DBS) of P2PSP as a HTML5+WebRTC application. 1

Explanation: Today, the Web browser is an indispensable tool to access information available on the Internet and HTML is the language used to describe the Web objects the browser interprets and displays to users. One of the most interesting additions in HTML 5 is the <video> label which enables the playback of a video embedded in Web pages. This possibility has open a range of multimedia applications and avoids the need of third party software to handle multimedia. This project proposes the implementation of the a client (peer + player) using HTML5+WebRTC.

Expected deliverables: A SplitterWebRTC C++ class that inherits the SplitterDBS class defined in splitter_dbs.h implementing the WebRTC funtionality and a new P2PSP client build-in web browser.

Explanation: This project addresses the implementation of a statistics module for P2PSP that records information related to the stream, number of peers (audience) per minute, in/out of peers, total peers, etc. That set of data must be displayed a convenient graphical interface. A very interesting extension is to consider also the use of social sign-in (Facebook, Twitter, Google+).

Expected deliverables: An application that displays graphs of all data recovered.

Implementation of the Internet Gateway Device Protocol for NAT traversal.

Explanation: Some "routers" runs this protocol allowing a local UPnP client to add and remove port mappings, among other thigs. Thus, a P2PSP peer behind a IGDP NAT can enable NAT traversal.

Expected deliverables: A C++ SplitterUPnP class that inherits the SplitterDBS class of splitter_dbs.h and a C++ PeerUPnP class that inherits the PeerDBS class of peer_dbs.h, both implementing the techniques described in the IGDP.

Explanation: Chromecast is a digital media player developed by Google which can be connected to a TV. This idea consist in adding the option "send to chromecast" to the P2PSP GUI (See 11). This option should send the stream from a desktop application to Chromecast. Note that the player controls are held in the desktop version.

Expected deliverables: A new module for the GUI with Chromecast support.

Explanation: A Chromecast device can run a P2PSP peer and a player using the WebRTC framework. This idea depends on the success of idea number 2, but after that, a minor programming effort should be performed.

Explanation: Mobile phones are indispensable devices nowadays and the Android ecosystem is one of the most popular on smartphones, tablets and others multimedia devices (Android TV, Nexus players, etc.). This project proposes the implementation of the core of the P2PSP for Android devices as a native application.

Automatization of the deployment of a P2PSP team (or a part of it) over the PlanetLab infrastructure.

Explanation: The PlanetLab is a network of public (Linux) hosts exclusively dedicated to the development and performance measurement of communication protocols. The idea of this project is to automatize as much as possible this task, enabling the deployment and evaluation of hundreds peers.

Expected deliverables: A script deploying a P2PSP team over PlanetLab.

Explanation: A channel is associated to one or more splitters that stream the same content, in a synchronized way. In order to achieve a good load balancing among the splitters of the same channel, a tracker could determine (depending on the number of peers, for example, in each team) the a free splitter (team) and redirect the incomming peer to it.

Expected deliverables:A standalone application (written in a portable language such as Python or C++) which implements the previously described behaviour.

Knowledge prerequisites: Socket programming and a good understanding of P2PSP.

Explanation: Most defense algorithms against pollution and free-riding attacks rely on to know the number of attackers. In this project we will check the performance of some techniques that have been proposed to address this problem (such as the mathematical inference) and we will develop an estimator for that variable

Expected deliverables: A Python class that using the information provided by the splitter, will produce an estimation for the number of malicious peers that attack a team.

Explanation: The current splitter divides the code-stream into blocks (chunks) of the same size and that size usually does not match with the native block of the video (for example, in H.264 exist NAL units, in Theora there are pages, etc). Therefore, if a chunk is lost (in the current implementation), even if it is two bytes long, two blocks of video could be affected. To solve this drawback, this idea proposes to modify the implementation of the splitter available at: https://github.com/P2PSP/p2psp, in order to use a chunk size suitable for the media transmitted. The incorporation of such functionality should be provided as a "pluging".

Explanation: This idea is an extension of implemented idea 7 (see below). Add support for other cameras like SJCAM (the more the merrier). Maybe would be possible to add more streaming platforms like twitch or Twitter.

Explanation: It not easy to test if a modification in P2PSP has the expected impact. For this reason, we propose to write a Bash script which is able to create a team on a single host, run it and provide statistics about its performance (lost chunk ratio, for example).

Explanation: The synchronizer entity can be used by peers to receive (the same) media from two or more team, simultaneously. In this idea, we propose to extend the functionality of the synchronizer to allow a peer to move between teams in a seamless manner.

Design and Implementation of a new source video from mobile phone (Android).

Explanation: Mobile phones are nowadays present in everyone's pocket, meaning that there is a camera at virtually any populated place in the world. Giving users the chance to share what they are watching live with the rest of the world seems to be a good idea and is a natural application of the phone+Internet combination. On the other hand, P2PSP is a minimal (easy to implement) protocol designed for the streaming of media (audio and video). At the present time, there is a working Python implementation available at Launchpad. We propose the development of an Android app that captures the video of the camera and sends it to a streaming server (possibly Icecast) on real time. From there, P2PSP distributes the stream to the rest of the world.

Expected deliverables: An application for Android that captures the video of the camera and send it to a streaming server (icecast) in real time.

Implementation of the NAT Traversal Set (NTS) of rules of the Peer-to-Peer Straightforward Protocol (P2PSP).

Explanation: Another important aspect for improving P2PSP is that peers behind NATs can run with some form of restricted access from the outside. This set of rules defines how to provide this functionality.

Expected deliverables: A Python class that inherits the Splitter_DBS class of splitter.py and a Python class that inherits the Peer_DBS class of peer.py, both implementing the techniques described in the NTS.

Explanation: In the P2PSP system it is necessary a method to avoid attacks consisting on the injection of fake information into the team. An attacker can do this by sending poisoned chunks. A way to tackle this problem is by inserting one o more “trusted-peers”. These peers are authenticated as trusted to the splitter, but not to the rest of peer (the behavior of a trusted-peer is identical to any other peer making impossible for a poisonous peer to know these special peers). The source sends to the trusted-peers a hash code for every chunk sent to the team, using a reliable transmission protocol. Alternatively, hash codes for randomly chosen chunks are sent to the trusted-peers (note that the poisonous peer is not aware of which chunks were selected). If a poisonous peer sends an altered chunk to a trusted-peer, it will detect the change using the hash code and will notify the source, which will eject the poisonous peer from the team.

Expected deliverables: A Python class that inherits the DBS class of splitter.py and a Python class that inherits the DBS class of peer.py, both implementing the techniques described in the DIS of rules.

Design, implementation and integration of a graphical user interface for the Peer in the P2PSP python implementation.

Explanation: There already is a working implementation in Python but it does not have any integrated GUI, so the user must run a player separately. The purpose of this work is to use LibVLC (a media framework that embeds the features of VLC into an application) to integrate a peer and a player into a single executable. However, any other suggestions about multimedia libraries are welcome. The P2PSP source code is available at https://launchpad.net/p2psp. You can find more information about LibVLC and Python in https://wiki.videolan.org/PythonBinding/. The code must be documented with Doxygen.

Expected deliverables: A single executable integrating a GUI, a player and a P2PSP peer.

Explanation: Action cameras are becoming popular. We think that create a gateway between the camera and Internet is a interesting thing. So, in this project we propose create an app for mobile devices that use the GoPro camera as a source and send the stream to the Internet. It could be sent to a P2PSP splitter, Youtube, Icecast, etc.