Flask-socketio: Disconnect when server system date changed.

Created on 10 Oct 2020  路  3Comments  路  Source: miguelgrinberg/Flask-SocketIO

Describe the bug
Disconnect when server system date changed.

To Reproduce
Steps to reproduce the behavior:

  1. Change server system date with cmd: date -s 20101010 (Need to ensure that the time changed successfully. NTP server should be disable or disconnect the Internet ).
  2. Connect to server.
  3. Change server system date with cmd: date -s 20201010
  4. See error: Disconnect

Expected behavior
Not disconnect.

question

Most helpful comment

All the conditions that you mention are corner cases or exceptions. I think it is acceptable that clients are dropped and have to reconnect if such conditions occur. My point above about this not making sense is that a server would not change its clock by large amounts once it reaches steady state, the changes are only going to be small adjustments such as those triggered by nntpd and those are not a problem.

All 3 comments

Why would you change the date on a web server? That goes against common sense.

I have a few "why" scenarios:

You run this on a embeded platform or a single board system like raspberry pi without a real time clock. When it boots it starts with the last date and time it had before last shutdown.

Maybe it doesn't have internet, it can't sync time with ntp. Or maybe like some cases I've done, you added a GPS module and it takes several minutes to get GPS satellites. Or maybe you sync the time with the first computer's that connects with a browser on a non-internet LAN.

I've used these real time clockless computers in several systems. IOT in farms or an interface to control mobile telescopes. Especially at the farms when there is a power outage the power seems to come back often before the internet does.

Another scenario is where you run a flask server in tandem with something like an nwjs or electron app on desktops. Some desktops are badly configured and they have big time jumps which you can't control as a developer.

In anycase I would expect sessions to timeout on date change and just have the client reconnect. I wouldn't call this a bug personally, but this would be some "why" reasons. A workaround would be to utilize something like monotonic cputime (time.monotonic()) instead of the clock time. I do not think that it is worth making such a change though.

All the conditions that you mention are corner cases or exceptions. I think it is acceptable that clients are dropped and have to reconnect if such conditions occur. My point above about this not making sense is that a server would not change its clock by large amounts once it reaches steady state, the changes are only going to be small adjustments such as those triggered by nntpd and those are not a problem.

Was this page helpful?
0 / 5 - 0 ratings