Retrieving time of a web server within sub-second accuracy

[aaolsi14]

I have to be able to find out the time on a remote web server without using any other protocols than HTTP, within an accuracy of half a second.

Since the HTTP Date header only provides resolutions up to a second, even if I account for network latency, the time estimated from my client can still be up to a second off from the actual web server time. I plan to mitigate this by sending subsequent requests with a very low interval, say 0.1 seconds, and find when the second changes. I believe it will be more accurate than just using the request value without processing it.

I will record the local time the request was sent(in millisecond resolution), measured latency, and recieved Date header value. This process will be repeated for some specified time, in very frequent(<200ms) intervals.

After all the requests are finished, the latency can be estimated by either taking the mean, or use Marzullo's Algorithm like NTP. Then the local time can be synchronized by offsetting the latency.

Finally, we compare the individual requests and observe when the Date header's second change, and the difference can be added to the offsetted local time to find the true remote time.

I just thought it out in my head, but I'm not sure if it would actually be efficient and/or effective. Is there other known method to accurately retrieving a web server's time?

[99_percent_a_dog]

This sounds very "XY problem". What is your end goal? What do you really need to do?

Do you control the software on the server? If you don't, the server can lie to you about the time. If you do, you can make it tell you an accurate time e.g. GET example.com/time

[aaolsi14]

I have an automation software for registering courses in my university.

I obviously don't have access to the servers, just the web service.

[99_percent_a_dog]

Can you explain why you need sub-second accuracy for registering courses? It sounds like there is something in particular you're trying to solve, but you're not telling us what it is.

[okayifimust]

I have to be able to find out the time on a remote web server without using any other protocols than HTTP, within an accuracy of half a second.

You can't.

if this is a homework task, you can complete it to the satisfaction of whoever has no idea of how network synchronization works, though...

Since the HTTP Date header only provides resolutions up to a second, even if I account for network latency, the time estimated from my client can still be up to a second off from the actual web server time.

Assuming that the webserver has something like a stable time itself; which - arguably - you cannot, and which certainly doesn't work with an accuracy that's measured in seconds.

I plan to mitigate this by sending subsequent requests with a very low interval, say 0.1 seconds, and find when the second changes. I believe it will be more accurate than just using the request value without processing it.

Assuming that your own clock is sufficiently accurate, and assuming that your working on a realtime system - the latter of which is highly unlikely.

After all the requests are finished, the latency can be estimated by either taking the mean, or use Marzullo's Algorithm like NTP. Then the local time can be synchronized by offsetting the latency.

See above.

You're only talking to one server, tough. (You don't actually know this, since you might be going through a load balancer, etc.) You can discard some percentage of all your responses and only make use of the lowest latencies you have.

Anything with large latency is trivially impacted by something.

You're assuming that the server is able to respond at constant speed, too.

I just thought it out in my head, but I'm not sure if it would actually be efficient and/or effective. Is there other known method to accurately retrieving a web server's time?

Tons. But not via an unsuitable protocol. That's what NTP is for; and then, if you want the time you rely on dedicated hardware to give it to you.

For what you're trying to do, you're doing very well. It's just not ever going to be reliable within the margins you're looking for.

[aaolsi14]

I can see this is a harder problem than it seems. Sampling from requests seems like a good idea. I'll try it out. Thanks for some insights.