Ring Message Bus on RS-232
ipSpace.net » Early Networking History » Ring Message Bus on RS-232
A few years after I finished the LAN-on-RS232 project, the group I worked with got an interesting challenge: write a software solution that would support multi-day rally races. Not surprisingly, it landed in my lap.
Writing the software was easy (after all, it’s nothing more than adding times and sorting the sums), the real challenge was the multi-user aspect: the software had to support multiple terminals, including external displays (which we faked by connecting a TV to external output of VT100 clone connected as an RS-232 printer to a microcomputer – there was no VGA output in those days).
The whole thing could run easily on a Raspberry Pi today, but we simply didn’t have anything portable that would support multiple concurrent users (nobody dared to suggest to try to take a PDP-11 with us), and relying on leased lines going back to a data center was out of question – these events tend to take place in odd locations where it was impossible to get any connection, let alone a decent one (keep in mind that mobile Internet was invented ~20 years later).
The only compute resources we could take out in the field without major complaints were the Z80-based Partner computers, so I had to write a solution that would allow multiple nodes to access the same data. Using my local area network was out of question as it had no support for file sharing; it was time to (re)invent another wheel.
Hardware: Using weird connectors we tied together TX pin on node X with RX pin on node X+1, effectively creating an RS-232-based ring topology. It wasn’t a real Token Ring, as there was no bypass of a failed node.
Connecting RX and TX pins in a ring. What could possibly go wrong?
Software architecture had three layers: message bus, shared database, and the application.
The message bus was implemented as an extension to the operating system, so it kept running even if the application crashed or if the operator was running another program. Any node could send a message which would be repeated by all other nodes until it got back to the original node which removed it – at that point all other nodes had the message in their receive buffers.
The shared database used the message bus to propagate updates between nodes (simple records containing driver#, stage# and time). It was an eventually consistent database with update logging, which gave us the ability to replay the log to all nodes (effectively synchronizing data across them) if something really bad happened.
I won’t waste the time describing the application. Adding times, sorting data and generating printouts is not sexy.
Did it work? You bet! We successfully supported dozens of rally races over several years, and some of them (in more hospitable parts of the country) were huge fun.
You can't leave comments on this web site, but you can add them to this blog post.