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.