The good ol' days - live scorecards using 'dougie' and 'finger'

More reminiscences of the early days of cricket on the Internet...

Just as CricInfo was getting started, there was another revolution on the 'net, around the 1992-93 timeframe. Jacques De Villiers, a student in South Africa (and no relation to Fanie or AB, as far as I know!), wrote a neat little program called dougie. This was a cricket scoring program coupled with an Internet-wide score distribution system - well before the emergence of the web and browers. For those of us yearning for live score updates, it was positively a boon! Here's more on how it worked.

The dougie program worked in two modes - let's call them master and listener. A volunteer scorer watched the game, usually on TV, and operated dougie in master mode. The program had a command-line interface using which the scorer entered the 'events' on each ball, using short-hand commands. For example, if it was a dot ball, the scorer merely entered a '.' whereas if it was hit for a four, the scorer typed in '4'. There were similar commands for recording extras, the fall of wickets, a change of bowling, etc.

Of course, most users of dougie never needed to learn these commands - only the scorers did. Most of us were listeners. Now we used dougie in conjunction with the finger utility available on most Unix systems. The person who was doing the scoring would typically post to the Usenet newsgroup rec.sport.cricket, giving us their address (username@hostname.com, or whatever). The master dougie would internally keep track of the complete scorecard, including the bowling analyses, etc. and store a plain-text, nicely-formatted version of the scorecard in the user's .plan file. If I was only interested in an occasional update, I would run the command "finger username@hostname.com", which fetches that user's .plan file and displays it on my screen. So I'd get to see the latest scorecard.

However, most of us were greedier - we wanted the live scorecard, continually refreshing itself! For that, we had to have the dougie program downloaded and installed on our machines. It was available for free via anonymous FTP in the form of source code, and we had to compile it on our machines. Now we'd run dougie in its default listener mode, and give it the Internet address (hostname and port number) of the master dougie. The listener would set up a connection (TCP) with the master, and hey presto, we'd have the latest, live, self-updating scorecard displayed on our screens! Every time the scorer entered a command into the master dougie, the command (just that '.' or '4' or whatever) would be relayed to all the listeners, who would then update their scorecards accordingly. So by transmitting a tiny amount of data, dougie could regenerate and display the live scorecard for many users.

Now dougie had even more tricks up its sleeve. Although those were early days of the Internet, there were still hundreds, if not thousands of users interested in following the scores live. If all of them had tried to connect to the master dougie, we'd have a resource problem - not enough network bandwidth at the master machine, not enough ports to connect to, etc. So Jacques et al. came up with a neat solution to that. The master would only support 4 listeners. When a fifth listener dougie came along, it would be told "sorry, the master's too busy, why don't you try one of my four children who are already connected?". Then that fifth listener would connect with the first child, and start getting live updates from it. Similarly, a sixth listener would connect to the next child. Whenever the master sent out an update to its four listener children, each of them would propagate the update to their respective dougie listeners (children), and so on recursively. Thus a hierarchical distribution tree was formed over time, keeping the load on any one machine/network in check.

Once in a while, the master would terminate all its connections (children). The effect of course was that the entire tree of listener dougies would stop getting updates. All of them would then race to the master, trying to reconnect. The first four - presumably the ones 'closest' to the master on the network, and not necessarily the same as the original four children - would become immediate children of the master, while the others would then reconnect via those children, forming the tree again. This way, a more efficient tree would be regenerated periodically, helping optimize the network usage further. I can tell you, it worked very well! I used to get seemingly instantaneous updates to the scorecard on my screen!

Later, the same dougie was adapted for use by CricInfo. In addition to generating those .plan files, it would generate an HTML page that would be available on CricInfo via the web. Also, the scorer using the master dougie could also type in "commentary" in addition to recording the 'event' that occurred on a specific ball. That commentary of course would also appear in the CricInfo scorecard on the web. Vishal Misra and Travis Basevi, two of my volunteer 'colleagues' at CricInfo, made lots of enhancements to dougie for this purpose.

Some derivative of dougie is still used I believe, to generate the scorecard and commentary you see today on CricInfo. So, a tip of the hat, and a heartfelt thank-you to Jacques for creating dougie!