The protocol started to be implemented recently (see proto.c in the Github repository, for reference). Of course, as with any project log, this had its ups and downs (and currently, isn't finished; part of the protocol is implemented, however what remains cannot be completed until later, when the code begins to talk to the UCI). You may have noticed a lot of issues and problems cropping up in the project log, often several per post. That's not us being incompetent (I don't think), but rather, trying to be 100% transparent.

The last time I posted on here, the heartbeats and replies were literally the strings "heartbeat" and "reply". Obviously, that's not much help at all for sending any useful information over the network, so we needed to start on the actual project now that communication was established.

2 new data structures were defined: one for the heartbeat, and one for the reply. They share the same base set of fields (identification number, used to discern between the two when received over the network), flags, and a magic number. The fields following this, the optional fields, differ, however right now they aren't used (although are present in the structure), so I won't go over them here.

4 routines also got added, per data structure. One to generate the structure, one to serialize it for sending over the network, one to deserialize it back into a data structure, and one to output it to stdout, for debugging purposes. A 9th routine (remember 4*2, because 2 data structures) was added, to tell the two apart. These were already stubbed in proto.c, however as I haven't gone over them yet, I shall repeat it here.

The first implementation of these did not work, and transmitted 0s for all fields. As did the second version, and the third as well (none of which were committed to Github, due to the principle of not breaking the build tree). The itterations we went through were: copying bytes directly from structure to buffer (and back again) using some pointer magic. Then, we went to using memcpy. Then we moved to using types declared in stdint.h, and at last it worked, just about. This happened in stages, hence the 3 versions above. The move to memcpy should be pretty obvious, however the move to stdint.h is a bit less so, and an issue I've certainly never ran into before. As far as I've ever been concerned, an int in C has always been 32 bits, and I've always assumed them to be so. However, and I should have known this before, different architectures assume their basic types to be different sizes, which can change (MIPS, which is what we're developing for, incidentally uses 64 bits, I believe, for ints). Hence, a 64 bit magic number field was created, the lower 32 bits stuffed with a randomly generated (from /dev/urandom), and (thanks to the way pointers work for little endian) the upper 32 bits copied to the serialized bitstream, to be sent over the network. Using uint32_t fixed this (this was the 4th change: from int32_t to uint32_t. Fundamentally it makes no difference, as it will work either way, but it makes debugging easier, as it means minus signs aren't just floating around in the output, making it easier to read.)

That made the protocol fully implemented, as good as it was going to get without linking to UCI, which won't happen until much, much later. The next step is to build the 3rd thread, PC, for processing the generated and received messages.