.net - Socket.AsyncSend Behavior When Remote Client Stops Receiving

I'm running into an issue where I have a lot of AsyncSends going on with dozens of client sockets, and at the moment if any remote client stops receiving but doesn't actually disconnect, the app quickly eat sup all of the SocketAsyncEventArgs (aka an sae) I have preallocated because they're not released since the SendAsync is not completing. The obvious solution to this is to implement a per-client send queue, which sounds easy enough but I am unclear as to the specifics. I have one sae allocated per client to receive, which works perfect, and ideally I'd love to allocate a single sae to the client's async sends.

I understand popping in and asking a question that is veiled request for a 'give me code' solution is looked down upon, but I honestly have not been able to turn up a lot, either on the .XAsync methods, which Microsoft has a horribly poor example for, nor for a send queue in general.

Edit for @J.N.

I forgot to mention it, but I -am- actually using a bunch of preallocated sae's stored in a managing class that internally uses a ConcurrentBag. With one connection, in a test scenario where 20 small messages are sent per second (this is slightly more than double how many messages would actually be sent in the production server), the server eats up 500 preallocated sae's in a few seconds. If I implement 'create if empty' code, the sae count quickly climbs into the thousands.

I understand the functionality that the async methods of the Socket class provides, but if there's a network hiccup or something similar, this issue will outright bomb the server within seconds. A send queue sounds like an great solution, but I have no idea whether it's a good idea to do in a high performance production environment or not.

The base problem remains, though, that with a dozen messages per second per client being sent out, any network congestion or other factor that lags the connection but does not disconnect it will quickly deteriorate into a laggy mess.

I think a solution I might be looking for is something that locks up the single sae being used for sending until the completion callback is reached, where that sae is then unlocked and then reused to send any pending data. The actual implementation of it eludes me though.