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-25 14:54:17

On Tue, Jun 25, 2013 at 10:00 AM, Marat Abrarov <abrarov_at_[hidden]> wrote:
>> 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/server.cpp

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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users