Multithreading with concurrentqueues

[MvanDoorn]

In our application we are trying to send massive amounts of data (+100MB/sec). With little data this library works fine but with a bigger amount of data is gets extremely slow. I pinpointed the problem and it lies with the queueing and locking system. This is the bottleneck for big data. Could you please make a branch that uses concurrentqueues with multithreading enabled? In other comments, you mentioned that Unity doesn't support it, but thats not true anymore. You can now change the .Net version of your project so we do have access to .net 4+ classes.

Your help is much appreciated.

[RevenantX]

@MvanDoorn low speed in library doesn't depends on locks. There is already exist task #110 . You can check this by increase DefaultWindowsSize to higher values.
But there another thing. Why do you using UDP library to transfer massive amounts of data?
Better use TCP protocol for reliable massive data. It will be faster in that situation.

uses concurrentqueues with multithreading enabled

And this will not fix problem. I am already tested this case.

[RevenantX]

You can now change the .Net version of your project so we do have access to .net 4+ classes.

.net 4+ in Unity3d is very unstable.

[MvanDoorn]

@RevenantX Thanks for your answers. TCP isn't possible in our case since it generates lots of header overhead. We need to have a latency as low as possible, preferably under 10ms.

The problem whit increasing the DefaultWindowSize is, that then I don't receive any data at all anymore. Same with SocketBufferSize. I did had to set the PoolLimit to at least 5000.
In a comment on the Unity Forum (https://forum.unity.com/threads/litenetlib-another-reliable-udp-library.414307/#post-2727515) you mentioned you reached 100MB/sec. May I ask how you did that? The maximum I have achieved so far is 20MB/sec and then the queue started to fill up again. (Thats why I pinpointed it to be a queue issue).

[RevenantX]

@MvanDoorn try increase DefaultWindowSize from 64 to 128, 256, 512.

[RevenantX]

@MvanDoorn

you mentioned you reached 100MB/sec. May I ask how you did that?

Ah i rembembered) That speed because MTU in local socket was very high (higher than 1500 bytes)

[MvanDoorn]

@RevenantX I have increased the DefaultWindowSize in the steps you mentioned and also set all possible MTU's to 7981 to force it to use bigger data. Unfortunately, it all doesn't make a difference.

I'm also logging the PacketsCountInReliableQueue and PacketsCountInReliableOrderedQueue. One thing I have noticed here is that with little data (under 10MB/sec orso) these numbers are both stable but when increasing the data throughput they starting to shoot to the skies. Sometime when using an avarage amount of data, it seems stable but then all of a sudden it also increases rapidly and the data stream stops. With increasing rapidly I mean the PacketCount shoots to 20.000+.

Edit: this also occured when using the "default" LiteNetLib without my MTU, and DefaultWindowSize.
Tested with both 0.7.7 branch and with master.

[RevenantX]

@MvanDoorn this is expected behaviour. Like in TCP. But TCP will be faster for reliable ordered data anyway.

[MvanDoorn]

@RevenantX TCP has to much overhead for us. We can afford to lose data, we only need it to be ordered and as fast as possible (low latency). That said, we actually need to use the "Sequenced" option of your library but that throws an exception inmediatly because the data is to big? Why doesn't sequenced allow big data?

[RevenantX]

@MvanDoorn unreliable packets can't be higher than MTU. Because auto fragmentation disabled. You must split packets by MTU