Spent the day on qnet yesterday.  Biggest change was using a structured library for the package/message format encoding/decoding.  That same structure stuff should be usable by people writing games to write their own protocols.  It's pretty straight-forward stuff.  Could use some optimisation work though. Speed dropped considerably with the structured approach instead of making single calls to struct.pack/struct.unpack.  However, it makes defining/altering the protocol structures easier.

After that began working on a callback-based sender (event interface), that worked beautifully, and the first sample/test code using it worked on the first go... except...

Why were there so many packets getting sent?  There were 3 messages getting through, and the statistics for messages were exactly what you'd expect, 1.00 resends per message that got through... but there were hundreds of packets being sent to get those messages through!  There were two oversights:

• packages were always sent on every cycle (hundreds of cycles per second), regardless of whether they had any payload/acks
• every package, even ones without messages, were getting acked

The first problem was why there were so many packages getting sent, each side was sending a "ping" hundreds of times per second.  The second is more subtle, but it essentially created an infinite loop between the sides.  It didn't come to light because in all of the tests each side is busy most of the time, so the fact that there's always "one more message" to go wasn't noticeable (especially as we were sending messages every cycle anyway).  The acks are extremely compact (1 byte + 2 bytes per package to ack, with up to 255 acks/package), so their overhead disappears in normal loads, as you can ack hundreds of packages with a single response package.

The fix for the first problem was pretty easy, though the code thought it was already checking for null packages at a higher-level, re-check at the lower level and don't send any null packages.  The fix for the second problem, however, broke the network-level plumbing.  Because there is no longer that one-last-message to be sent (ack to my last set of acks), the network test harness no longer receives the message it was receiving when it would realize it was finished and shut down.  Not a big deal, but an unsatisfying place to leave development for the week.