NTDLS.ReliableMessaging v4.0.0

Be sure to check out the NuGet package 📦

New 🎉

• Added RmConfiguration.MaxPendingNotifications (default 10,000): the most notifications from one connection that can be waiting for their handlers. When this many are waiting, the connection stops reading until there is room, so TCP slows the sender down.
• Added RmConfiguration.MaxConcurrentQueries (default 1,000): the most query handlers that can run at once for one connection. When this many are running, the connection stops reading until one finishes, so TCP slows the sender down.

Changed 😎

• Each connection's receive thread now decodes its own frames (decryption, decompression and deserialization), instead of handing every frame to the thread pool.
• Replies complete their waiting query directly on the receive thread. The code that sent the query still resumes on the thread pool.
• Notification handlers for a connection now run one at a time, in the order the notifications arrived, instead of all at once. A slow notification handler delays the notifications behind it, but not replies or queries, unless the notification queue is full.
• Query handlers still run on the thread pool, so several queries from one connection are handled at once, now up to MaxConcurrentQueries.
• With AsynchronousNotifications or AsynchronousQueryWaiting set to false, those handlers run on the receive thread, which reads nothing else from the connection until each handler returns. An asynchronous query handler that is still pending replies when it completes, and does not hold up the receive thread.
• RmConfiguration.AsynchronousFrameProcessing is obsolete and no longer has any effect.
• Caution: a handler that sends a query on the same connection and waits for the reply can wait forever if that connection's notification queue or query limit is full, because the reply cannot be read until there is room.

Fixed 🐛

• Fixed notifications from one connection being handled out of order. Every frame was processed on its own thread-pool task, so notifications sent in order could be handled in any order. In CatMQ, 35–53% of fire-and-forget publishes from a single client were stored out of order.
• Fixed connections having no backpressure. A peer that sent faster than its messages could be handled filled the receiving process's memory with queued work, instead of being slowed down by TCP.

Full Changelog: https://github.com/NTDLS/NTDLS.ReliableMessaging/compare/3.6.0...4.0.0