I came across a slightly other solution. I just dispose the pool on stop of the UDPBuffer. That works perfect for me. I'm not sure if 16 is really a good choice I think I saw about 25 used buffers per pool when I traced the problem. But not sure on that. Who gives a damn about memory anyway those days - at least if it isn't a leak?

Does the singleton handle multiple clients well? I could imagine it leads to some locking overhead? But I must say a singleton is a clever workaround or did you also realize, that the timer is the root cause? Always free unmanaged resources

I attached my patch. Feel free to do whatever you want with it. Bases on rev 2009 of ObjectPoolBase.cs and UDPBase.cs.

Thank you for spotting that it was the timer, I figured it was something in the pool keeping things alive but never dived in to see exactly what. I switched to the singleton because the pool is designed to be used with as many packet buffers as the application has. Splitting it up into multiple pools doesn't help since that is already done at the pool level with the concept of segments. Before this patch a pool had a default segment size of 64, each packet buffer was 2048 + 4096 bytes, and one pool was allocated per simulator (by default you connect to the simulator you are in and four around you). That meant something like 1,920KB of memory used just for the packet buffer pool when a client would log in. Now that's been scaled down to 96KB at login, and even very active clients should not use more than 192KB for the pools.

Thank you for tracking this down!