Re: Web Sockets for synchronization mechanisms?

Hi Francois and all.

Thank you for this input! Please find my comments inline.

Cheers, Ingar



2015-04-10 14:56 GMT+02:00 Francois Daoust <fd@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 accurate?
>
> If so, how much flexibility do we want here? More precisely:
>


Yes, the definition of the timing object leaves a lot of flexibility for
protocol design. One could even consider decentralized approaches, though
we have argued in the charter that a strict client-server approach is most
suitable for the Web.

It is also correct that vector sync and clock sync can be solved
separately/differently. Note however

   -

   the backend service for the vector sync protocol MUST use the same clock
   as the clock sync service. This is required for correct vector update
   processing.


In our implementation (InMotion by Motion Corporation), we have opted for
what we think is the simpler solution, doing both clock sync and vector
sync over a single connection. This avoids complexities and extra failure
scenarios related to dependency on two services as opposed to one. It also
ensures that the entire problem (vector sync + clock sync) is within the
control of the timing service provider. This will likely be necessary in
order to fix problems and provide service guarantees etc. In addition,
maintaining an open connection to a timing provider requires sending some
messages from time to time, simply to ensure that the connection remains
open. So, bundling clock sync with update does not add much of a cost.



> 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"?
>


Even If one opted for a two endpoint solution  (clock service + vector
service) it would probably be a good idea to hide this for programmers. You
could for instance imagine a protocol which asks the vector service for the
URL to the appropriate clock service. The src attribute would then simply
specify the vector service.

However, we suggest using one endpoint to limit complexity, resource usage
and connect/setup delays.



> 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.
>

I think interoperability and ease of use is the purpose of the TimingObject
API itself, and as mentioned above, the current spec is very much open to
different implementations. Mandating mechanisms is more relevant when we
consider native browser support for the client-side protocol logic, as
opposed to a library approach. Different levels of browser support is also
possible, where some levels would require mandating protocols and others
would not.

At this point though we think it is premature to go into the details of
this. The library approach already yields sync precision well beyond the
requirements coming from the WebTV community, so it makes sense to avoid
limiting the design space from start by adopting the library approach
initially, and then to discuss optimizations later as demanded by new
application scenarios.



> 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.
>

Yes. This is also in line with the library approach. The timing group would
simply specify a reference protocol based on single connection over
WebSocket. The Motion Corporation service is built this way and already
demonstrates that WebSocket yields a sync precision that is more than good
enough for current scenarios.


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

If multiple, non-standardized mechanisms are used, the sync provider should
provide a JS library to bind with the HTMLTimingObject.  Whether we
standardize the full stack or not needs to be discussed, and will likely be
affected by how the HTMLTimingObject turns out.  Regardless, the programmer
should not need to know about the underlying protocols.


> 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.
>

Agreed.


> 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.
>


Yes. the basic requirement is low-latency duplex communication link between
client and server. Different types solutions for this is possible. Still, I
would not recommend multiplexing other types of data transfer across the
connection. Separating timing cleanly from data delivery is a key design
principle for precise and scalable online timing services. So, Web Sockets
is sufficient in the library approach. I can not see any benefit from
introducing WebRTC here. If we consider native browser support, UDP based
protocols could potentially be very interesting.




> Francois.
>
> [1] http://webtiming.github.io/timingobject/#distributed-synchronization
>
>