Re: [asio] tcp non blocking sync read query (bug?)

From: Keith Robinson (Keith.Robinson_at_[hidden])
Date: 2020-06-11 12:51:29

> 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