Package org.cometd.server.ext

Class TimesyncExtension

java.lang.Object
org.cometd.bayeux.server.BayeuxServer.Extension.Adapter
org.cometd.server.ext.TimesyncExtension
All Implemented Interfaces:
BayeuxServer.Extension
public class TimesyncExtension
extends BayeuxServer.Extension.Adapter

Timesync extension (server side).

With each handshake or connect, the extension sends timestamps within the ext field like: {ext:{timesync:{tc:12345567890,l:23,o:4567},...},...} where:

  • tc is the client timestamp in ms since 1970 of when the message was sent.
  • l is the network lag that the client has calculated.
  • o is the clock offset that the client has calculated.

A CometD server that supports timesync, can respond with an ext field like: {ext:{timesync:{tc:12345567890,ts:1234567900,p:123,a:3},...},...} where:

  • tc is the client timestamp of when the message was sent,
  • ts is the server timestamp of when the message was received
  • p is the poll duration in ms - ie the time the server took before sending the response.
  • a is the measured accuracy of the calculated offset and lag sent by the client

The relationship between tc, ts, o and l on the server is given by ts=tc+o+l (the time the server received the message is the client time plus the offset plus the network lag). Thus the accuracy of the o and l settings can be determined with a=tc+o+l-ts.

When the client has received the response, it can make a more accurate estimate of the lag as l2=(now-tc-p)/2 (assuming symmetric lag). A new offset can then be calculated with the relationship on the client that ts=tc+o2+l2, thus o2=ts-tc-l2.

Since the client also receives the a value calculated on the server, it should be possible to analyse this and compensate for some asymmetry in the lag. But the current client does not do this.