I've finished the write completion driven outbound data flow control connection filter that I started work on a while ago. This provides a way to deal with the problem of having more data to send to a client than the client can receive within a reasonable time. Rather than simply continuing to send and building up a massive amount of buffered data in the TCP/IP stack the connection filter keeps track of write completions and begins to buffer data for you when there are 'too many' write operations outstanding. This means that the data is buffered in your own memory rather than in the TCP/IP stack and that it doesn't use valuable non-paged pool. Once data is buffered it will be sent as existing write operations complete. If the amount of buffered data gets above a predetermined amount you can either get a callback or you can tell the filter to 'throw away' some of the data; either the oldest data or the newest data. Obviously there aren't many protocols where this is acceptable so the filter can call into your own code to allow you to decide what to do.
The result is that the filter will protect your server from using more non-paged pool than you'd like it to. You can rely on the TCP receive window to manage your flow control for you and once the TCP/IP stack stops sending due to the receive window being 'full' the filter will work out what's going on from the slower write completions and begin to buffer future writes for you. Once the problem passes the data will be sent automatically. If the problem is long-term then you get to decide what to do, if it's a short-term blip then you can ignore it completely and know that several of these 'blips' happening at once aren't going to bring your server down due to non-paged pool exhaustion.
Like the other connection filters that are available this one can be 'stacked', so you can push an SSL layer onto your connection, then a send flow control filter, then a connection maintaining filter or a read timeout filter, etc. Servers that don't need this functionality aren't affected by the optional functionality because they don't have the filter installed.
With this and a connection limiter installed your server (or client) can be tuned so that you can guarantee that you won't use more non-paged pool than you want to.
This code will be available in version 5.3 of The Server Framework. At present there's no release date for this. If you need this code sooner, get in touch.
Updated: 21st July 2008 - This code was actually included in the 5.2.2 release.And now, back to the data distribution server problem...