The Eagle has landed
A monumental milestone has been achieved: I have replaced the entire ATOM protocol service with my own code. It is now
- Small
- Simple
- Maintainable
- Comprehensible to mortals
- Easy to extend
- Easy to debug
- Modular
- Fault tolerant
- Suitable for clustering
- Much faster
- Vista/Server 2008 compatible
There is support for multiple databases, allowing per-customer administration of data. Multiple database servers are supported, allowing asymmetric clustering.
Communications, logging and notification are handled completely independently. It is possible to stop, start, reconfigure and even upgrade these services independently without service interruptions.
The communication hub uses MSMQ for reliable, fast, restartable delivery of inbound packets to the logger. Both the logger and the hub advertise subscriptions to device events, the difference being that logger notifications occur later but are guaranteed to pertain to data that is definitely in the database, and may describe second order events (derived rather than reported by a device).
AtomSmasher, the successor to Device Manager, does not require connection to the database. If the configured hub is available, devices connected to it can be managed. Otherwise, AtomSmasher lists such devices as may be connected via local serial ports.
USB serial adaptors are not only supported, they are preferred since this provides a convenient way to trigger redetection (unplug and reconnect) when handling several devices. A database connection is unnecessary for serial connections because AtomSmasher autobauds, making it unnecessary to look up connection parameters. As many devices may be connected as USB adaptors and ports are available. Better handling of resource contention and thread management means that large numbers of concurrent sessions are easily supported.
A greatly improved user interface combines a property-sheet editor with a scrolling device log, with all commands directly available from menus.
Internal data structures are a lot simpler too, with simple byte array backing stores and property getters and setters mapping properties to and from the bytes in which they are a stored, eliminating double handling and making serialisation trivial.
While it may be traditional for an incoming programmer to rag on the efforts of his predecessor, the codebase I inherited was so bad as to be comic: it violated 43 out of the first 50 of Microsoft’s framework design guidelines (after that I stopped counting). The use of threads ran counter to every piece of scalability advice offered (I had several white papers thrown back at me), exceptions were consistently swallowed unhandled and unreported, and locking was used so incompetently as to render the entire tottering edifice effectively single threaded, but with the complexity, difficulty of debugging and fragility of free-threading.
In this context it would have been difficult to fail to make radical improvements.
Paul wants me to put post-processing logic into the logger. I’m not going to, because if you do so you can’t manage server behaviour extensions independently.
There will be no frivolous, artificial dependencies in my creation. It is currently a work of art, and it is damn well going to stay that way.