Handling event simultaneity at the web-application level?

Question

Hi all, I'm sure this problem has been considered or even solved before; I just don't know how and what all my options are. Would greatly appreciate your ideas, any links to useful info... even if you don't have actual code/implementation to share. Many thanks!

Let's say:

1. I have a bunch of nodes on the Internet. These could be either www browsers, or custom thick client applications.

2. There is a server (running some service/application) that these nodes know of in advance. If necessary, the nodes can also come to know about each other via this central service.

3. Any node can send data to the central server (say, on user interaction). Any node can pull data off of the central server, Ajax-style.

Now the question:

If these nodes need to interact with each other in realtime...

and

If I need to explicitly display on each node EITHER the current server time OR the current localtime (of the node) OR the current time since the start of a session)...

Then, how do I go about addressing differences among the node clocks, clock differences between the server and the nodes, and not to mention unpredictable communication channel delays?

Use case: A user fires an event at her node at time T. Not only do I need to process this event (locally and at the server), I need to also convey the time it precisely occurred relative to all others.

I suspect there already are some time sync-ing protocols in some murky, low-level areas of the TCP/IP stack, but what all is available at the application layer level... especially, the www level?

Answer 1

Some distributed systems put responsibility for time onto infrastructure services: when you deploy system X, you must already have configured your OS to to use a time make use of services such as NIST. Things work fine so long as the distributed memebers stay within (say) a second or two of each other.

In your case arbitrary browsers can't be assumed to be in synch. So as you have a hub-spoke architecture, let the server be the keeper of "Now". When each client connects have it determine its "localTime" relative to server Now. All times sent for remote consumption are then normalised to be relative to the global Now.

You say that you need to precisely determine the times of event processing? Why? Is this really important? I can see that the sequence in which any one node processed events is interesting, but what would you infer from the exact sequence in which two nodes did things.

Node A  processed event 76
Node B  processed event 77
Node A  Processed event 77

versus

Node A  processed event 76
Node A  processed event 77
Node B  Processed event 77

Why would that matter? (Einstein might even argue that you can't guarantee knowledge of that relativity).

Answer 2

The best way to handle this kind of situation is by always using the time on your central server. I'm assuming that if your central server is really a cluster of several servers in your data center(s), that all of these servers have synced clocks. The clock of your own seervers is a known and under your control, all outside nodes are unpredictable and cannot be relied upon. You should be able to detect at least the time zone of the external node and therefore convert your own time to the zone of the user's node when displaying times.

Answer 3

Since it is ajax, the client can send the local timezone informations ( getTimezoneOffset() ) to the server. Each server-side process will know it's own timezone and can either convert that to the central timezone, or send their own timezone info to the central server. If the real task is coordinating times each process needs to implement locales in a way that the central process can understand and propagate.