On Tue, Jun 25, 2013 at 10:00 AM, Marat Abrarov
If the timer handler is called first, then you're done: initiate disconnection, etc. If the read handler is called first, you simply reset the timer (maybe cancel and then reset). I honestly don't know if you have to worry about a race condition (timer going off while handler for async_read is executing), or if a cancel / reschedule out of the async_read handler would preempt any other handlers. You might end up having to stick both the async_read and deadline_timer in the same strand; that would prohibit concurrent execution.
There is a good example: http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/example/timeouts/se...
Hmm, reading through this one, I'm not sure we want to disconnect the socket before the service is through, unless there's a good reason, like an error code occurred; i.e. network error, client disconnected, and so on. Read will likely be idle throughout, but can occasionally receive messages. More likely we will be sending messages. Will study this one bit closer I think. I expect to host an io_service in a thread runner with mutex-protected deque of events that publish to subscribers. As has been suggested, I expect to handle the concern of: whether connected. That's one use case of this service, it can run "serverless" if needs be for diagnostic purposes. The real discipline for me is in separating the concerns: server from connection (and/or session), session from worker thread, and so on. Making sure the strands all go when I expect them to is the challenge. Session will expose a Boost.Signals2 hook that requests a next write from the hosting worker thread for the write part. Write, message content, framing, and so on, is straightforward enough. The read part is *I think* is "simple" enough, deadline-timered, read a some as long as there is something available and pass that through an framing unwrapper. If I understand the Asio model, it's all about keeping the io_service busy doing something. Maybe asynchronously waiting for the next thing, but in any event, keep running the next part (the state machine aspect).
and a good article: http://blog.think-async.com/2010/04/timeouts-by-analogy.html
and a rather heavy example: http://sourceforge.net/projects/asio-samples/ (see project named echo_server).
In general, you will need a state machine (or even few of them).
I am familiar with this concept. We've done something right along these lines for message framing. Out-bound (write/send) is simple. In-coming (read/receive), not so much: state machine. Seems like the more layers I peel back grasping this Asio animal, there's one more. However, I am growing up in it, so to speak, it's easier to comprehend.
Regards, Marat Abrarov.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users