How to cope with high frequency data?

Question

I have a C++ application which receives stock data and forward to another application via socket (acting as a server).

Actually the WSASend function returns with error code 10055 after small seconds and I found that is the error message

"No buffer space available. An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full".

The problem arises only when I run the application after the market hours as we are receiving the whole day data (approximately 130 MB) in few minutes (I assume this is relatively large) I am doing so as a robustness test.

I tried to increase the sending buffer SO_SNDBUF using setsockopt function but the same problem still there. How can I solve this problem? is this related to receiver buffer?

Sending details:

For each complete message I call the send method which uses overlapped sockets

EDIT: Can someone give general guidelines to handle high frequency data in C++?

Answer 1

The flow-control of TCP will cause the internal send-buffer to fill up if the receiver is not processing their end of the socket fast enough. It would seem from the error message that you are sending data without regard for how quickly the Winsock stack can process it. It would be helpful if you could state exactly how you are sending the data? Are you waiting for all the data to arrive and then sending one big block, or sending piecemeal?

Are you sending via a non-blocking or overlapped socket? In either case, after each send you should probably wait for a notification that the socket is in a state where it can send more data, either because select()/WaitForMultipleObjects() indicates it can (for non-blocking sockets), or the overlapped I/O completes, signalling that the data has been successfully copied to the sockets internal send buffers.

You can overlap sends, i.e. queue up more than one buffer at a time - that's what overlapped I/O is for - but you need to pay careful regard to the memory implications of locking large numbers of pages and potentially exhausting the non-paged pool.

Answer 2

Nick's answer pretty much hits the nail on the head; you're most likely exhausting the 'locked pages limit' by starting too many overlapped sends at once. Ideally you need to buffer your data in your own memory buffers and only have a set number of overlapped sends pending at any one time. I talk about how my IOCP framework allows you to deal with this kind of situation here http://www.lenholgate.com/archives/000788.html and the related TCP receive window flow control issues here http://www.lenholgate.com/archives/000784.html.

My preferred solution is to allow a configurable number of pending overlapped sends at any one time and once this limit is exceeded to start buffering data and then using the completion of the pending overlapped sends to drive the sending of the buffered data. This allows you to strictly control the amount of non-paged pool and the amount of 'locked pages' used and makes it possible to have lots of connections sending as fast as possible yet still control the resources that they use.