Bugs

| 0 Comments

It's been a bit of a week for bugs. First I had a bug report for the really rather old CodeProject socket server COM object. This allows people using VB to create a socket server that uses the free version of The Server Framework. It works well, for what it is, and has been the basis for several custom objects that various clients have needed over the years. The bug involves the 'read string' functionality and either the ATL headers (specifically the narrow to wide character conversion macros) have changed since the code was originally written in 2002 in VC 6.0 or it never worked. Anyway I've posted a fix, here and there's a compiled version of the COM component available here.

Next up was a strange (and currently unsolved) problem with my rotating async file log. This is a log that uses async file writes to decouple the writing of log messages to disk from the thread that's logging the messages. One of its features is that it can be set up to change the log file every X period (hour, day, week, etc). It can also be told about time changes on the box, so that it doesn't get confused when daylight savings time changes, or when someone adjusts a clock. Anyway, whilst looking for an issue in a client's log file I noticed that the log file name ended in -16010101.log... This was a little unusual as the log file should have been for 20091103.log (or thereabouts). It looks like the file name is being created with an invalid system time, or one that's set to zero. I spent a few hours writing some tests to exercise the areas of code that I expected might cause this problem but couldn't get a reliable reproduction of it. If anyone else sees this happen please let me know. (The 'new file' creation code is somewhat over-engineered as the log uses a timer to create a new file 30 seconds or so before it needs it and then swaps the file in use for the new file when the first log message is written after the time when the new file should become active).

Finally I'm looking into various implementations of 'reliable' UDP for inclusion in The Server Framework; lots of people ask me about it (mostly games people) and although I've built an async version of the ENet protocol and integrated it with the framework it was one of the very few pieces of development where the client didn't want to trade cost for IP rights and so I can't reuse for other clients and the couple of clients who were willing to pay for an implementation from scratch have gone quiet on me. Anyway, so I'm looking at various reliable UDP alternatives such as UDT, RUDP, and on a related note DCCP, and possibly even something a simple as the "Carmack unreliable delta transfer" system. I decide that it might be a good idea to first extend the standard UDP server example and its test client so that I can have a base line of unreliable data flow to measure the improvements or potential improvements on and I discover that the EchoServerUDPTest program has been broken for several releases without me knowing. Basically it was never ported to the 'remove inappropriate use of pointers' release (which, I think, was pre 5.2). Anyway, it just goes to show what happens when code isn't automatically tested as part of the build and release process. All along the UDP side of things hasn't been automatically tested as well as the TCP side of things simply because of the unreliable nature of UDP; it's harder to run even a simple black box echo test during a build if some of the packets might not get echoed...

Update: the game's client that I did the original ENet work for decided to sell me the IP rights to the asynchronous, IOCP based ENet implementation that I had done for them. I'm currently rewriting this from the ground up for even more performance and this means that there WILL be a version available as an optional extra for The Server Framework in early 2011.

So, I guess this week's theme is 'must try harder'.

Leave a comment