SourceForge Logo

Bugster version 0.1

What is it?
Bugster is a P2P application to share MP3z/OGGz over a shared network. The interface being similar to that of Edna. The bugster daemon is started on system bootup or otherwise. It listens on port 6666 and serves songs. It also hunts for neighbouring bugs and provides a singular interface to multiple bugs.

It's incomplete as of now. It's being developed on RedHat Linux 6.2 (and 7.0). Please see the TODO.

How it works?
On system bootup or otherwise, the daemon should be started (through /etc/rc.d/init.d/bugster or otherwise). The main() starts two threads, one to serve songs and other to hunt for neighbouring bugs. As and when the "bugs" (the bugster daemons) are discovered, a link list maintaining list of "alive" bugs is updated. The interface provided to the bugster daemon runs on port 6666. This is a mini web server which will serve songs. If you have seen Edna - the MP3 server, in action, then the interface is very much like Edna but additional section 'Other bugs'. So the interface looks like -
* Aerosmith-Crazy.mp3
* Richard Marx-Hazard.mp3

* PinkFloyd

Other Bugs
Further, though, not implemented as yet, like in Edna, there would be 'Play all songs (recursively)' and 'Shuffle all songs (recursively)' or 'Play all songs' and 'Shuffle all songs' as the case might be.

Like Edna, a combination of Lynx and .mailcap, should be able to browse through the song listings at port 6666 (lynx http://localhost:6666/). The same interface should be available using WinAMP or RealPlayer. As of today, I don't know any other option to browse through the MP3z.

Maybe, in future, a command line interface is written to browse through the songs. For eg, when starting up, the command line inteface (CLI) will present a prompt, which can accept commands like 'ls', 'play', 'hunt', 'cd' and 'connect', each of which mean, listing the songs available in the current directory at the current host, requesting a song to be piped to mpg123 or similar command line MP3 player (configurable), hunting for other neighbouring bugs, changing directory and connecting to a remote bug.

Configurable Parameters
The following are the entries in the configuration file (/etc/bugsterrc).

This is the topmost directory visible to the user. When somebody connects to the port 6666, the bugster daemon dynamically generates a page listing the songs, directories available in this directory and information about known bugs. The index.html and other .html files are ignored.
This is unused and will be removed in succeeding versions.
This is the userid who will own the server thread. Currently, the bugster daemon starts off as root, switches to user nobody (by default) for serving songs and stays as root for the hunting thread. This is because, for pinging IP addresses, a socket of type SOCK_RAW is needed which only the root can create. It is possible to create the socket of type SOCK_RAW and give up privileges and thus making the server more secure. This again will be done in succeeding version.
This is location of the log file. Currently, there is no logging. By default, the access and error messages will be logged using syslog.
These are all unused for time being. This will be useful when security features are implemented. For eg, if somebody wishes to restrict the access to a particular directory of songs.
These are unused too and will be removed. The initial idea was to allow the local user to play the songs directly without going through the server. But currently, even the local user has to connect to port 6666 to play songs.

What is hunting? How does it hunt for bugs?
Currently, a very stupid "algorithm" is used to hunt for bugs. At the startup, it should read /etc/bugster-hosts, which has initial list of "known" bugs. This along with the localhost, is set of known bugs. What the "hunting" algo does is, ping each IP address in the subnet of each of the IP address of the known bugs. For eg, ping all the hosts in the subnet of ie, ping to If the ping's successful, then connection to port 6666 of the IP address is made to "talk" to the probable bug.

The bugster checks the all subnet addresses of all the known bugs. It also maintains a hash table of the IP addresses, it has already pinged to avoid looping (for eg, my bugster running on can find out as a bug which informs me that is a bug, to which I connect and so on).

Thanks to the following people, whose copyrighted works make up parts of Bugster.

Chirag Kantharia <chyrag-at-slashetc-dot-net>