Google summer of Code 2012
For the year 2012 the Ninux.org community decided to participate to Google Summer of Code (GSoC 2012).
About the Google Summer of Code
Here some info on GSoC
Google Summer of Code is a global program that offers student developers stipends to write code for various open source software projects. We have worked with several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Since its inception in 2005, the program has brought together nearly 2500 successful student participants and 2500 mentors from 98 countries worldwide, all for the love of code. Through Google Summer of Code, accepted student applicants are paired with a mentor or mentors from the participating projects, thus gaining exposure to real-world software development scenarios and the opportunity for employment in areas related to their academic pursuits. In turn, the participating projects are able to more easily identify and bring in new developers. Best of all, more source code is created and released for the use and benefit of all.
- Google summer of Code 2012
- About the Google Summer of Code
- GSoC Project Ideas 2012
- More Info
- Saverio Proto
- Lorenzo Bracciale
- Marco Giuntini
- Federico Capoano
- Gioacchino Mazzurco
GSoC Project Ideas 2012
The goal of this task is to push forward the development of Nodeshot in order to make it mature, stable and more flexible. The final goal is to promote this software so other wireless communities around the world can start using it and participate in the development. At the moment this is only partially possible because the software is not very flexible and has been developed to satisfy our needs only.
- Integration with django's user management framework (django.contrib.auth.user) and permission system
- Easy registration and login
- Possibility for admins and users to login in the frontend and be able to perform different actions depending on their privileges (eg: some info might be configurable to be seen by a certain group of users only)
- Improve the graphical user interface
- Email app to ease the communication with node owners (possibility to send an email to all the nodes, possibility to send an email to only a group of nodes)
- Possibility to use placeholders for distance calculations on the fly
- New overviews with IP addresses
- Better DB abstraction, eg: differentiation between different types of devices (antennas, servers, others)
- Integration with traffic statistics
- Better caching system
- History for all the changes in the database
- Mobile version
Integration with Layar - we already have a php script, we will just need to port it to python/django => Possibly find an open alternative to layar
- Better notifications, 2 examples:
- Possibility for non-admins to receive notifications when new potential nodes are added
- Possibility to be notified if new potential nodes are added in a specified distance range (eg: notify me if a new potential node is added in a range of 10km)
Permit nodes configuration from nodeshot ( http://nnx.me/eigenfirmware + UCI + SSH? - this needs to be in a separate app)
- Better SNMP monitoring (at the moment we support only Ubiquiti devices)
Visual traceroute & graphs
DNS Management App for wireless communities
We implemented our own DNS system in our community which is integrated with the map-server. At the moment the integration is more like a temporary hack and not a piece of good software. We would like to separate this functionality and make it an indipendent application that can be integrated easily into the map-server but also run in standalone mode. The Goal is to make a system which calculates the hostnames of the nodes automatically but also give the possibility for community networkers to manage their own DNS records indipendently (each node owner should be able to change his/her hostnames or add new ones).
- Backend web interface for administration
- Frontend application in which each node owner can manage hostnames of his/her node
- Standalone mode
- Pluggable mode (integration with Nodeshot)
- Integration with Opensource DNS software (PowerDNS, myDNS, ecc)
Distributed node monitoring and management application
We use different monitoring systems but we are not completely satisfied with any of them.
Problems we face:
- Different monitoring systems are hard to mantain. When we change anything in our network we have to remember to change also the information in all the systems we use
- One of the systems is proprietary, closed source and it works with only with a very limited set of devices
- We need to be able to diagnose problems quickly with a cross check on different protocols (SNMP, OLSR, BATMAN)
- We need more flexibility
- We need a decentralized system
- We want it Open Source
Solution proposed: Develop a new pluggable distributed app for the map-server which can be deployed in different parts of the network which automatize the synchronization of the operations and eases our pain in the management of our network.
Videoconferencing suitable for Mobile Phone and Mesh Networks (MPMN )
Many people want to use VOIP in our mesh network but they step into some problems:
- Existent major videoconferencing solutions depend on the Internet ( like skype or gtalk )
- Most of major existent videoconferencing solutions have not a good mobile phone integration ( like skype )
- Most of major existent videoconferencing solutions doen't support ipv6 ( our network is primarily ipv6 )
- Internet bandwidth on our network is going towards exhaustion
- They doen't want to learn to use another VOIP app
To solve these issues we decided to implement Videoconferencing suitable for Mobile Phone and Mesh Networks:
- Create a good app, fully integrated in android/iphone/(other?) addressbook ( call someone trough MMPN must me simple as call him with phone number without learn to use other apps or have different gui).
- Separate MMPN backend from addressbook integration ( like telepathy framework do on desktop ).
- Make the backend extensible for newer protocols
- Offer good privacy with encryption
Type of Work: Coding Level 4 Semi-Professional
Collaborative Music Composition
This project aims to realize a web-based social application for music composition.
It will allow the creation of jam session (non real-time) in this way: users will upload tracks (e.g. piano track) and then they can merge them with other tracks (e.g. bass track) putted in the system by other user. Users could play a bunch of selected tracks creating a composition (e.g. bass+piano+vocal).
Using the linux audio plugin and a proper backend engine, they can also apply effects on tracks.
Conversely, if a user don't like an instrument track of a song, he can create his version by substituting with his own track.
It will use a web framework such as Django to manage users, file upload and dynamic content.
On the backend it will handle files using linux programs. It could add effects (such as reverb or delay) on tracks by interfacing with a LADSA compatible command line script. In this way we will reuse the tons of linux audio plugin.
- Every track is under a kind version control (git or whatever) so to keep track of branches and merges.
Improve the OLSRd mDNS plug-in
The OLSRd mDNS plug-in allows the distribution of mDNS (multicast DNS i.e. avahi/bonjour/zeroconf) messages over an OLSR network. This is substantially achieved by sniffing for mDNS packets on the final users' networks (usually HNA networks), encapsulating them inside OLSR protocol messages, exploiting OLSR native message transfer mechanisms, and decapsulating the mDNS packets at all the other end users' networks.
The plug-in has been developed by ninux.org, however we would like to address some important issues that have arised during deployment:
loops. If two mDNS plug-in enabled OLSR routers are attached to the same HNA network, then mDNS packets will loop back and forth between the two, also flooding the whole OLSR network. For the moment the temporary solution to this problem is to enable the plug-in on one router at a time on the same HNA. A real solution to the problem would be the following:
- usually mDNS packets have a TTL != 1, so:
- capture only mDNS packets with TTL != 1
- when decapsulating mDNS packets, set TTL = 1
- where TTL is the IP Time-to-live field
capture rate. mDNS packets are incapsulated into OLSR messages, which in turn are contained in OLSR packets that are sent at the wireless basic rate (i.e. 1 or 2 Mbps) over the whole network. Thus a big amount of mDNS captured packets in a small time can slow down the whole network. A solution to this is to add a plug-in configuration option to set the maximum packet capture rate.
About GSOC 2012: http://www.google-melange.com/
Info about ninux participation on previous years:
If you are interested to participate please contact