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.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[davidfowl]

This feels like something we should do.

[BrennanConroy]

Agreed, SignalR and Kestrel should switch to using Environment.TickCount64 for timeouts.

[halter73]

The analogue for this in the SignalR JS/TS client is performance.now().

[adityamandaleeka]

Updated the title since the SignalR side of this is done in #34382

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[BrennanConroy]

😢 I should push a branch for the Kestrel stuff I tried

[adityamandaleeka]

Sure, and I'm not ruling this out for 7. Just moved it out of NSP since it's too late for 6.

[halter73]

😢 I should push a branch for the Kestrel stuff I tried

This isn't an API change. I see no reason we couldn't take this for 6 if it's ready.

[adityamandaleeka]

Agreed. It's not ready though, and it sounds like it's trickier than originally imagined. @BrennanConroy if you are still interested in getting it done for 6, don't let the milestone change stop you :).