Now that we're back in business, and working on the code again, I find myself lost for work; there's a lot to do, but no clear direction. After some much needed coffee, however, the direction becomes clear - split the project into 5 threads: tx, which manages the transmission of the heartbeats, rx, which manages receiving everything, pc, which processes the incoming packets, and rp, which replies to any and all heartbeats it needs to. The final thread, ct, will orchestrate these, shutting them down, setting options, and communicating with UCI.

Now that we have a clear architecture, the place to start is obvious - get a working tx thread, and a stub rx, which also replies (for now...). That's easy enough, and takes only a couple of hours of work. I use my inter-thread stream library, which I developed for another project, in the code, and hooked SIGINT to properly shut down the streams.

I won't go into any more depth with regards to the code, as most of it was simple coding, flowing from my brain, through my fingertips, and into vi, in that much coveted state of 'flow'. We've all done it before. What is interesting, however, is the snag I encountered upon compiling the project - no libpthread in my SDK. After much Googling, I concluded that my SDK needed to be recompiled, with libpthread selected in menuconfig. I was surprised that this wasn't the default behaviour, but oh well. Now it compiles, I SCP it over to the router, only to find libpthread missing yet again.

This one was harder to find the solution for; when I began to think I'd need to build a custom image for the router (I'd already tried, to no avail, manually copying libpthread.so over), I stumbled upon this resource, and my prayers were answered. Downloading libpthread.ipk, and SCPing it over, it finally installs, and DHCPExt is on the router. Repeat for #2 and #3.

To test, I ran dhcpext 10.255.255.255 10.55.223.2 1 on node #1, and dhcpext 10.255.255.255 10.0.0.1 0 on node 2. The parameters are, in order, address to broadcast heartbeats on, address to directly transmit heartbeats to, and whether (1) or not (0) to broadcast the heartbeats. Success! Heartbeats are sent and received just fine, although there's no provisions to check if they're being replied to. I will check this later, however, as it's easily enough added.

Closing both pieces of software highlights an issue that, in hindsight, should have been obvious. Because recvfrom(2) is blocking, there's a window of a few microseconds between receiving a heartbeat, and sending the message from ct to close the thread - meaning, expert timing on Ctrl-C. This needs to be made nonblocking somehow, so that the thread can be closed properly and cleanly, rather than having to use the kill command, using a separate SSH session.