* [0.7.2] Start threads as background in HashedWheelTimer, LoopExecutor, ThreadDeathWatcher
* + code formatting
* [0.7.3] Target net5 and net6 (#2)
target net5 and net6
Adopted TlsHandler for the case when Handshake completion callback is dispatched asynchronously to thread pool
Introduced SingleThreadedEmbededChannel for TlsHandler and SniHandler tests
* + Update DotNetVersion to "6.0.302" in build.ps1
Motivation:
Implement commonly used string-based operations (originally Netty CharSequence) for byte buffers.
Modifications:
Added read/write/get/set strings methods to byte buffers.
Also reduced unsafe pin/unpins for byte operations.
Result:
String-based operations are supported in DotNetty
1. Microsoft.Extensions.Configuration from 1.1.0 to 1.1.1
2. Microsoft.Extensions.Logging from 1.1.0 to 1.1.1
3. Google.Protobuf from 3.1.0 to 3.2.0
4. Microsoft.NET.Test.Sdk from 15.0.0 preview to 15.0.0
5. XUnit to 2.2.0 release
6. Moq from alpha to 4.7.1
7. NBench from 0.3.4 to 1.0.0
Motivation
.NET Core tooling allows building for both .NET Framework and .NET Standard while easing pains of running tests and packaging.
Modifications
- csproj -> xproj + project.json
- support for .NET Standard 1.3
- build script is now based on CAKE
- using dotnet CLI for building, testing, packing
- strong name by default (snk included)
Result
DotNetty works on .NET Core and any other platform supporting .NET Standard 1.3+.
Motivation:
as netty moved on to use JCTools directly, it is worth revisiting standard .NET concurrent collection and open queue type election in executor.
Modifications:
- Removed MpscLinkedQueue as redundant (perf is no better than with ConcurrentQueue)
- Introduced CompatibleConcurrentQueue to bridge ConcurrentQueue and IQueue<T> interface, made it the default.
- Updated STEE execution benchmark
Result:
Cleaner solution, less GC pressure from executor actions, ability to specify specialized task queue type (e.g. MpscArrayQueue on server for efficiency (at a cost of extra-mem consumption).
Motivation:
TlsHandler
Fix TlsHandler, optimize encryption / decryption wrt Write vs Flush semantics, optimize memory retention for sparse communication, adopt IByteBuffer.GetIoBuffers() in TlsHandler.
Modifications:
- TlsHandler is rewritten to use batch->copy->write approach instead of writing directly to SslStream in order to reduce overhead of framing / writing out everything separately.
- TlsHandler uses IByteBuffer.GetIoBuffers intead of direct array access increasing compatibility for non-array-backed buffers.
- TlsHandler and TlsHandler.MediationStream use Task semantics now when reading through SslStream.
- Extra: upgraded to NBench 2.2, xUnit 2.1.0.
- Extra: better portability for .NET Core support.
Result:
TlsHandler provides better framing and much better (x2+) performance (depends on application control of flushing).
TlsHandler operates properly in edge cases when more than one frame is accepted at once and if decrypted frame size is more than 4 KB.
TlsHandler holds only 256 byte buffer while waiting for more data to arrive off the wire.
Extra: DotNetty is almost .NET Core compatible.
Johnson Yang