Fix problems with high load on RUDP

[JamJar00]

There are currently problems with high load as demonstrated with BenchmarkNet. Hazel should not fall at any of the BenchmarkNet tests let alone at such an early test.

[Vytek]

Not so bad for 192 clients ;-)

[JamJar00]

It's not too bad, but it still indicates a problem somewhere that could always trip up lower client counts in the wrong circumstances!

[Vytek]

How can we fix the problem? Using Profiler?

[JamJar00]

Profiler won't help here really, just need to find the set of locks causing the deadlock (assuming it's a deadlock)

[nxrighthere]

Now the thing that really matters is just fixing the module crash that happens when more than 500 clients connected to the server.

System.InvalidOperationException: Could not send data as this Connection is not connected and is not connecting. Did you disconnect?
in Hazel.Udp.UdpClientConnection.WriteBytesToConnection(Byte[] bytes)
in Hazel.Udp.UdpConnection.SendAck(Byte byte1, Byte byte2)
in Hazel.Udp.UdpConnection.ProcessReliableReceive(Byte[] bytes, Int32 offset)
in Hazel.Udp.UdpConnection.ReliableMessageReceive(Byte[] buffer)
in Hazel.Udp.UdpConnection.HandleReceive(Byte[] buffer) Unreliable: 30102 messages (1444896 bytes)
in Hazel.Udp.UdpClientConnection.ReadCallback(IAsyncResult result)ble: 28828 messages (1383744 bytes)
in System.Net.LazyAsyncResult.Complete(IntPtr userToken)nreliable: 28828 messages (1383744 bytes)
in System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)ges (5641632 bytes), Unreliable: 116587 messages (5596176 bytes)
in System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
in System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
in System.Net.ContextAwareResult.Complete(IntPtr userToken)
in System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
in System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
in System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

[xmedeko]

How it's possible the Hazel has crashed while the DarkRift 2.1.0 has been doing OK? I though the DarkRift 2.1.0 is build on top of the Hazel.

[JamJar00]

DarkRift 2 was originally going to be built on top but was changed during the development to a simpler bi-channel TCP/UDP setup to make it easier to maintain.

[xmedeko]

So, the README.md is wrong:

Hazel is going to be the basis of DarkRift 2 ...

Continued support as it's improved and maintained for DarkRift 2 ...

[JamJar00]

Good spot, I forgot about that. Fixed.

[xmedeko]

Since building robust RUDP is not easy and RUDP may be implemented in different way (e.g. reliable with order, reliable without order, unreliable with order, ...). I suggest you to drop RUDP from Hazel and maintain bi-channel TCP/UDP communication like DarkRift2. This way, maybe the DarkRift2 may use Hazel again in the future?

[JamJar00]

I don't think it would be fair to drop a connection method, there are people who use Hazel for it's RUDP and it would mean they had to change otherwise.

[willardf]

Okay, I feel like I'm resurrecting something here, but I wanted to gather some opinions.

Someone randomly suggested I run @nxrighthere's Benchmark.NET project against the fork of Hazel I've been developing for the last year or so. They had concerns with this issue showing up in those tests. Since I've been running my fork in production for 6+ months at 500+ users, I'm not surprised that I have fixed this issue.

However I noticed Hazel is leading in bandwidth, and I'm sure my fork has improved the memory and CPU characteristics as well since I've removed several locks, allocations, and buffer copies.

The changes are deep enough and my focus diverged from @JamJar00's enough that I have considered rebranding entirely. But I've been developing strictly for my personal uses and I'm not really a "maintainer", I don't have a strong feel for if that is the right choice.

So uh, tl;dr. Is it possible I can get an external reading of my progress? The necessary changes to the benchmark are very simple. Should I rename my fork and part ways (with credit, of course) or is there room for an almost certainly breaking change PR?

[Vytek]

I vote for rebranding! Please add some simple example client-server. And Unity simple example, it is very usefull! Hazel next gen is back! Thank you for your help!

[JohnBergman]

What would the breaking change(s) be and how hard are they to compensate for in my code?