W3C home > Mailing lists > Public > public-webtiming@w3.org > April 2015

Web Sockets for synchronization mechanisms?

From: Francois Daoust <fd@w3.org>
Date: Fri, 10 Apr 2015 14:56:19 +0200
Message-ID: <5527C873.8060802@w3.org>
To: public-webtiming@w3.org
Hi Multi-Device Timing group,

The Timing Object spec defines the core timing object but leaves out the 
core mechanisms used to connect it to online timing resources. I'm not 
sure about the best way to proceed, but I'm sure you do, so thought I'd 
throw out mumblings and questions to gather input :)

The spec describes two synchronization mechanisms [1] for the 
multi-device scenario:

- "update synchronization" which handles vector propagation, covering 
the sending of vector updates from a client to the online timing service 
on one hand, and the broadcasting of the updates received by the online 
timing service to all connected clients on the other hand.
- "clock synchronization" needed to synchronize the local client clock 
with that of the online timing service.

My understanding is that different protocols can be used here in theory. 
For instance, HTTP long polling could perhaps be used to handle "update 
synchronization" and NTP could be used for "clock synchronization". A 
new dedicated protocol could also be defined. Messages exchanged over 
some Web Socket connection could also work as well. Is that roughly 

If so, how much flexibility do we want here? More precisely:

1. How many remote endpoints are needed to connect a timing object to an 
online timing resource? The current "src" attribute assumes that the 
same communication channel will be used for both mechanisms. Is there a 
need to relax that constraint and e.g. allow users to provide a URL for 
"update synchronization" and one for "clock synchronization"?

2. Will the spec mandate mechanisms? For instance, as opposed to image 
format supports, it would not be that easy for Web authors to support 
different types of online timing resources in practice for instance, 
since supporting additional types would require the backend to support 
additional protocols. To achieve interoperability and ease of use, it 
seems important to mandate default mechanisms common to all implementations.

3. To ease implementation and make it easy to create polyfills, and 
implement online timing resources, building the mechanisms on top of a 
protocol already implemented by Web browsers and easy to support on 
servers seems like a good idea, in other words on top of Web Sockets 
since we need a dual-way communication channel. It could also make our 
life easier from a specification perspective. Developing a new protocol 
might lead to better results but seems harder to achieve than a higher 
level approach that "just" specifies exchanges over a Web Socket connection.

4. If multiple mechanisms are possible, how can a Web author tell if a 
particular mechanism is supported?

In the end, I'm proposing to stick to Web Sockets and define mechanisms 
in terms of messages exchanged on top of such a channel.

One possibility in a hypothetical rosy future could be to allow the 
creation of a timing object from an already established communication 
channel, meaning from an object that has the semantics of a Web Socket 
(an onmessage EventHandler and a send method in other words). That would 
make it possible to reuse the same communication channel for different 
purpose (although we would need some way to filter out non-timing 
messages) as well as to address other use cases such as direct 
peer-to-peer connections between devices, or use of a WebRTC data 
channel between a client and a server (I vaguely remember having heard 
that this was possible). I'm not suggesting that we do that right now 
(and that's out of scope looking at the charter) but that would be 
relatively easy to add if the initial spec defines the mechanisms in 
terms of "message exchanges" over some communication channel.

Does that make sense?


[1] http://webtiming.github.io/timingobject/#distributed-synchronization
Received on Friday, 10 April 2015 12:56:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:25:14 UTC