Selected School Projects
Software Porting and Operating System Installation
In my opinion, porting software across various platforms has been one of the most important learning tools I've used. My first "big" project was a summer job that involved porting hundreds of software packages (including the GNU suite, which was much less portable at the time) to a central server running what almost amounted to System V, but not quite. Many times things worked "out-of-the-tarfile", and at other times they required major changes (additions, deletions, hacks, kludges ...). A few occasions proved to be nightmarish. I believe that the overall experience had tremendous educational value (besides the gigabytes of disk quota I gained, the usual student quota being 4 MB - yes - MB!), and was largely responsible for developing my interest in operating systems. After that I undertook several such tasks each of which invariably introduced me to aspects I didn't know before. Also, I view operating system installation, configuration and tweaking as interesting activities, because it offers a nice opportunity for understanding system behavior: for example, getting the interface-less gnu-0.0 (HURD) system up-and-running could be a motivating introduction to the microkernel concept.
I designed and implemented a 32-bit virtual machine, designed an assembly language for the hypothetical CPU, and wrote an assembler. There was a curses interface to display the various CPU entities (registers, stack, etc) as they changed.
I designed and implemented a simple hashed file system, first using a file as the disk. Later I moved over to MS-DOS in order to use the BIOS for accessing the real disk. I also set forth to do the whole thing under Linux, but canned it midway to write a tool that allowed access to a Linux file system from within MS-DOS.
I designed a protocol (call it "AlphaChat") that provides services similar to IRC, and implemented a server (in C) and a client (in Perl/Tk) for it. The system allowed for multiple discussion groups, with notions such as channel ownership, public/private channels, join requests/denials, kick, etc. The server did not use multicast: it simply multiplexed sockets. MD5 was used to offer some sort of secrecy. The GUI client was deliberately made to resemble the popular Netscape Navigator. It was multi-windowed, and included a mailer, a protocol debugger, hypertext help and the like. In my opinion, this proved to be a good exercise in software engineering as well. The software was (freely) included (under terms similar to the GNU Public License) in the cover CD-ROM of a computer magazine. Click here for screenshots and further details.
This project was part of the "industrial" internship I did at DoE (Department of Electronics, Government of India). The aim was to design and implement an integrated environment which allowed one to view an "experiment" (a collection of executable programs exchanging data via a pipeline) as a general N-ary tree graphically, select one or more paths in the tree as execution sequences, schedule the corresponding processes, set breakpoints, and view the operation of a tree node operating on some data and sending it to its children along the connecting edges. The system included a general purpose plotting tool, and a reasonably useful text editor. The implementation was multiple-language (Perl, C, awk and sed), with the major portion being in Perl (over 13,000 lines of Perl code). Click here for screenshots and further details.
Communication with Serial Devices
This involved implementing a program to talk to a family of hand-held devices (bar code scanners) connected to a Linux PC by a serial cable.
A Study on the Security of Managed Systems
This was a favorite study of mine (carried on unofficially) that aimed at exploring the causes of breaches in security, both generic and circumstantial, of networked computer systems. I also wished to generalize the relationship of these attacks to the psyche of the attacker in an academic environment, with the IIT-D campus as a case-study. I aimed to demonstrate how an initial headway leads to an array of security bashing methods, and suggest some measures. The conclusions drawn from this study were used effectively to design and implement various security policies and mechanisms for the general purpose computing environment at IIT-D.
The P3 Multimedia Conferencing Environment
This was my major project in the final year of my undergraduate studies. The objective was to design a multimedia conferencing environment that would be efficient with the use of network bandwidth, provided synchronization among the various multimedia objects, and was secure enough to be used in an enterprise setting. Multimedia was already a normal component of any computing environment then. These aspects had magnified user expectations incredibly. Besides, application code needs to be portable across platforms, or better still, the compiled code should run unchanged across the plethora of platforms that exist. With these ideas in mind, the most important aspect of the design as I perceived it was that it should be simplistic and scalable, and should not be inherently tied to a particular platform: the only system specific parts in my design were the ones dealing with the frame grabbing hardware. There was a uniform file-like interface to multimedia streams, and applications were instantiated by, for example, connecting an input stream (belonging to a frame grabber or a video CD) to an output stream (which could be a display device, or a network). For the user-interface of these instantiated applications, an appropriate medium was Perl/Tk, wherein the code would run almost unchanged across several UNIX-like systems, and the Win32 platform. Further, multimedia teleconferencing being a real-time application, the real-time characteristics of the media streams (frame rates and delay tolerances for example) were also of paramount importance - synchronization between audio and video had a high priority. Though I was not assuming that the underlying Operating System is real-time, I hoped to achieve a reasonable degree of soft real-time behavior by using both the local resources and the network resources appropriately: most systems support the POSIX interface to altering the scheduler and priority: static priority real-time scheduling along with memory locking would be done on the local machine. The end-to-end network transport functions needed for transmitting the real-time data came from RTP (Real Time Protocol). This also provided feedback on the quality of data distribution. As far as the security of the whole thing was concerned (here the notion of Security includes Authentication, Confidentiality and Integrity), I utilized IP ESP (Encapsulated Security Payload).