-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
improve resiliency of quic test #57020
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,7 +12,6 @@ | |
using System.Threading.Channels; | ||
using System.Threading.Tasks; | ||
using static System.Net.Quic.Implementations.MsQuic.Internal.MsQuicNativeMethods; | ||
using System.Security.Authentication; | ||
|
||
namespace System.Net.Quic.Implementations.MsQuic | ||
{ | ||
|
@@ -37,6 +36,12 @@ private sealed class State | |
|
||
public QuicOptions ConnectionOptions = new QuicOptions(); | ||
public SslServerAuthenticationOptions AuthenticationOptions = new SslServerAuthenticationOptions(); | ||
#if DEBUG | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we really need this? I'm not a fan of cluttering the product code with debugging helpers. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. really? => no. I spent fair amount of time debugging test failures and I was adding and removing various instrumentations wishing it was there. Perhaps @geoffkizer or @stephentoub would have preference. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We need a third opinion here 😄 @geoffkizer @stephentoub could you chime in here? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't mind having stuff like this as long as we think it's generally useful. I think it starts to verge into clutter if it's not super useful and/or not clear what the value is. I would suggest |
||
public int EventCount; | ||
public int ErrorCount; | ||
public int ConnectionCount; | ||
public Exception? ex; | ||
#endif | ||
|
||
public State(QuicListenerOptions options) | ||
{ | ||
|
@@ -219,15 +224,20 @@ private static unsafe uint NativeCallbackHandler( | |
IntPtr context, | ||
ref ListenerEvent evt) | ||
{ | ||
if (evt.Type != QUIC_LISTENER_EVENT.NEW_CONNECTION) | ||
{ | ||
return MsQuicStatusCodes.InternalError; | ||
} | ||
|
||
GCHandle gcHandle = GCHandle.FromIntPtr(context); | ||
Debug.Assert(gcHandle.IsAllocated); | ||
Debug.Assert(gcHandle.Target is not null); | ||
var state = (State)gcHandle.Target; | ||
#if DEBUG | ||
state.EventCount++; | ||
#endif | ||
if (evt.Type != QUIC_LISTENER_EVENT.NEW_CONNECTION) | ||
{ | ||
#if DEBUG | ||
state.ErrorCount++; | ||
#endif | ||
return MsQuicStatusCodes.InternalError; | ||
} | ||
|
||
SafeMsQuicConnectionHandle? connectionHandle = null; | ||
MsQuicConnection? msQuicConnection = null; | ||
|
@@ -266,6 +276,10 @@ private static unsafe uint NativeCallbackHandler( | |
if (connectionConfiguration == null) | ||
{ | ||
// We don't have safe handle yet so MsQuic will cleanup new connection. | ||
#if DEBUG | ||
state.ErrorCount++; | ||
#endif | ||
|
||
return MsQuicStatusCodes.InternalError; | ||
} | ||
} | ||
|
@@ -280,6 +294,10 @@ private static unsafe uint NativeCallbackHandler( | |
|
||
if (state.AcceptConnectionQueue.Writer.TryWrite(msQuicConnection)) | ||
{ | ||
#if DEBUG | ||
state.ConnectionCount++; | ||
#endif | ||
|
||
return MsQuicStatusCodes.Success; | ||
} | ||
} | ||
|
@@ -288,12 +306,18 @@ private static unsafe uint NativeCallbackHandler( | |
} | ||
catch (Exception ex) | ||
{ | ||
#if DEBUG | ||
state.ex = ex; | ||
#endif | ||
|
||
if (NetEventSource.Log.IsEnabled()) | ||
{ | ||
NetEventSource.Error(state, $"[Listener#{state.GetHashCode()}] Exception occurred during handling {(QUIC_LISTENER_EVENT)evt.Type} connection callback: {ex}"); | ||
} | ||
} | ||
|
||
#if DEBUG | ||
state.ErrorCount++; | ||
#endif | ||
// This handle will be cleaned up by MsQuic by returning InternalError. | ||
connectionHandle?.SetHandleAsInvalid(); | ||
msQuicConnection?.Dispose(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is a temporary solution and we should define our own status codes that'll abstract the msquic ones.
That could be probably covered with #32066.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may change the exception base and define quic specific codes. #32066 is primarily talking about the messages.
However, the HResult I pick are generally portable and for example you can use https://www.hresult.info to look them up. What comes out should pretty match what is happening at MsQuic.
Hopefully this will not be thrown directly in 6.0 and we can finalize this when we do exception cleanup and when we make it public.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay so basically we would rather expand the usage of HResult to cover all the relevant codes from msquic.
I assume this will be thrown directly from S.N.Quic, but not from S.N.Http.
QuicException
is a public API of S.N.Quic. But we're talking 7.0 time frame here.Anyway, what I was trying to say/suggest is that we should cover all the result codes eventually. However, this is perfectly good enough for the problem we have here.