Yesterday I've spent a fair amount of time trying to do a simple thing: in Python 3 write logs to a FIFO (created with mkfifo(1)) in a somewhat reliable way (i.e. without loosing logs on the writer end when the reader disconnects, nor duplicating them). It turned out to be quite an unforeseen adventure with what seems to be 3 levels of buffering on the way.

The exact scenario:
1. Both reader and writer connect to a FIFO.
2. Reader disconnects for some reason.
3. Writer writes N bytes of data and flushes it (and in the process gets a BrokenPipeError as expected).
4. Reader re-connects.
5. Writer does a flush (or disconnects, which implicitly invokes flush).
6. Reader reads data from the pipe (if any).

The main question here is:
How many bytes (sent in the 3rd step) did the reader receive in the end?

Below I present the download links for the slideshow (PDF) from my "Practical security in computer games" lecture, and a 0.0.1 alpha version of SilkProxy. A few more words about that last position: it's a multi-tunnel written in C++, scriptable in Python, that can be used for a few various things like protocol analysis, network traffic fuzzing or as a proxy/tunnel for some application. The version I publish is the version I've used while doing research for my lecture, and it's an alpha version - it means that not everything works as I would like it to work, the python API is undocumented, and some functionality is still (like replaying packets/network traffic and application-replay tunnel) missing - so, currently it might interest some curious programmers, but it's not yet usable for most of the researchers. However, I encourage you to take a look at it anyway (see the http.py script for a simple usage example; you run it by typing ./SilkProxy script.py, however the script is optional; to compile it you need to have Python installed with libs/headers, and GCC compiler (MinGW is OK)) ;>