ISP Projects

LDAP performance analysis

LDAP is an Internet database protocol. The project is to analyze the overhead, response delay and throughput of a single- and multiprocessor LDAP system. (We have a four-processor server that can be used.)

Network management using Corba

Write a network management application that tracks user logins, CPU usage and other statistics on a host and allows querying by a Corba-based network management system. Track, for example:

• CPU usage
• memory usage
• load procs per min
• swap usage
• page I/O
• net I/O
• disk I/O
• list of user names

File sending

This requires kernel-hacking. Windows NT has a function that transfers a whole file via a socket. This is more efficient for web and ftp servers, since it avoids the copying of the file content to user space, just to be copied right back into kernel space. Implement this feature as a new system call in Linux or FreeBSD and compare its performance to using mmap.

File system notification for Linux or FreeBSD libc

Modify the Linux or FreeBSD libc routines to notify designated listeners when files are created, deleted or changed, as discussed in class. Consider either multicast or unicast subscription. How can you deal with NFS files?

Smallest and fastest web server:

Build the smallest and/or fastest HTTP/1.1 server. The server only has to support GET. In particular, it does not need to support authentication, content negotiation, byte ranges, cgi-bin, POST, HEAD, redirection. Performance should be measured for both returning an empty response as well as a long file.

Embedded OS project:

Add TCP to a small embedded network OS running on an Internet appliance.

Network performance test tool:

Create a tool for testing the performance of network services, e.g., (one of) DNS, DHCP or LDAP.

Partially connected file system:

See

Ronald G.  Minnich, "The AutoCacher:  A File Cache Which Operates at the
NFS Level", USENIX Technical Conference Proceedings, pp.  77-83, Winter
1993, San Diego, CA.

Minnich extended an old version of Amd to do something similar. The paper is too old to be on Usenix's online library, but Erez Zadok has those proceedings in his office.

Consider the Usenix '92 paper "Discovery and Hot Replacement of Replicated Read-Only File Systems, with Application to Mobile Computing", from http://www.cs.columbia.edu/~ezk/research/. In that work, Erez Zadok describes failover from one dead NFS to another working one.

nfs proxy

Very useful for firewalls. Requires maintaining lists of file handles, generating file handles for the outside world, and mappings b/t the file handles of the inside (protected site) and the outside. I believe firwall/proxy support is being considered for V.4. (Hmm, maybe you can cull some other nfs projects out of the v4 drafts in /misc/rfc/*nfs*.)

read-only, nfs multiplexor

Say you mount two "identical" file systems. Then issue nfs requests to either one at random (or LRU, or round-robin, etc.) Will require maintaining proper state wrt the filehandles, which while opaque to the client, are meaningfull to the server. You cannot get a FH from server 1 and use it on server 2. NFS v3. makes FH handling easier, b/c it returns new FHs as a side-effect of almost every call. So restricting this project to v3 only may make more sense.

NFS measurements

Take a few CLIC hosts and put them on a 100Mbps hub, so they all see everyone's traffic, and thus affected by it. Test NFS perf. b/t pairs of those hosts when nothing else goes on the network. Then start overloading the network by using some udp/tcp tool that sends packets (ping, ttcp, or /usr/local/sbin/netout). Continue to measure the performance of NFS as the overall network becomes more and more loaded. At some point, the load/utilization on the network would be high enough that NFS over UDP would perform poorly, but over TCP it would perform better. TCP, however, would not perform as well as UDP when the network is really quiet, b/c of TCP's overhead.

DNS server:

Implement a sufficient part of a standard DNS server so that it can replace the standard bind server. For example, you might limit yourself to UDP and the common resource record types (A, SOA, HINFO, MX, CNAME, etc.) and IPv4 only.

DHCP server:

Implement a server which is sufficient to hand out IP addresses and other configuration information.

Active networks:

Build a programmable firewall or packet scheduler using active network technology. The firewall should allow packet stateless and stateful packet filtering. Stateful filtering dynamically allows specific connections, e.g., based on TCP packets. Stateless filtering filters packets based on protocol (UDP, TCP) and port numbers. External updates, e.g., based on application-layer protocols, are desirable. (Here, a setup protocol such as RTSP or SIP dynamically installs a new filter for the duration of the connection.)