Coursework
Computer Networks
Working directly with DNS messages, HTTPS range requests and network measurements.
UDP and TLS sockets, DNS wire format, parallel downloads and latency statistics.
Project 1
DNS forwarder with domain blocking and DNS-over-HTTPS
A DNS forwarder that relays queries to an upstream resolver over UDP or DNS-over-HTTPS, answers NXDOMAIN for blocked domains and logs every query.
- Stack
- Python
- UDP sockets
- scapy
- requests
- Who and when
- Course project
- My contribution
- I wrote the forwarder in Python, and a smaller C variant that parses the query by hand.
Working demo
Send a query through the forwarder
Runs in your browser
Try this: Query yahoo.co.jp, which is on the deny list, then www.example.org, and compare the two packets and log lines.
Real DNS message bytes, simulated network and upstream. Nothing leaves your browser.
Loading demo...
What the original did
- Listens on UDP port 53 and reads the queried name and type from each request.
- Domains in a deny-list file get a synthesised NXDOMAIN response. Everything else is forwarded.
- Forwarding goes either to an upstream server on UDP port 53 or to a DNS-over-HTTPS server.
- Every query is appended to a log as: domain, query type, ALLOW or DENY.
How it works
- A DNS message is a 12-byte header followed by the question, with each name stored as length-prefixed labels.
- Blocking only needs the question, so the forwarder never has to understand upstream answers.
- For DoH the same message bytes travel inside an HTTPS request instead of a UDP datagram.
Added for this showcase
- A real DNS packet encoder and decoder, so the hex dumps are genuine wire-format messages.
- A step-by-step view of each query from client to forwarder to upstream and back.
- An editable deny list that starts with the one from the repository, and the log in the original format.
Notes
- The network is simulated. The upstream is a tiny synthetic zone using documentation address ranges, and no real DNS or HTTPS request is made.
- My original DoH call put the packet in the query string as hex. RFC 8484 specifies base64url, so the demo shows the compliant form.
Project 2
Multi-threaded HTTPS file downloader
A C program that asks a server for a file's size, downloads byte ranges in parallel threads over TLS, tries each part up to three times and reassembles the file.
- Stack
- C
- POSIX threads
- OpenSSL
- HTTP range requests
- Who and when
- Course project
- My contribution
- I wrote the downloader in C.
Working demo
Download a file in parallel
Runs in your browser
Try this: Raise the failure rate to 40% and watch parts retry, then raise it further until one runs out of its 3 attempts.
Simulated, with a virtual clock and a synthetic server. No real file is downloaded.
Loading demo...
What the original did
- Takes a URL, a number of parts and an output file name on the command line.
- Sends a HEAD request over TLS to read Content-Length, then splits the file into byte ranges.
- Runs one POSIX thread per range, each sending a range request and writing its own part file.
- Tries each part up to 3 times (MAX_RETRIES is 3), then joins the threads and concatenates the parts.
How it works
- Each thread asks for bytes start-end with a Range header, so parts are independent and can arrive in any order.
- Writing each part to its own file avoids locking. Reassembly is a sequential concatenation at the end.
- A part that uses up its 3 attempts leaves a gap, and the reassembly step then stops with an error.
Added for this showcase
- A simulated server with adjustable bandwidth and a failure rate, so retries can be seen.
- Per-thread progress bars, the exact Range header each thread sends, and an event log.
- A comparison against a single connection on the same simulated server.
Notes
- Everything is simulated on a virtual clock. The speed-up shown is illustrative: real gains depend on the server, the network and whether the server limits connections.
Project 3
Ping and traceroute statistics
Two Python tools: one runs ping and summarises latency, the other runs traceroute repeatedly and reports per-hop statistics with box plots.
- Stack
- Python
- ping and traceroute
- matplotlib
- JSON
- Who and when
- Course project
- My contribution
- I wrote both tools and the written conclusions.
Working demo
Explore the traces
Runs in your browser
Try this: Look for the hop where the box is widest, then paste in a traceroute of your own.
Parses text in your browser. Nothing is sent anywhere, and no ping or traceroute is run.
Loading demo...
What the original did
- pingstats runs ping with a delay and a packet count, parses the times and writes average, median, minimum and maximum to JSON, plus a box plot as a PDF.
- trstats runs traceroute several times, groups the latencies by hop, and writes per-hop statistics to JSON and a box plot per hop.
- A test mode reads saved traceroute output from files instead of running the command.
How it works
- Regular expressions pull the hop number, host and latency out of each output line.
- Latencies are grouped by hop across runs, so each hop gets a distribution rather than a single number.
- A box plot shows the spread: a long box means variable latency, and dots beyond the whiskers are outliers.
Added for this showcase
- The five saved traces from my own connection are loaded in the browser and parsed by a port of the same logic.
- Box plots drawn from the data, the JSON the tool would write, and readouts that point at the hop with the highest median or widest spread.
- A box to paste your own traceroute or ping output.
Notes
- The five traces are real runs from my home connection to a Google address. Hops that did not answer are skipped, as in my parser.
- My original parser read only the first of the three probe times on each hop line. The demo reads all three, which gives each hop a better distribution.