On Mon, Jun 24, 2013 at 5:22 PM, Michael Powell
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_str...) 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