Re: [Boost-users] [asio] How to deal with no-connect and/or read-timeout

Subject: Re: [Boost-users] [asio] How to deal with no-connect and/or read-timeout
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2013-06-24 18:32:43

On Mon, Jun 24, 2013 at 5:22 PM, Michael Powell <mwpowellhtx_at_[hidden]> wrote:
> Hello,
>
> I posted previously, but this is a bit of a follow-on thought.
>
> Did some searching, and SO has this note:
> http://stackoverflow.com/questions/13126776/asioread-with-timeout
>
> Pardon me while I stare in disbelief. Seriously? Okay, I'd like to use
> Boost.Asio to facilitate things. Is this the way (one proposed way) of
> handling read-with-timeout?

When in doubt, RTM, right? One of those a-ha! moments, more strongly
optimistic now.

I am looking at socket::available
(http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/reference/basic_stream_socket/available.html)
as possibly being the key to the whole callback read/write operation.

Seems as though, if there is a message waiting to write, write that
out, followed by the next operations. If there is data is available,
then perform some reading.

Possibly with some thread sleeps sprinkled in for good measure. Maybe
with a comprehended timeout of sorts.

> Our scenario goes similar to this I think:
>
> * Client may (or may not) connect, depending on the integration
> scenario. The main service thread should tolerate either, with
> plausibly the socket connection/session operating in another thread
> "asynchronously".
>
> * When client connects, the session logic is pretty straightforward:
> read if/when there is something to read, and pass it through a message
> framing unwrapper. Completed message gets deserialized and published
> into a thread-safe queue.
>
> * Events may be generated from the main service thread and
> subsequently published to the client: effectively a write operation,
> after passing a serialized message through a message framing wrapper.
>
> Doable? Feasible, possibly with some sort of a
> ping-ponging-back-and-forth type of session handling callback
> mechanism? I am cautiously optimistic that this has more to do with
> connection/session callback/state-machine type things, than it does
> Asio?
>
> Regards,
>
> Michael