SilverFox
SilverFox
Seems it's ok in netcoreapp(but not ported to netfx), `Task.Wait()` don't need an new thread in netcoreapp(whether `TaskCreationOptions.RunContinuationsAsynchronously` is set). https://github.com/dotnet/coreclr/blob/v2.1-rc1/src/mscorlib/src/System/Threading/Tasks/Task.cs#L2955 https://github.com/dotnet/coreclr/commit/0163ed29ca05275f94101051284be9a8ccf235ed So maybe similar logic can be apply to...
Yes, the before code didn't change that. All continue outside still run in async. `WaitSync()` just create an temp Task `t2`, and force it to be run after the orig...
Add another edge case. `EnumsNET.Enums.GetNames(Type)` and maybe all other non-generic methods will throw `System.InvalidOperationException: Cannot perform late binding operation on fields of the type whose Type.ContainsGenericParameters is True.` for any...
MqttServerAndClient not failed this time, but see on some other test(TlsHandlerTest.TlsRead) in net5.0_windows ``` System.IO.IOException : The write operation failed, see inner exception. ---- DotNetty.Codecs.DecoderException : Exception of type 'DotNetty.Codecs.DecoderException'...
奇怪了, 怎么我改了测试之后mac下都跑不过了, `Assert.False(ch.Finish());`也被触发了, TlsHandler的代码我都还没开始改... 下周再看看.. ``` Mac 1. System.PlatformNotSupportedException : The requested combination of SslProtocols (Tls, Tls12) is not valid for this platform because it skips intermediate versions 2. System.Security.Authentication.AuthenticationException...
> 非windows平台的测试还是要把 SslProtocols.Tls 去掉 之前删if的时候没注意, 使用的协议版本必须要连续, 已经在新的提交里面修了, 换了一种方式验证握手的协议版本 只是不知道为啥, pipeline里面现在TlsHandleTest.TlsRead对应的所有测试项都显示同一个名字(还是已经删掉了的), 但raw log和Attachments里面又是正常的, 看着好难受... 我看别的像TlsHandleTest.TlsWrite的显示又是正常的啊, 而且是正常分组了的, 奇怪   现在主要剩下失败的应该就是新加的那个Assert, 和不知道为啥新触发的`Assert.False(ch.Finish());`
1. 查了下提交日志, 报错的那个`Assert.False(ch.Finish());`(好像是仅在握手成Tls13的情况下报错)还是我加的, 但想不起来是当时加这个是为了验证什么了, 可能当时看到返回的都是false, 这个Assert我先屏蔽掉吧. https://github.com/Azure/DotNetty/pull/366/files#diff-f34ff1ddf35c6af0420e796aa97007ec141fe8e7e7737c77a69b958472ef8776R107 2. 我本机在windows上测试下列组合握手失败(最新提交的版本忘了应该优先测试新版Tls了, 我后面反下序), 本身未触发任何的Assert, 但原生的SslStream用同一组合可以正常握手成功, 需要调查下原因 ```cs Message: System.Security.Authentication.AuthenticationException : Authentication failed, see inner exception. ---- System.ComponentModel.Win32Exception : 因为算法不同，客户端和服务器无法通信。(The client and server cannot...
设了DisableDiscoveryEnumeration好像没用, 而且不知道从哪缓存了一个旧版测试的名字, 先不管这个了 测试的名字全显示成一样的是pipeline本身和xunit+vstest的兼容性问题, 可惜连接过期了看不到当初给的规避方案了, 而且估计短时间内也不会修, 虽然不知道为啥dotnet/runtime本身用到的测试好像都是对的... https://developercommunity.visualstudio.com/t/xunit-theory-tests-using-complex-memberdata-have-d/1037085#T-N1068757 ------ MqttServerAndClient 那个我会修的, 因为现在还剩下的基本上都是Azure/DotNetty#374那个问题, 就是我最初加的那个Assert, 但可能要周末才有空改, 而且这块本身的代码也是一团乱麻, 搞得我都想去抄system.io.pipelines的实现或者引用了... 其实需要的MediationStream基本上就是这么一个东西 https://github.com/AArnott/Nerdbank.Streams/blob/main/doc/FullDuplexStream.md
不知道是不是最近win10预览版的问题, 现在我一跑dotnet sdk就蓝屏重启, 但跑别的又没问题. 现在完全没法调, 先延下期...
Updated: 1. Ub下测试通过(还没有PUSH) 2. Tls13在windows系统上测试失败的原因已确认, 并可以在dotnetty以外独立重现: 在windows上系统疑似会为同一域名+客户端协议缓存最终握手的协议, 因此更换服务端协议后无法重新谈判到Tls13 疑似就是https://github.com/dotnet/runtime/issues/47378 准备参考dotnet的解决方案, 生成随机(子)域名用于测试, 我研究下怎么重新生成上传一个带通配符(泛域名)的证书 3. 还是TlsHandlerTest.TlsRead, 试了下在net6.0控制台下跑测试概率失败(数据错误), 但无法在调试中重现, 正在想办法打日志中看看是不是还存在什么别的问题... ``` DotNetty.Handlers.Tests.TlsHandlerTest.TlsRead(frameLengths: [100, 0, 1000], isClient: True, writeStrategy: as-is, serverProtocol: None, clientProtocol: None)...