Boost logo

Boost Users :

From: Klebsch, Mario (Mario.Klebsch_at_[hidden])
Date: 2020-06-11 22:03:48


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.klebsch_at_[hidden]         Dresdenstrasse 17/18
Fon: +49 531 38 701 716            38124 Braunschweig
Fax: +49 531 38 701 88            German

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net