Hi, > 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.
You probably will have the same problem with sync APIO calls on async sockets. If your timer expires, you can have read a partial message received by the peer. Unless the peer violates your protocol, it will send a complete message,, and some bits are still waiting in the socket to be received later. You usually cannot start reading the next request, when you are not on a request boundary of your message stream. You either have to re-sync or discard the connefction by closing the socket. My solution to this kind of problem is to not cancel reading the message. Unless the peer violates your protocol, either the message sent by the peer will arrive (at some future time) or an error will be signalled. If the message arrives after the timeout has been reached, and no one is ready to handle incoming messages, I just discard it. I often use boost::asio::[async_]read_until() with a boost::asio::streambuf. I usually use a predicate, that signals when the entire message has been received. With the4 async variant, the last action in the event handler is to re-start boost::asio::async_read_until(). 73, Mario -- Mario Klebsch Actia I+ME GmbH mario.kleb...@ime-actia.de Dresdenstrasse 17/18 Fon: +49 531 38 701 716 38124 Braunschweig Fax: +49 531 38 701 88 German _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
