What I did with Tea Time

Guy Steele is a sweet guy who doesn’t give folks a hard time. But I have heard him several times lament that many computer science conferences are filled with variations on the same paper, which he lampoons as, “How I cataloged my CD collection with Lisp.” (I think he started saying this back when they were called record collections. I haven’t seen him in years and I suppose the routine now refers to MP3s.)

I’ve just been wrestling with a problem, and I’m so charmed with the Tea Time solution that I’m willing to sound like a college student that just learned how to do something mundane with his new profound toy. Call me a hack.

I could be wrong about this solution. I haven’t coded it up yet and so I’m still in that giddy stage of having not yet been proven wrong. But I think this passes the Hoare criteria of obviously having no deficiencies rather than simply having no obvious deficiencies.

The task is this: I want to allow a completely random set of transport mechanisms to drop off files at a server that will then be treated as though a Croquet participant had imported the files into the collaboration. There may be no one in the Croquet collaboration at the time the file is dropped off, or there may be a number of people working together.

The simplest way to do this would be to have the server join the collaboration as though it were just another user, import the new file in the usual way, and save the collaboration in the usual way. The Tea Time model of collaboration would take care of everything. However, I don’t want our server to have to join a collaboration or start one if the intended space is not already running. This takes several seconds, and I want the dropping off of files to be a trivial load on our server.

So, thinking of the set of imported data as a trivial bit of state, the task amounts to coordinating the state between two different systems: a server’s file system and a Croquet collaboration that may or may not be running at the time. I started by trying to figure out how to commit between the two systems without loosing data and got lost amid various forms of rollback storms. Nothing too horrible, but enough to make either the server or a Croquet participant have to do an extra save, which is, you know, one save too many when we’re talking about networks and servers.

My simple solution is to just record the server’s timestamp with each file that gets dropped off. When Croquet eventually picks up the list of new files and timestamps, it records the last such timestamp, and each pick-up only bothers to add the files that are stamped as being after the last timestamp already processed by Croquet. All of the files and timestamps stay on the server through these fetches by Croquet, and grows as new files are dropped off. Only when Croquet saves its work does it tell the server the timestamp of the last file it knows about, at which point the server can purge everything through that time. If the save never happens because of a crash, nothing is lost, and nothing is rendered inconsistent.

After figuring this out, it finally occurred to me that this exactly how Croquet’s Tea-time model manages coordination between distributed systems. Think of each new file as a message with a timestamp. Don’t try to coordinate times across the network, but use only a timestamp from the server that all these message run through.

Tea Time really is a very nice model. At Qwaq we now have some pretty serious financial institutions using Croquet, but so far only for enabling interactions between people. I can’t wait until they start using the model for coordinating financial transactions. The time of a transaction really matters in banking, effecting tiny accumulations of interest on zillions of dollars, or non-linearly producing wildly different results based on what happens in what order. Tea Time provides a very simple model for rationalizing that in a distributed environment.

More abstractly, if you view money as a means of rationalizing resources in an environment sharing the same clock, I wonder what happens to money if you view financial transactions as messages that don’t need to depend on a shared local clock.