Consider not using the wall clock time for timeouts in Kestrel

[Tragetaschen]

Is your feature request related to a problem? Please describe.

I have an embedded instrument with an RTC that's powered by a small gold cap. However, that battery is limited and so the instrument might forget the current date / time. If that happens, the system boots with a default date/time depending on when the Linux image was built.

There's a user interface that's rendered on an internal web browser connected to the localhost web server via SignalR.

Third, there's a way to set the date/time when lost, which directly sets the wall clock on the instrument (the time difference is typically O(months)).

When the user sets the date/time, the SignalR connection runs into a timeout because timeouts are based on wall clock time and my thought-to-be stable localhost connection breaks. I have included a retry logic just for that case.

Describe the solution you'd like

Using wall clock for timeouts always runs into scenarios such as the one described above. In my opinion it would be better to base those decisions off of a monotonic and continuous time source (Stopwatch?).

[halter73]

Do you know if Stopwatch is actually guaranteed to be monotonic and continuous?

[Tragetaschen]

My read on the documentation is that Stopwatch uses a monotonic counter as a backing store and looking through the code, that claim is backed:

• Windows uses QueryPerformanceCounter and debug-asserts that it works (available since XP)
• On Linux it uses a CLOCK_MONOTONIC, again with an assert.
• On Mac, there is mach_absolute_time

I think the only time when it was not guaranteed is the pre-XP operating systems.

[halter73]

If we change this is SignalR, we should probably consider doing the same for Kestrel timeouts. While it's probably not as likely to run on client devices with unreliable clocks like SignalR, it seems like the right thing to do.

[BrennanConroy]

This specific case looks like the server was running on one of those devices so Kestrel would definitely have similar issues.

[samsosa]

Maybe Environment.TickCount or Environment.TickCount64 are good (and fast) enough?

[Tragetaschen]

This is probably worth synchronizing with: dotnet/runtime#15207

[Tragetaschen]

Related to dotnet/corefx#35401

[BrennanConroy]

Related to dotnet/corefx#35401

Related to that dotnet/corefx@06f25ea where they switched to the new Environment.TickCount64 API.

Seems like a good possible mechanism to switch to.