1

Let's say from current server at timestamp 1600000000.123 (123 is milliseconds part) we do initialize ping to external server's API server-time endpoint, which says that server-time at that moment (when request reached there) was 1600000000.555.

However, of course there was latency before request reached the server and moreover, when the response was obtained by our request. When server responded .555, maybe exactly at that moment (parallelly) on our server exactly was already 1600000000.602 or whatever any different time).

So, how to determine, what time was on the originator server, when the remote API responded that answer .555. Should we check headers or which approach should we use, to find out the milliseconds difference at best possible accuracy.

(p.s. language doesn't matter much -be it php or node-js)

T.Todua
  • 53,146
  • 19
  • 236
  • 237
  • Does this answer your question? [The best way to synchronize client-side javascript clock with server date](https://stackoverflow.com/questions/1638337/the-best-way-to-synchronize-client-side-javascript-clock-with-server-date) – Gabriel Oct 29 '21 at 13:02
  • 2
    Network time synchronization is a *broad* topic, and a complicated one. Because you don't know how the source server is synchronized to some authoritative time source, or its current drift, you can only be so accurate. – Pointy Oct 29 '21 at 13:02
  • How are you going to handle slow request between the server and your user? There are ways to try to do it with multiple timestamps with packets, but it will be off by a certain percentage. – epascarello Oct 29 '21 at 13:10
  • @Pointy many thanks for the comment, it makes sense. – T.Todua Oct 29 '21 at 16:05
  • @epascarello I don't think slow or fast request matters. Let it be even 5 seconds delay. We just want to find out "how to find out **that** difference". Is there any way profs do to measure that? – T.Todua Oct 29 '21 at 16:06

1 Answers1

2

You're using the internet here, a network of connected IP networks, to communicate from your client to the server and back again. As you know, IP networks aren't deterministic in their timing. So there are many unknowns.

A good way to do what you ask is to assume two things.

  1. the first time your client hits the remote API there'll be some connection setup time. For example, it takes some time to set up https connections.

  2. after the first hit to the API, it takes about the same amount of time for your request to arrive at the network and the response to arrive back.

Given those assumptions, you can try this.

  • hit the API twice and ignore the results (to make sure the connection is set up).

  • make a note of the local time. local_start_time

  • hit the API again.

  • when you get the response, make a note of the local time again. local_end_time.

  • assume that the server responded halfway between your start_time and end_time.

    actual_server_time = reported_server_time 
                      + (local_end_time - local_start_time) * 0.5

This is close to the best you can do.

Another tip: If the server time (in UTC) is not within a few seconds of your client time, issue a warning message. If you trust your server's administrators, warn your user that their local machine is not synchronized using the Network Time Protocol. Almost all internet-connected operating systems handle this time synchronization automatically these days.

If you don't trust your server's administrators, your warning will necessarily be a bit more vague.

A lot of authorization / authentication tech (Javascript Web Tokens, SAML, Google Authenticator style TOTP codes, and on and on) relies on time synchronization.

(I once had a customer try to integrate with a SAML authentication protocol from a non-synchronized machine set to some random time of day. My SAML implementation correctly rejected the incoming auth tokens because they were from several minutes in the future. So I added the warning message. It asked my customers to use their OS Date & Time settings screen to sync up. The problem hasn't recurred since.)

O. Jones
  • 103,626
  • 17
  • 118
  • 172
  • Great tips O.Jones, I appreciate. Interesting though to estimate someway in between. I will go that route probably, as it seems the best possible thing in such case. – T.Todua Oct 29 '21 at 16:08
  • Can you mention, how can "ping" help in this case? For example, when doing `ping google.com` and response is `Reply from 142.250.187.142: bytes=32 time=27ms TTL=112` , is `27ms` any meaningful/alternative solution to this problem? – T.Todua Oct 29 '21 at 16:12
  • 1
    The time listed in ping output is the round-trip elapsed time from sending the ping (ICMP / IP echo) packet and receiving a response. It contains no information about the clock setting on the responding server. – O. Jones Oct 30 '21 at 10:44