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.

About Stearns

Howard Stearns works at High Fidelity, Inc., creating the metaverse. Mr. Stearns has a quarter century experience in systems engineering, applications consulting, and management of advanced software technologies. He was the technical lead of University of Wisconsin's Croquet project, an ambitious project convened by computing pioneer Alan Kay to transform collaboration through 3D graphics and real-time, persistent shared spaces. The CAD integration products Mr. Stearns created for expert system pioneer ICAD set the market standard through IPO and acquisition by Oracle. The embedded systems he wrote helped transform the industrial diamond market. In the early 2000s, Mr. Stearns was named Technology Strategist for Curl, the only startup founded by WWW pioneer Tim Berners-Lee. An expert on programming languages and operating systems, Mr. Stearns created the Eclipse commercial Common Lisp programming implementation. Mr. Stearns has two degrees from M.I.T., and has directed family businesses in early childhood education and publishing.


  1. By the way, Croqodile is an Erlang implementation of Tea Time. Cool idea.


    “Croqodile abstracts networking and state synchronization to allow for rapid development of multi-user, richly-collaborative flash applications.

    ”Croqodile differs from Croquet in many details (it is a far less ambitious project), but the general architecture is similar…

    “A Croqodile system will consist of three components. Two of these components will run on the client’s machine and are implemented entirely in Flash Actionscript. The third component is the router, a thin server implemented in erlang that
    will serve as a middle-man between the many clients.

  2. This model (minus the initial memory snapshot exchange) sounds a lot like how multiplayer real time strategy games operate over a network. Or at least I always assumed they do. Hmm..

  3. Cool beans. I guess the deal is to start with the idea of timestamped messages:
    1. If that defines everything you need, as in today’s problem above, you’re done.
    2. If you further have to start with the same state, then you need to do the dance with the timestamped snapshot.
    3. If you get undesired divergent behavior without it, you need bit-identical compute environments.

    By the way, Andy, did you happen to arrive here as regular reader or through, e.g., a Google alert on Lisp program or some such.

  4. I clicked through from Planet Smalltalk. The mention of Guy Steele got my attention.

Comments are closed