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 -

Songs
* Aerosmith-Crazy.mp3
* Richard Marx-Hazard.mp3

SubDirectories
* ABBA
* PinkFloyd

Other Bugs
* mercury.it.iitb.ernet.in
* xyph.it.iitb.ernet.in

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).

public_dir

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.

download_dir

This is unused and will be removed in succeeding versions.

user

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.

log_file

This is location of the log file. Currently, there is no logging. By default, the access and error messages will be logged using syslog.

auth_name
auth_user
auth_pwd

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.

mp3player
oggplayer

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 144.16.116.231 ie, ping 144.16.116.1 to 144.16.116.254. If the ping's successful, then connection to port 6666 of the IP address is made to "talk" to the probable bug.

• If the url requested is /ayt, which stands for "Are You There?", then the bug is supposed to respond with just 'yes!\n'
• If the url requested is /bug_list, the bug is supposed to let the other bug know the locations of alive bugs, it knows.
• If the url requested is /song_list, the bug is supposed to print out the names of the songs (file names ending with .mp3 or .ogg), recursively, starting from it's root public mp3 directory. This could be used to form a list of songs which could be used to search for songs. Another thread could be used to constantly update/refresh this list of songs.

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 144.16.116.231 can find out 144.16.116.232 as a bug which informs me that 144.16.116.231 is a bug, to which I connect and so on).

Acknowledgements

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

• Greg Stein - For edna, which was the starting point.
• The Apache Group - The base64.c was lifted straight off from apache_1.3.14 src code.