Node.fz: fuzzing the server-side event-driven architecture

Paper: https://people.cs.vt.edu/~dongyoon/papers/EUROSYS-17-NodeFz....

Very interesting. From what I'm reading it's a novel approach:

>A remark from one of the developers inspired the approach we took to Node.fz: “Unfortunately, I’m not able to provide a simple test case because I dont know how to artificially expand the delay between the ‘timeout’ and ‘close’ events.” Using Node.fz, developers can do this and much more

>Node.fz amplifies the non-determinism in Node.js using the techniques of de-multiplexing, event shuffling, and event delaying, achieving a greater exploration of the possible application schedule space without requiring any developer intervention. As a drop-in replacement for Node.js, developers can easily make use of Node.fz during development and test and then seamlessly switch to the optimized Node.js binary in production. Developers then have the assurance that their applications will be stable under a wider variety of deployment conditions.

As the article mentions, I wonder if the code for Node.fz could be released. Would be cool to play with.

Very cool. I've run into a number of these sorts of bugs in my own code - usually the kind of thing where we have multiple people concurrently trying to edit one single data item. My node / javascript framework does some decent caching of data on the front end, but (for example) sometimes the "hey that value has changed and must be expired from the cache" event is received by a client between their initial request for the value and the response containing the value (so the client never expires the cached value it just got, despite it having been expired before it was received).

It's timing and race condition bugs like that which can cause all sorts of crazy problems, and worse: they are often exacerbated by things like production system load. If you're building and connecting to a local (or low-load development) server, you may never even see the behavior of the system under load with higher latency. There's all kinds of ways to simulate this, but more tools for fuzzing this is always better. I'm looking forward to playing with it once it is released.

Very interesting! It sounds like node.fz should be released to the public soon. I wonder what bugs we will discover, and how easily could this be added to a CI environment.

Some related topics not considered:

* promises and async/await flow

* shared memory and atomics etc. just released in V8 6.0 which will eventually land in Node.js.