I can't see how the pooled SocketAsyncEventArgs style helps me reduce memory consumption for a server that serves many concurrent connections.
Yes, it provides an alternative to MS' Begin/End style that aforementioned MSDN page describes as requiring a System.IAsyncResult object be allocated for each asynchronous socket operation
.
And inital research lead me to believe for some reason it would allow me to allocate only a handful of byte arrays at most and share them among my thousands of concurrently connected clients.
But it seems that if I want to wait for data on thousands of client connections, I have to call ReceiveAsync
thousands of times, providing a different byte array (wrapped in a SocketAsyncEventArgs) every time, and those thousands of arrays will then just sit there until the time a client decides to send, which might well be 10 seconds.
So unless I call ReceiveAsync just around the time a client sends data (or after that, relying on some network stack buffers?) - which is at the client's discretion and unpredictable to the server, I'm out of luck and the byte arrays will sit there, idly waiting for a client to move his bottom.
I was hoping to listen on those thousands of connections with a single byte array (or maybe a single array per listening threads, if parallelizing makes sense), and once any of those connections sends something (which does have to get into some network stack buffer first anyway), it will be copied over into that array, my listener gets called, and once the listener is done the array can be reused.
Is this indeed not possible with Socket.*Async() methods?
Is something like this possible at all with .net's socket library?
It is not possible to share the same memory for multiple socket operations (or if you do you receive undefined results).
You can circumvent this problem by reading only 1 byte at first. When that read completes it is likely that more data will be coming. So for the next read you use a more efficient size such as 4KB (or you interrogate the DataAvailable
property - this is about the only valid use case of that property).