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.
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" ...
Date field to HTTP responses should be straightforward.
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
Later, when the browser requests the same resource again,
it will send an
If-None-Match header field with the saved
If the resource hasn’t been changed, your web server should respond with “304 Not Modified” to avoid transferring the same data again.
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
.sofile and using
LD_PRELOADto inject the
.soto your web server, which will intercept system calls or libc functions that need to be logged/replayed;
write a separate process that uses the
ptracesystem call to trace the web server (you can read its memory using
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.
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
and briefly describe your idea there.