This page contains some rough ideas for possible programming projects. Although they are written somewhat like a proposal, they are far from complete. Their form is to give a general idea and possible scope. As a rule of thumb, you might plan on this for the project timeline:
If you spend 4-5 hours per week on the project, you should keep the estimated size of your implementation to under 35 hours or so.
Motivation: Typical ftp servers require ftp client users to have a login on the machine before allowing them to access files. Our Java ftp server can avoid this. One of the big advantages promised by the Java language is the ability to "write once, run anywhere." Our Java frp client should allow users to connect to our server from any JVM platform.
Problem: Doing a secure client/server implementation requires a fair amount of knowledge about security. In addition, accessing local files through Java is difficult. It's also unclear if we will implement our connection in sockets, RMI or Corba.
Related Work: There have been numerous projects using RMI. Some examples are blah, blah, blah. Others have dealt with security, such as zippity and dooda.
Approach: We will first build a Java ftp client that connects to a traditional ftp server. Then, we will implement a simple server. We will add user authentication and encryption. Lastly, we will study performance.
We will use the JDK 1.1.1 and Microsoft Visual J++ to implement our programming project. Our development platform will be a 200Mhz Intel Pentium PC running Windows NT 4.0.
Evaluation: At a minimum, we must implement a simple FTP client in Java.
C- implement simple client and server.
B- implement user login and authentication.
B/A- implement compression.
A- measure performance.
Summary: Implement major portions of a simple operating system using the Nachos.
Motivation: Operating system knowledge is best learned with a blend of theory and implementation. Unfortunately, implementing an operating system from scratch is too time consuming for a semester long course. Modifying and existing OS is complicated because most operating systems are proprietary, complicated, or just too large to completely understand. Nachos is instructional software designed to assist learning about operating systems through implementation. Nachos provides a software environment that allows OS students to learn OS concepts through implementation.
Problem: The Nachos package comes with a very incomplete operating system. The incomplete OS parts are all problems that need to be solved. The problems illustrate and explore all areas of modern operating systems, including threads and concurrency, multiprogramming, system calls, virtual memory, software-loaded TLB's, file systems, network protocols, remote procedure call, and distributed systems.
Related Work: There are other instructional OS projects similar to Nachos. Minix is written by Tannenbaum and lets you do stuff. OSP is written in Java and does other stuff. SOS does ...
Approach: We will download the latest version of Nachos and implement the programming projects within. Our development platform will be a DEC Alpha running Digital Unix 3.2.
Here are the required steps in our approach:
Evaluation: At a minimum, we must successfully download, install and solve a Nachos programming problem. A more detailed grade evaluation breakdown is as follows:
C- implement programming problems 1 and 2.
C/B- implement programming problems 1 and 4.
B- implement all of the programming problems.
B/A- implement all of the programming problems and an additional feature of ...
A- implement all of the programming problems and an additional feature. Measure the performance effect on the OS from our feature.
Summary: Explore performance of Linux kernel modules.
Motivation: Linux is a free Unix-based operating system. Linux has a simple structure, meaning user applications reside in the top layer, the hardware resides in the lower layer and the operating system resides in the middle. The kernel is basically one large binary program. However, Linux also provides a method of loading additional parts of the kernel dynamically when they are needed. These dynamically loaded parts are called modules. There are benefits of having a smaller kernel, but at what price? What is the performance overhead from loading modules?
Problem: We are going to carefully measure the performance aspects of using dynamic modules in Linux.
Related Work: There is a lot of documentation on building Linux kernel modules, such as blah. There has been some work done on Linux performance, such as ugh.
Approach: We will install the latest version of Linux. We will implement kernel modules and measure their performance. Our platforms will be a DEC Alpha and a Intel Pentium 150Mhz.
Here are the required steps in our approach:
Evaluation: At a minimum, we must successfully download, build and measure the performance of a module. A more detailed grade evaluation breakdown is as follows:
C- measure module performance.
B- compare tradeoffs in using modules.
A- measure performance of modules on other platforms.