Running under electric fence

In one of the previous posts I was promising to give a whirl to ElectricFence. Despite of the flurry of posts (which, as you can correctly infer, means I did not do anything meaningful at a large scale :) - I still did something... Two things. First - inclusion of the reference code for UUID operations from RFC4122, and also the RFC itself into "docs". There's a bunch of the code that I currently do not use - but given that it's still much smaller than the 500-something kilobytes library that I've found otherwise (what, WHAT is there for 500 kilobytes ?:) I am happy with it.

The second thing indeed incorporating the electric fence as part of the build - so the whole thing is now exploding with various memory diag and safety tools :)

ElectricFence allowed indeed to uncover one stupid lapse in the autogenerated serialization/deserialization code.

My assumption about the char[X] members of various structures was that they would hold the strings. Now, there is a "Color" member, which is declared as char[4] :-) So, when this array was set to 0xFF, 0xFF, 0xFF, 0xFF, and I called printf("%s", Color) - obviously the printf walked past the array - which was excellently caught by the efence, so now the _to_s routine just prints the hex values. I should fix it to be smarter and print a more friendly hex dump with characters.

Thinking more about the object updates sent to the clients - they should not be hard-tied to the object updates made by agents (hence exhibiting "received objectAdd - processed - sent objectUpdate to all" pattern) - but rather be "soft" and happen as a modification of the local objects queue (addition of elements to the tail of it) - this will allow to avoid any duplicate code to handle also the "external updates" (not by any of the agents, but rather by the processes), and gives much more headroom in the packet QoS/shaping field.