Currently we set timeout in SafeMsQuicConfigurationHandle
|
if (options.IdleTimeout != Timeout.InfiniteTimeSpan) |
|
{ |
|
if (options.IdleTimeout <= TimeSpan.Zero) throw new Exception("IdleTimeout must not be negative."); |
|
|
|
ulong ms = (ulong)options.IdleTimeout.Ticks / TimeSpan.TicksPerMillisecond; |
|
if (ms > (1ul << 62) - 1) throw new Exception("IdleTimeout is too large (max 2^62-1 milliseconds)"); |
|
|
|
settings.IsSetFlags |= QuicSettingsIsSetFlags.IdleTimeoutMs; |
|
settings.IdleTimeoutMs = (ulong)options.IdleTimeout.TotalMilliseconds; |
|
} |
When timeout is Timeout.InfiniteTimeSpan we should set the value to 0.
If we skip setting it, default 30s timeout would still apply.
There is separate timeout setting for Connect. So if somebody wishes to control that either by allowing more time on slow network or vice versa they currently cannot do that via timeouts. (smaller timeout can be enforced via cancellation token as mitigation ) We can either apply current timeout in both cases or split the timeout setting.
Currently we set timeout in SafeMsQuicConfigurationHandle
runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Interop/SafeMsQuicConfigurationHandle.cs
Lines 118 to 127 in 633e044
When timeout is Timeout.InfiniteTimeSpan we should set the value to 0.
If we skip setting it, default 30s timeout would still apply.
There is separate timeout setting for Connect. So if somebody wishes to control that either by allowing more time on slow network or vice versa they currently cannot do that via timeouts. (smaller timeout can be enforced via cancellation token as mitigation ) We can either apply current timeout in both cases or split the timeout setting.