Motivation:
SslStream's paramter required client certificate is misleading. In fact in suggests to client to provide the certificate and client may or may not provide it.
If client has not provided the client certificate - it assumes that client is not authenticated from TLS prospective and continues the handshake
Modification:
Expose this setting as a parameter, so that users could set it if needed.
Results:
Allows users to do a client certificate authentication on server.
Motivation:
Some important SSL Stream settings are hidden in the TlsHandler class
Modifications:
SSLStream is provided by user now via factory method;
TLS settings extended
Results:
More advanced scenarios, like X509 client authentication, are possible to do now
Motivation:
Catching up on recent netty changes, simplifying data flow through channel pipeline
Modifications:
- Replaced IChannelHandlerInvoker with direct methods on IChannelHandlerContext implementation.
- Ported changes in AbstractChannel, DefaultChannelPipeline, etc. to reduce coupling through casting.
Result:
IChannelHandlerInvoker is removed, perf improved, it is easier to implement IChannel or IChannelPipeline from scratch.
Motivation:
Improve dev exp using DotNetty nuget packages.
Modifications:
- enabled xml-doc output on projects
Result:
xml-docs are packages along binaries in nuget packages.
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.
Motivation:
Provides good flexible default while lowering memory consumption on average.
Modifications:
- Synced IRecvByteBufAllocator and relevant parts up to date
- Ported AdaptiveRecvByteBufAllocator
- Extra: properly porting ChannelMetadata
Result:
Process of receiving bytes from network is more configurable and allows for both more conservative and more agressive ingestion.
Motivation:
Increasing feature parity and dev convenience through addition of arbitrary data assignment on Channel and related API on Bootstrap classes.
Modifications
- Introduced IAttributeMap, IAttribute<T>, IConstant and related impl artifacts.
- Moved ChannelOption to common constant codebase
- AbstractChannel now inherits from DefaultChannelMap
- Reflection-less child optoins config in ServerBootstrap
- Extra: minor closure allocation fixes, internal API fixes.
Result:
Attributes can be set on Channels, better code portability in Bootstrap.
Modifications:
Added new handlers:
- IdleStateHandler.cs
- ReadTimeoutHandler
- WriteTimeoutHandler
- ChannelDuplexHandler
Added a new utils class for work with time:
- TimeUtil.cs
Motivation:
Support new versions of .NET, have a core framework that is portable across all .NET platforms.
Modifications:
addressing part of issues reported by portability analyzer
Result:
Easier to introduce .NET Platform compatibility in the future.
Motivation:
Modern language features provide for easier to read, more compact code.
Modifications:
- expression body for single line methods
- Extra: fixes in xml docs
- Extra: code style deviations in recent commits
Result:
Cleaner, more consistent code.
Motivation:
In order to avoid buffer copies and yet perform IO efficiently,
it is essential to support sending multiple byte sequences in one call.
Also there should be no additional constraints on IByteBuffer implementations
in order to be accepted by TcpSocketChannel for sending.
Modifications:
- IoBufferCount, GetIoBuffer(), GetIoBuffers() are ported to IByteBuffer and implementations.
- ChannelOutboundBuffer is extended to leverage *IoBuffer* members in order to prepare buffer batches for sending.
- TcpSocketChannel and its ancestors were extended to support sending (sync and async) a list of array segments.
- Extra: fixes WriterIndex positioning in ByteBufferUtil.EncodeString(..).
- Extra: TLS support and exception reporting in benchmark (commented out).
- Extra: fixes async send path in TcpSocketChannel and AbstractSocketChannel.
Result:
A benchmark of single client channel writing to a single server channel runs 3 times faster at 150K op/sec (vs 53K op/sec before) with no increase in CPU consumption.
CompositeByteBuffer can be used directly in IChannel.WriteAsync.
Motivation:
Improving support for future porting efforts relying on special implementations of IRunnable tasks.
Modifications:
- Added IEventExecutor.Schedule(IRunnable, TimeSpan) overload
- Extra: cleaning out IEventExecutor.Unwrap and related IWrappedEventExecutor.
- Extra: fixing synchronization in DefaultChannelPipeline's Replace and DestroyDown methods.
Result:
Better support for IRunnable implementations in execution model.
Motivation:
initial port was based on now dropped netty 5.0. This is an effort to bring core channel model artifacts to terms with ongoing development in netty 4.1. As a result future sync efforts should be much lower.
Modifications:
- Rewrote DefaultChannelPipeline (port as much as possible)
- Updated AbstractChannelHandlerContext (Skip handling is preserved from netty 5.0)
- Revisited AbstractChannel
- Extra: fixes in benchmark
- Extra: tweaking spin count on STEE
Result:
Core channel model elements are up to speed on recent modifications in netty.
Motivation:
Existing rudimentary buffer pool implementation is not flexible to efficiently support scenarios with high variety in message sizes.
Modifications:
- implemented PooledByteBufferAllocator (port of PooledByteBufAllocator) and related artifacts
- made IByteBuffer implement IEquatable<IByteBuffer>, IComparable<IByteBuffer>, implemented Equals, GetHashCode.
- ported test suite for Byte Buffers and fixed discovered issues.
- added suppression of ExecutionContext flow on async read / write on socket-based channels.
- removed old pooled Byte Buffer allocator implementation.
Result:
Support for buffer pooling for larger byte sequences, more efficient usage of memory dedicated for the pool.
Motivation:
Fix up top priority issues to ensure proper working state with recent changes.
Modifications:
- TlsHandler negotiates TLS 1.0+ on server side (#89)
- STEE properly supports graceful shutdown (#7)
- UnpooledHeapByteBuffer.GetBytes honors received index and length (#88)
- Echo E2E test uses length-prefix based framing (#90)
Result:
Setting up DotNetty does not require workarounds for shutdown and hacks to enable negotiation of higher versions of TLS. Tests are passing even with new SslStream behavior.
Motivation
Since signed assemblies became part of the release they slowed down release cycle due to extended effort necessary to prepare nuget packages with signed assemblies.
Modifications
- introduced "Signed" solution configuration
- optional Test Friends (turned off in Signed)
- re-signing support in build script
Result
New releases can be produced quicker with less effort.
Motivation:
use of breakoutInterval setting on SingleThreadEventExecutor while executor is idling is confusing to users and inefficient due to fixed interval wake ups. We can do better by peeking next scheduled task and use its deadline for wait timeout.
While breakoutInterval is still useful while executor is busy, it can be reduced now to much lower number without impacting idle performance.
Modifications:
- When going to wait due to empty immediate queue, consult with scheduled task queue to figure out timeout value (next task's deadline - now).
- default breakoutInterval changed to 100 ms for higher resolution for scheduled tasks while busy.
Result:
Better precision for scheduled tasks at no performance cost while idling.
Motivation:
Allow for less GC when scheduling if Task-based API is not required. Allow for proper cleanup when canceling scheduled task so that associated resources can be cleaned up early.
Modifications:
- Moved out scheduled task implementations from AbstractScheduledEventExecutor
- Introduced IScheduledTask and aligned IScheduledRunnable
- Implemented removal of scheduled task upon its cancellation
- Extra minor fixes
- IByteBuffer.ToString(Encoding) honoring ArrayOffset
- InternalLoggerFactory creating default logging factory lazily
Result:
Scheduled tasks that normally never fire (e.g. timeout handling) do not cause resources to be held up unnecessarily in memory for longer period of time if not necessary.
Motivation:
When buffer was released in other thread, this buffer couldn't be released. I think that need to release a buffer in other thread for memory effectiveness.
Modifications:
Implement WeakOrderQueue for releasing a buffer that other thread owned.
Result:
When buffer was released in othread thread, owned thread can use this buffer.
Motivation:
Fix a bug #71.
Modifications:
Set length property of a PooledByteBuffer in case of a switch of underlying array to unpooled.
Results:
PooledByteBufferAllocator can work with buffers bigger than pooled buffer's original capacity.
Motivation:
Fix a bug that breaks setting options specific to socket-based channel implementations
Modifications:
Added SetOption overload accepting socket-specific options to DefaultSocketChannelConfiguration
Result:
It is possible to modify send/receive buffer size and other settings through SetOption on Bootstrap.
Motivation:
Due to misuse of IEventExecutor.SubmitAsync in
DefaultChannelHandlerInvoker and Bootstrap, async operations return future
that is completed after first sync part of operation is through.
Modifications:
DefaultChannelHandlerInvoker and Bootstrap are modified to complete
returned future only after the whole async operation is completed.
Result:
chaining async operations does not result in intermittent failures due to
premature access to channel, errors potentially appearing in later stages
of async operations are also properly reported through failure of the
future.
Motivation:
ResourceLeakDetector throws when the same object is picked through sampling
Modification:
GCNotice is made reusable to avoid the described issue
Result:
ResourceLeakDetector can be used without unexpected errors from repeated use
Motivation:
If users want to change the ByteBuffer of the string, it is complicated.
Modifications:
Implement ToString methods in IByteBuffer and derived classes.
Result:
Users can easily use to change IByteBuffer to the string.
Motivation:
Guid is necessary for other systems to make a distinction between event.
Modifications:
Guid assigned to the DefaultEventSource.
Result:
We have a Guid now. Yay!
Port Logging Handler Fixes#38
Motivation:
LoggingHandler is a must in many situations especially with non-trivial
pipeline composition so it will definitely be ported soon . It actually
provides nice looking bytebuf output + additional log for all the
events.
Modifications:
Added Logging functionality to DotNetty.Handlers project
Modified Echo.Server example project to log the events
Result: Easier to learn DotNetty from output by LoggingHandler
Motivation:
revisit EmptyByteBuffer port to ensure complete functionality
Modifications:
- ported trivial implementation of ToArray, Duplicate and other methods
- minor cleanup
Result:
EmptyByteBuffer does not throw exceptions when operation can be completed in a trivial way (0 byte length is enough to complete the operation).
Max Gortman