I currently run the CS 128 Honors course at UIUC where I've taught the Rust programming language to ~300 freshman since January 2022. I publish weekly lectures, develop autograded Rust programming homeworks, and manage a course staff of 10 other students. The course runs in parallel to an introductory course that teaches C++. It aims to teach memory safety, parallelism & concurrency, functional programming, and more through the lens of the Rust programming language while students learn similar concepts in C++ in the introductory course.

Since January, I've been delivering weekly lectures covering various concepts from Rust syntax to generics & templating to thread-safety. I have also developed programming assignments such as a Rust rendition of MapReduce or a Rust implementation of the K-Nearest Neighbors algorithm to expose students to well-known algorithms in computer science while also giving students extra practice programming in Rust.

Here are a few of my lectures from the past year. You can view the full playlist of lectures by semester on YouTube:

• Spring 2022
• Fall 2022

Smart Pointers and Generics in Rust

Borrowing and Slices in Rust

Ownership and Borrowing

Structs and Method Impl in Rust

Enums and Pattern Matching

I built a web server in C that is inspired by the Flask web framework for Python-based web servers. It takes inspiration from Flask's function annotation route definitions. I built this project to learn more about the kqueue interface and non-blocking IO in the C programming language and to better understand how web servers work. You can view the source code of the project on GitHub.

The kqueue interface is a kernel event notification mechanism supported on FreeBSD systems. However, the primary reason I picked the interface is because it is also supported on MacOSX systems. There are alternatives like the epoll system call interface, but epoll is only supported on Linux. I wanted to write a web server that could run natively on my Macbook. There is an interface called libevent that abstracts away the differences between the kqueue, epoll, and other non-blocking IO interfaces, but I wanted to learn more about the kqueue interface and interact with all of the system calls directly.

Since C is shipped without any native data structures, I also had to implement a few data structures from scratch. I implemented the hashset, hashmap, vector, and bitvector data structures in C to become more intimately familiar with the data structures and to continue the theme of avoiding external libraries. I also built a custom n-ary tree data structure to store the routes for the web server so that the server can efficienty look up variable routes with route parameters. For those unfamiliar, route parameters are routes that have query parameters built into the URL. Take GitHub, for example. You can look up any GitHub repository with the route /<username>/<repo-name>/. To look up the source code for my web server, you would go to https://github.com/nkaush/c-web-server/ since my GitHub username is nkaush and the repository is called c-web-server. Both the username and repository name are route parameters since they can vary for different users and different repositories.

The interface for the server is very simple. There are only 3 functions that you need to call to get a web server up and running. There are a lot of constants, but that is expected with the HTTP protocol.

• void server_init(char* port) initializes the web server on the specified port.
• void server_register_route(http_method http_method, char* route, route_handler_t handler) defines a route for the web server. The callback function handler is called when the method and route passed into the function definition are requested.
• void server_launch(void) starts the web server.

Here is what the a basic Flask application could look like:

This is the equivalent with my web server interface:

Requested routes that do not match any of the registered routes be answered with default appropriate HTTP responses. If a route is defined but the method requested does not match the defined methods, the server will respond with a 405 Method Not Allowed response. If a requested route simply does not exist, the server will respond with a 404 Not Found response. The default responses are JSON strings with the status code and a simple message included, but they can be changed by defining a custom route handler callback function for each type of error.

The server has capitalizes on some advanced browser features for file caching. If the server is configured to serve a static file, it will include headers so that the browser can cache the file. The server will respond with the contents of the file only if the file has been modified after the browser has recieved a copy of the file.

The web server is in no means production-ready. It is a only a proof of concept at the moment. The server struggles with handling upwards of 1000 concurrent connections. The server only runs on a single thread, so accepting a connection from a client and handling a portion of the IO that can be acted upon is all done on a single thread in a single cycle of a loop. As the number of clients that must be served increases, the time taken to handle each client and accept a single connection increases. I am currently working on a fix that accepts clients and adds them to a queue of clients to be served on a different thread. However, there are some nuances that arise from the blocking-nature of kqueue and the absence of a wakeup mechanism. My multi-threaded solution is currently in progress, but it is messy and relies on a hacky busy waiting solution. However, the server works very well when handling fewer than 500 concurrent connections. It can serve files and static content very efficienty.

Here is a basic example of how to use the web server: