acceptor_(io_service_)
acceptor_.bind
acceptor_.listen
acceptor_.async_accept
io_service_.run

You mixed here blocking and asyncronous calls (which is legitimate),

so, how 'pure' async_accept should looks than? (without mixing)

I'm sorry, I just missread your code - you don't mix anything there, you just set-up the acceptor and launch asynchronous accept.

at last I understood how io_service works.
till now I thought "why they are talking that I have to schedule async operation first than run io_service.
in server example there is async_accept and io_service.run() and server is accepting forever. So, run() must running forever. ". I did not caught that in async_accept handler there is once again async_accept. this trick don't let run() never end.

Exaclty. If you look at other asio examples you'll see the same pattern: async. operations are chained in the way that completion handler of a previous operation launches the next one. This pattern allows you to end the i/o in a very simple way: just break the above chain and the io_service.run() ends. Note also that if your handlers are made of some "connection" object (using shared_from_this, like in the examples) that encapsulates socket, then when the chain terminates, this object is automatically destroyed closing its socket.

However, such a simple design is not always possible. In more complicated cases you have to keep io_service running *always*, even when there's no i/o activity - until explicitly stopped. Refer to the following example to see how you can do this:

http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio/example/http/server2/io_service_pool.cpp

It seems that I understand now what does it mean : explicitly/implicitly run io_service, synchronous/*synchronous*

In a synchornous (blocking) design you cannot run io_service "message loop" (which would block itself), so blocking functions pump their io_service by themselvs, in their implementations.

> once again thanks for your efforts (in sharing asio knowledge) Igor

you're welcome :)