If you can, I recommend using asynchronous reads on a blocking socket instead. It's a little less weird that way since there isn't an "error" that isn't an error.
I do actually have a version of the code that uses asynchronous blocking reads, but the problem I found is how to deal correctly with timeout i.e. data not being received within a specified time limit. My current solution (using asynchronous blocking read) is a little too complex (and therefore potentially error prone) for my liking. I couldn't think of an elegant solution to timeout, that didn't involve closing the socket. I need the connection to be long lived, even after timeout. Given that, I started looking at non blocking sync read to cope with timeout. Knocking something together quickly has massively simplified the code compared to the async blocking read.
Yes, that just means that it has returned as much data as is currently available, and the rest has not yet been received yet. (Thus the error means it cannot return more data without blocking.)
I suspected as much, but the documentation wasn't entirely clear in this use case.
The data that was returned from the first read is entirely valid and present in the buffer. It is your responsibility to either copy this elsewhere before your subsequent read, or pass a start-of-buffer pointer in your subsequent read starting at the point just after the already-read data, so that it doesn't get overwritten. Otherwise you will lose data.
Further testing after sending my original email query, confirmed what you say. My problems was because I wasn't doing this right! Does make a scatter-gather style read (with multiple buffers) a little more complicated though. Not a big deal though for what I'm doing. I just had a play with trying to get what I wanted using a CompletionCondition, but my first attempt failed miserably but for now it doesn't matter. Thank you for your help. Keith