Critical performance drop and memory bloat on large binary transfers (20MB+ files)

[fedorfx]

Library is unusable for high-load binary transfers (files 20MB+).
It suffers from memory bloat and internal queue deadlocks, causing 2-5 minute freezes.
Old-school Synchronous TCP works 100x better. Only good for small chat messages.

[fedorfx]

Internal queue deadlocks and 2-5-minutes freezes during high-load TCP streaming.

[fedorfx]

Not so 'Ultra Fast': unusable for history data-feed and large file streaming.

[fedorfx]

Description :(
I've tested this library for a high-load DataFeed project (streaming 20MB+ ZIP archives to multiple clients). Despite the "Ultra Fast" claims, the library fails under real binary load.
The problems I encountered:
Internal Queue Deadlocks: During streaming, the server randomly freezes for 2-5 minutes per file.
Memory Bloat: RAM usage skyrockets (from 8GB to 56GB+) because the internal DynamicBuffer doesn't release large objects in time, even when using synchronous Send.
Throughput Decay: Transmission speed starts well but quickly decays to a crawl as the internal message queue gets overwhelmed.
Socket Instability: Frequent ObjectDisposedException and forced disconnects when trying to bypass the high-level API for direct socket access.
Conclusion:
This library might be good for small chat messages (10K simple connections), but it's completely unusable for heavy binary streaming or history data-feeds. Reverted to a simple "old-school" TcpListener with a thread-per-client model, which works 100x more stable and faster without any of these issues.

[chronoxor]

Large objects should be split into small chunks on app side and send them one by one with controlling by virtual void OnSent(long sent, long pending) method in order to sent next chunk after pending == 0 or near to 0. Otherwise NetCoreServer take all blob and append it to the send buffer. If you produce and send files faster that network could transmit, your buffers will grow.

[fedorfx]

This is exactly what was done, but the problem was that there could be over a hundred files, ranging in size from 1 MB to 120 MB. Splitting the files into 64 KB and 128 KB chunks didn't help. Furthermore, Datafeed crashed without an error message, even though exception handling was enabled.
Crashes occurring outside the exception block indicate serious errors in the library's asynchronous loop, which the standard TcpListener successfully avoids.