Thanks, I believe the problem has been solved (at least 10 continuous hours thus far of streaming without any socket enomem error), very much so as a result of this forum and the 'heap corruption' comment, and as it turns out, nothing to do with socket recv.
If of any interest / use to anybody, the only part of the application looking out for system errors was the socket handling, thus naturally an ENOMEM would show up there - obvious likely to most but not to me, actually any part of the application could have been screwing up the memory long before the socket tried to read. I put in ENOMEM checks all over the application and waited for one to pop up. Essentially the problem came from the below code:
vector< vector<data> > DataStreams; // Data container for each stream
void RecvSocketData(); // Read once from socket and append any data to relevant stream
vector< vector<data> > ProcessStreams;
// Init number of data and process streams
for(int num = 0; num < 10; num++)
// Update process streams from streamer
ProcessStreams = myStreamer.DataStreams;
// Get latest stream data
// Do whatever to ProcessStreams
After a few hours, an ENOMEM was triggered after 'ProcessStreams = myStreamer.DataStreams'. I don't really know why, its sequential, no multiple access, no mutexing required, and it only caused an issue with the socket reading (simply because it was told to disconnect on ENOMEM). It seemingly did not effect the data containers, subsequent processing, storage, results, display, no noticeable memory leak, no segmentation, no crash, all I had to do was create a new socket, reconnect and it would carry on without issue until the next ENOMEM.
Anyways, thanks again, I learned quite a bit.