You are encouraged to work in groups (up to 3 people) for the labs and collaborate through version control (e.g., gitlab.cs). It is okay to use open-source code in your implementation. The labs are intended to be open-ended. Feel free to add interesting features.

For Lab 2, your job is to enrich the web server implemented in Lab 1 (either from Part 1 or Part 2), with a log and replay mechanism. You must identify all the sources of non-determinism in your application and log the events and sufficient information to allow to deterministically replay them.

Part 1

Enhance your web server with two features, date and entity tag, in HTTP responses:

HTTP/1.1 200 OK
Date: Tue, 05 May 2015 11:00:00 GMT
ETag: "10e86364-3978-55484049"
...

Adding a Date field to HTTP responses should be straightforward.

To add ETag, you should design your format (e.g., a hash of the file content or the last modification timestamp). The browser will save a copy of the ETag. Later, when the browser requests the same resource again, it will send an If-None-Match header field with the saved ETag:

If-None-Match: "10e86364-3978-55484049"

If the resource hasn’t been changed, your web server should respond with “304 Not Modified” to avoid transferring the same data again.

Part 2

Now it’s time for log & replay. You web server should be able to run in two modes: log mode and replay mode. The web server may choose one of the modes through some environment variable at start-up, or an option set in the configuration file, or a command-line argument. During logging, your web server should save data it needs later for replay. During replay, your web server should read back the logged data and reproduce the same HTTP responses in the same order. You can find a similar use case at http://rr-project.org/.

You may use one of the following, or come up with your own design and implementation:

• explicitly modify the web server to log more data (e.g., the complete HTTP requests, current timestamps) and then replay the logged events;

• if you prefer not to change your web server, consider implementing log & replay in a separate .so file and using LD_PRELOAD to inject the .so to your web server, which will intercept system calls or libc functions that need to be logged/replayed;

• write a separate process that uses the ptrace system call to trace the web server (you can read its memory using procfs);

• write a kernel module that logs system call parameters and later feeds the logged data back for replay;

• leverage a virtual machine (e.g., QEMU) to log and replay your web server.

Bonus

ETags can be abused as cookieless cookies to track users. Design a way to do this and implement it in your web server.

Note that this may make log & replay harder.

What to submit

Submit a tar file of the source code of your (modified) web server, the log and replay mechanism and the README file that contains the following:

• short description of the adopted solution;
• difficulties in implementation (if any);
• commands to log and replay the execution of the web server.

If you have done the bonus part, make a note in a file called BONUS and briefly describe your idea there.