Package org.cometd.server.ext

Class TimesyncExtension

  • All Implemented Interfaces:
    BayeuxServer.Extension
    public class TimesyncExtension
extends java.lang.Object
implements BayeuxServer.Extension

    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.