Skip to content
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

Fix that TlsHandler don't run well on Mono #374

Open
wants to merge 6 commits into
base: dev
Choose a base branch
from

Conversation

yyjdelete
Copy link
Contributor

No description provided.

@yyjdelete yyjdelete changed the title [WIP]Fix that TlsHandler don't run well on Mono Fix that TlsHandler don't run well on Mono Mar 11, 2018
@yyjdelete yyjdelete changed the title Fix that TlsHandler don't run well on Mono [WIP]Fix that TlsHandler don't run well on Mono Mar 12, 2018
@yyjdelete yyjdelete force-pushed the tls branch 4 times, most recently from 492f893 to d2893d1 Compare March 12, 2018 00:22
@yyjdelete
Copy link
Contributor Author

yyjdelete commented Mar 12, 2018

Update Microsoft.NET.Test.Sdk from 15.0.0 to 15.6.1, it may fix that unable to run/debug an single test in vs for the 2nd time sometimes.

It's strange that The ci test always failed(but not failed in local) yesterday after this commit and later DisableParallelization.
DotNetty.Common.Tests.Utilities.HashedWheelTimerTest.* failed as it seems to be run in parallel with DotNetty.Common.Tests.Internal.Logging.InternalLoggerFactoryTest.TestMockReturned.

But the same commit always success today. Feel free to revert it if that happened again.

@yyjdelete yyjdelete changed the title [WIP]Fix that TlsHandler don't run well on Mono Fix that TlsHandler don't run well on Mono Mar 12, 2018
fixed (byte* source = &src[srcIndex])
fixed (byte* destination = &dst[dstIndex])
Unsafe.CopyBlock(destination, source, unchecked((uint)length));
Unsafe.CopyBlockUnaligned(ref dst[dstIndex], ref src[srcIndex], unchecked((uint)length));
Copy link
Contributor

@StormHub StormHub Mar 12, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsafe does a buffer pin/unpin, for unsafe buffers (already pinned on the arena), this is extra performance overhead
You have to do something like
IntPtr ptr = dst.AddressOfPinnedMemory();
if (ptr != IntPtr.Zero)
{
PlatformDependent.CopyMemory(addr, (byte*)(ptr + dstIndex), length);
}
else
{
fixed (byte* destination = &dst.GetPinnableMemoryAddress())
{
PlatformDependent.CopyMemory(addr, destination + dstIndex, length);
}
}
That is the reason why PlatformDependent does not use the ref param methods.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't recognized it's already pinned in DirectArena.MemoryChunk before.

But I think maybe ref is no need to be pinned, and this commit didn't change any overload with an pointer as param to ref. And the only thing need to be change is UnsafeByteBufferUtil.Copy, which is out of scope of this PR.

Maybe I will do some test to see the difference latter.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yyjdelete ref does a pin/unpin (fixed) for sure, your changes are ok as is. I plan to consolidate all unsafe calls.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@StormHub so this is good with you?

@StormHub
Copy link
Contributor

@nayato unsafe unaligned is good on netcore 2.1 preview. Eventually Span is a better choice once we move to 2.1.

@yyjdelete
Copy link
Contributor Author

@nayato
If this will not be merged, should I pick up some commit not reated to Mono from this to another PR? Or more than one PR? I'm busy recently so may not do that soon.

5370c02 override all methods in LoggingHandler
9fa5825 Speed up test for TlsHandler(An string up to 1.5MB(17K303) can be alloc here)
e85a443 Remove space from filename. UnsafeByteBufferUtil .cs (seems LOST after rebase in this PR) and IByteBufferAllocatorMetric .cs(And IHttpData .cs in 0.4.8)
7515ab7#diff-f5a1f6ab4f491acf78cbaeafeebc6dd1L252 Only ByteToMessageDecoder, see the todo left here before DiscardSomeReadBytes is ported.
a4be38b Failed to start debug for test in VS when after the first running.
9b52f6d An random test failed with parallel.(Not sure if it really works.)

And some thing in TlsHandler(Not sure)
https://github.com/Azure/DotNetty/blob/0.4.8/src/DotNetty.Handlers/Tls/TlsHandler.cs
L721 this->self
L756 BeginRead never call callback when finished Sync
L820 BeginWrite never check if callback is null when finished Sync

@nayato
Copy link
Member

nayato commented May 4, 2018

@yyjdelete that would be great. Feel free to bundle.

yyjdelete added a commit to yyjdelete/DotNetty that referenced this pull request Jul 8, 2018
* Make sure TlsHandler.MediationStream works well with different style of aync calls(Still not work for Mono, see Azure#374)
* Rework some logic in Azure#366, now always close TlsHandler.MediationStream in TlsHandler.HandleFailure since it's never exported.
yyjdelete added a commit to yyjdelete/DotNetty that referenced this pull request Jul 8, 2018
* Make sure TlsHandler.MediationStream works well with different style of aync calls(Still not work for Mono, see Azure#374)
* Rework some logic in Azure#366, now always close TlsHandler.MediationStream in TlsHandler.HandleFailure since it's never exported.
nayato pushed a commit that referenced this pull request Aug 13, 2018
* Add some missing method to LoggingHandler

* Avoid to alloc an huge error message when the test not failed.

* Update the unittest

* Update Microsoft.NET.Test.Sdk from 15.0.0 to 15.7.2, fix that unable to debug an unittest for the second time.
* Disable parallelization for InternalLoggerFactoryTest.TestMockReturned to avoid an rare test failure.
* Remove `dotnet-xunit` since it's never used and will be discontinued, see https://xunit.github.io/releases/2.4-beta2

* Remove space from filename

* Switch back to `DiscardSomeReadBytes` since it's avaliable

* Rework some logic in TlsHandler

* Make sure TlsHandler.MediationStream works well with different style of aync calls(Still not work for Mono, see #374)
* Rework some logic in #366, now always close TlsHandler.MediationStream in TlsHandler.HandleFailure since it's never exported.

* Workaround to fix issue 'microsoft/vstest#1129'.

* Change the default of TcpServerSocketChannel.Metadata.defaultMaxMessagesPerRead to 1
maksimkim pushed a commit to maksimkim/DotNetty that referenced this pull request Sep 14, 2019
* Add some missing method to LoggingHandler

* Avoid to alloc an huge error message when the test not failed.

* Update the unittest

* Update Microsoft.NET.Test.Sdk from 15.0.0 to 15.7.2, fix that unable to debug an unittest for the second time.
* Disable parallelization for InternalLoggerFactoryTest.TestMockReturned to avoid an rare test failure.
* Remove `dotnet-xunit` since it's never used and will be discontinued, see https://xunit.github.io/releases/2.4-beta2

* Remove space from filename

* Switch back to `DiscardSomeReadBytes` since it's avaliable

* Rework some logic in TlsHandler

* Make sure TlsHandler.MediationStream works well with different style of aync calls(Still not work for Mono, see Azure#374)
* Rework some logic in Azure#366, now always close TlsHandler.MediationStream in TlsHandler.HandleFailure since it's never exported.

* Workaround to fix issue 'microsoft/vstest#1129'.

* Change the default of TcpServerSocketChannel.Metadata.defaultMaxMessagesPerRead to 1
@paul-charlton
Copy link

Hi,
I've been having a few problems with tls, using dotnetty via a 3rd party, to connect from Xamarin.Forms, running into issues on both iOS and Android. I was speaking to the creator of the 3rd party package and he pointed me here.

The changes in the PR to TlsHandler.cs address this issue, I understand this may be a Mono problem underneath, but I was wondering what the state of this was and if it was to be merged?

The original problem by the way was a hang on IChannelHandlerContext.WriteAndFlush, eventually giving a ClosedChannelException

Thanks in advance,
Paul.

@yyjdelete
Copy link
Contributor Author

yyjdelete commented May 24, 2020

Tested on net5.0-preview4+win10x64 without NETSTANDARD1_3 defined.

See another similar problem on net5.0+win10x64(also known as netcoreapp5.0) , and this patch(only ResetSource and ownBuffer part is required, Flush part is still only needed in (maybe only old versions of) mono) also works. Don't know what is changed in net5.0, but MediationStream.ResetSource() can be called before all buffer is consumed now.

Not test on net5.0+linux.

I will rebase this PR on the top of dev latter, in case of someone still need this.

For 331ea1e, view with ?w=1 to ignore white space changes
331ea1e?w=1

yyjdelete added 5 commits May 24, 2020 16:07
…hich is not read.

Maybe needed for mono(old version only?) and net5.0(without NETSTANDARD1_3 defined)
In Mono(with btls provider) on linux, and maybe also for apple provider, Write is called in another thread, so it will run after the call to Flush.
`try{_=task.Result;}catch(AggregateException ex){ExceptionDispatchInfo.Capture(ex.InnerException).Throw();/*unreachable*/throw;}` => `task.GetAwaiter().GetResult()`, the latter one will not wrap Exception as AggregateException.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants