During manual testing I did, rarely, hit an assertion. It then disappeared. Since I don’t believe in magic, that meant the code was still wrong somewhere. So, the next step was heavy-duty testing of the Zyre v0.2.0 code to try to break its assertions, and get a good idea of how it would behave in the field.
We packaged the discovery and messaging functionality as an interface object that the main program creates, works with, and then destroys. We don’t use any global variables. This makes it easy to start large numbers of interfaces and simulate real activity, all within one process. And if there’s one thing we’ve learned from writing lots of examples, it’s that ØMQ’s ability to orchestrate multiple threads in a single process is much easier to work with than multiple processes.
The first version of the tester consists of a main thread that starts and stops a set of child threads, each running one interface, each with a ROUTER, DEALER, and UDP socket (R, D, and U in Figure 8-2).
Figure 8-2. Zyre tester tool
The nice thing is that when I am connected to a WiFi access point, all Zyre traffic (even between two interfaces in the same process) goes across the AP. This means I can fully stress-test any WiFi infrastructure with just a couple of PCs running in a room. It’s hard to emphasize how valuable this is: if we had built Zyre as, say, a dedicated service for Android, we’d ...