boost.asio-Advanced TopicsThis chapter elaborates on some advanced topics in Boost.asio. It's not possible to study these problems in daily programming, but it's certainly good to know that:
- If debugging fails, you need to see what Boost.asio can do for you.
- If you need to deal with SSL, see how much Boost.asio can help you
- If you specify an operating system, see what additional features Boost.asio has prepared for you
Asio VS Boost.asioThe author of Boost.asio also kept the ASIO. You can think in a Asio way, as it is in both cases: Asio (non-boost) and Boost.asio. The author declares that the update will appear in non-boost first, then after a period of time, then add to the boost release. the different points are summed up in the following several ways:
- ASIO is defined in the ASIO:: namespace, and Boost.asio is defined in Boost::asio::
- ASIO's main header file is ASIO.HPP, and Boost.asio's header file is BOOST/ASIO.HPP
- ASIO also has a class that initiates threads (as with Boost::thread)
- ASIO provides its own error code class (Asio::error_code instead of Boost::system::error_code, then asio:system_error instead of Boost::systrem::system_error)
you can read more ASIO information here: http://think_async.comyou need to decide the version you choose, I choose Boost.asio. Here are some questions to consider when you make a choice:
- The new version of ASIO is released earlier than the new version of Boost.asio (because the boost version is less updated)
- ASIO only the header file (while the Boost.asio part relies on other boost libraries, these libraries may need to be compiled)
- ASIO and Boost.asio are very mature, so unless you really need some ASIO new features, Boost.asio is a very safe option, and you can also have other Boost library resources
Although I do not recommend this, you can use both Asio and Boost.asio in one application. This naturally happens if circumstances permit, for example, if you use Asio, then some third-party libraries are Boost.asio, and vice versa.
Debugdebugging synchronous applications is often easier than debugging asynchronous applications. For a sync app, if it's blocked, you'll jump into debugging, and you'll know where you are (sync means ordered). Then, if it's asynchronous, the event doesn't happen in order, so it's hard to know what's going on in debugging. to avoid this, first of all, you need to get a deeper understanding of the process. If implemented correctly, you will not encounter a bit of an asynchronous debugging problem. just in case, when you do asynchronous coding, Boost.asio pulls you down; Boost.asio allows "HANDLER tracking", when boost_asio_enable_handler_tracking is defined, Boost.asio will write a lot of auxiliary output to the standard error stream, record time, asynchronous operation, and finish processing the handler relationship.
Handler tracking Informationinformation is not so easy to read, but it is very useful. The output of the Boost.asio is @asio|<timestamp>|<action>|<description>. The first tag will always be @asio, because the other code will be output to the standard error stream (and std::error equivalent), so you can easily use this tag to filter the information printed from Boost.asio. The number of seconds and milliseconds that the timestamp instance has been from January 1, 1970 to the present. An action instance can be any of the following:
- >n: This is used when we enter handler N. Description strength contains the parameters we send to handler.
- <n: This is used when we exit handler N.
- !n: This is used when we exit handler N because of an exception.
- -N: This is used when handler n exits without a call, possibly because the Io_service instance is deleted too quickly (before N is called)
- N*m: This is called when Handler N creates a new asynchronous operation that has finished processing hanlder m. The description instance shows where the asynchronous operation began. When you see >m (Start) and <m (end), the completion handle is called.
- N: As shown in description, this is used when handler n does an operation (possibly close or cancel). You can generally ignore this information.
- When n is 0 o'clock, the operation is performed outside of all (asynchronous) handler; You often see this in the first operation, or when you use one of the semaphores to be triggered.
- You need to be very careful about the type!n and-n information, most of which means your code is wrong. In the first case, the Async method does not throw an exception, so the exception must be self-inflicted; you can't let the exception run out of your completion handle. In the second case, you may have destroyed the Io_service instance too early, before all the completed processing sentences have been called.
An exampleIn order to show you an example with help information, we have modified the example used in chapter sixth Boost.asio other features. All you need to do is add a # define before you include BOOST/ASIO.HPP
#define Boost_asio_enable_handler_tracking #include <boost/asio.hpp> ...
At the same time, we also output the information to the console when the user logs on and receives the first client list. The output is as follows:
@asio |1355603116.602867|0*1| [Email protected]_connect @asio |1355603116.604867|>1|ec=system:0 @asio |1355603116.604867|1*2|[ Email protected]_send @asio |1355603116.604867|<1| @asio |1355603116.604867|>2|ec=system:0,bytes_transferred=11 @asio |1355603116.604867|2*3|[ Email protected]_receive @asio |1355603116.604867|<2| @asio |1355603116.605867|>3|ec=system:0,bytes_transferred=9 @asio |1355603116.605867|3*4|[ Email protected] @asio |1355603116.605867|<3|
@asio |1355603116.605867|>4| John logged in @asio |1355603116.606867|4*5|[ Email protected] @asio |1355603116.606867|<4| @asio |1355603116.606867|>5| @asio |1355603116.606867|5*6| [Email protected]_send @asio |1355603116.606867|<5| @asio |1355603116.606867|>6|ec=system:0,bytes_transferred=12 @asio |1355603116.606867|6*7|[ Email protected]_receive @asio |1355603116.606867|<6| @asio |1355603116.606867|>7|ec=system:0,bytes_transferred=14 @asio |1355603116.606867|7*8|[email Protected] @asio |1355603116.607867|<7| @asio |1355603116.607867|>8| John, new client List:john
let's analyze it one line at a line:we enter Async_connect, which creates a handle of 1 (in this case, all the handles are talk_to_svr::step)
- Handle 1 is called (when successfully connecting to the server)
- Handle 1 calls Async_send, which creates a handle 2 (here, we send login information to the server)
- Handle 1 exit
- Handle 2 is called and 11 bytes are sent out (login John)
- Handle 2 calls Async_receive, which creates a handle of 3 (we wait for the server to return the result of the login)
- Handle 2 exit
- Handle 3 is called and we receive 9 bytes (login OK)
- Handle 3 Calls On_answer_from_server (this creates a handle 4)
- Handle 3 exit
- Handle 4 is called, which outputs John logged in
- Handle 4 calls another step (handle 5), which writes ask_clients
- Handle 4 exit
- Handle 5 Enter
- Handle 5,async_send_ask_clients, creating handle 6
- Handle 5 exit
- Handle 6 calls Async_receive, which creates a handle of 7 (we wait for the server to send us a list of existing clients)
- Handle 6 exit
- Handle 7 is called and we accept the client list
- Handle 7 Calls On_answer_from_server (this creates a handle 8)
- Handle 7 exit
- Handle 8 in, then output the client list (on_clients)
it takes a while to understand, but once you understand it, you can identify the problematic output and find the code that needs to be repaired.
Boost.asio C + + Network programming translator (29)
