Broker IPC

Table of Contents

• What It’s For
  • Transaction Completion
  • User Status
• HTTP/WebSockets Servers
  • Testing
    • Autobahn
    • httplint
    • Unit Tests
    • KLEE
    • AFL

What It’s For

The pstore broker contains two IPC routes:

Transaction Completion

When a transaction completes, a message is sent to tell the broker to start the garbage collection process if it isn't already running. It is designed so that it won't block the compiler if busy. This has multiple listening threads and uses a simple "send and forget" (i.e. no handshakes), potentially lossy, protocol.

User Status

Users (and developers) need to be able to monitor the broker and GC processes. Are the GC processes running? Are they waiting or collecting? It would also be nice to collect and present logs and performance data for information and debugging.

To illustrate one use case: some time ago, whilst working on the garbage collector, I would occasionally see "permission denied" errors from the Windows implementation. Because there are multiple processes and multiple threads in each of the processes, I wasn't able to fully understand the cause of these messages. Showing the logs being issued in real-time in a browser window should make it much simpler to fully understand the behavior of these tools.

In contrast to the transaction messages, I'm using standard HTTP and WebSockets for this communication. That allows us to lean on a web browser to present all of this information and limits the amount of wheel re-invention.

HTTP/WebSockets Servers

The basic implementation is now working and validated by a 3rd party test suite.

After starting the pstore-httpd server, you can point a browser at two simple URLs:

• http://localhost:8080/index.html. The server will respond with a very simple static page.
• http://localhost:8080/index2.html. In addition to the static content above, page will cause the browser to open a socket to the server, send it a message, and modify one of the page elements to contain the response received.

These two are very basic at the moment, but are intended to validate that I have the basic implementation working in the brower.

Testing

Autobahn

I've documented the process for running the Autobahn WebSockets test suite, I'd be grateful if someone else could give this a try to ensure that the documentation makes sense.

httplint

Currently undocumented (but trivial to setup and use), I've used a simple HTTP conformance test HTTPLint.

Unit Tests

There's a (quite limited) set of unit tests for the WebSockets server. This could be expanded but the code to assemble the request and disassemble the response isn't completely trivial so I don't want to go crazy with these. The Autobahn suite gives a pretty good level of basic confidence in the code.

KLEE

This is a bit more complicated. The previous setup was a bit of a lash-up, but adequate (and its use is documented here). KLEE doesn't really come with any C++ support but I've been able to work around this without much trouble. There are a couple of changes to make:

1. Decoupling the "no-exceptions" mode from LLVM.

   Right now, when pstore is compiled inside LLVM, the exception handling support is disabled (and, just as does LLVM, we call std::exit() in the event of an error rather than raising an exception).

   Because KLEE doesn't support exceptions (or at least there's no implementation of the exception-handling library functions), I need to be able to also disable them for this case. This means some reworking of the macros (adding PSTORE_EXCEPTIONS) and CMake code (run with -D PSTORE_EXCEPTIONS=Yes or -D PSTORE_EXCEPTIONS=No to control exception support).

2. Standard library

   Everything KLEE processes needs to be compiled as bitcode. However, it doesn't come with an implementation for the standard C++ library. Mostly this is fine because the library is largely defined in header files. However, there are a set of out-of-line functions that are used in many cases.

   So far, I've simply added an implementation of the needed functions directly into each test's driver code. However, this has now got to the point where I need to have a single "cxxlibrary" target which can be linked to all of the KLEE test programs.

AFL

The networking code (both sending and receiving) is completely decoupled from the server code so that I can test the latter without using real sockets to do it. I'd like to be able to use AFL (or libfuzzer) to supplement KLEE for testing larger subsystems.