"Boost.Asio C ++ Network Programming". Chapter 7: Boost.Asio - additional topics

Hello!
I continue to translate the book of John Torjo "Boost.Asio C ++ Network Programming".

Content:

• Chapter 1: Getting Started with Boost.Asio
• Chapter 2: Boost.Asio Basics
  
  • Part 1: The Basics of Boost.Asio
  • Part 2: Asynchronous Programming
• Chapter 3: Echo Server / Client
• Chapter 4: Client and Server
• Chapter 5: Synchronous vs. Asynchronous
• Chapter 6: Boost.Asio - Other Features
• Chapter 7: Boost.Asio - additional topics

This chapter covers some additional Boost.Asio topics. It is unlikely that you will use it every day, but it will certainly not be out of place to know:

• If debugging fails, then you will see that Boost.Asio will help you with this.
• If you have to work with SSL, then look what Boost.Asio has to offer you.
• If you are writing an application for a certain OC, then look at what additional functions are in Boost.Asio for you

')

Asio vs Boost.Asio

Boost.Asio also provided support for Asio. You can think of it as Asio, since this library comes in two versions, Asio (not Boost) and Boost.Asio. The authors claim that updates will first appear in Asio, and will be added periodically to the Boost distribution.
In a nutshell, the differences are as follows:

• Asio is defined in the asio:: namespace, while Boost.Asio is defined in boost::asio::
• The header file in Asio is asio.hpp and boost/asio.hpp in Boost.Asio
• Asio has its own class for running threads (equivalent to boost::thread )
• Asio provides its classes for error codes ( asio::error_code instead of boost::system::error_cod and asio::system_error instead of boost::system::system_error )

You can get more information on Asio here .
You must decide for yourself which option you prefer; I personally prefer Boost.Asio. Here are a few things you should pay attention to when making your choice:

• New versions of Asio are released more often than new versions of Boost.Asio (new distributions of Boost are released quite rarely)
• Asio is purely header (while part of Boost.Asio depends on other Boost libraries that may be needed for compilation)
• Both Asio and Boost.Asio are quite advanced, so if you are not eager to use the functions from the new release of Asio, then Boost.Asio is a pretty good alternative, especially since you will have other Boost libraries at your disposal.

You can use Asio and Boost.Asio in the same application, although I do not recommend you do this. This may not work out intentionally, in this case everything will be fine, for example, if you use Asio, and some third-party libraries use Boost.Asio and vice versa.

Debugging

Debugging a synchronous application is usually simpler than an asynchronous application. For a synchronous application, if it is blocked, you will simply enter debugging and get a picture of where it happened (synchronous means consecutive). However, when you program asynchronously, events do not occur sequentially, so if an error occurs, it will be really difficult to catch it.
To avoid this, first, you must understand coroutines very well. If the program is implemented correctly, then you practically will have no problems at all.
Only when it comes to asynchronous programming, Boost.Asio will give you a helping hand; Boost.Asio allows you to track handlers if the BOOST_ASIO_ENABLE_HANDLER_TRACKING macro is BOOST_ASIO_ENABLE_HANDLER_TRACKING . If this is the case, then Boost.Asio contributes to the output of information to the standard error output stream, recording the time, asynchronous operation and, related to it, the final handler.

Handler tracking information

Information is not so easy to understand, but nevertheless it is very useful. The output of Boost.Asio gives the following:

 @asio|<timestamp>|<action>|<description>. 

The first tag is always @asio , you can use it to easily filter messages coming from Boost.Asio in case other sources write to the standard error stream (equivalent to std::cerr ). The timestamp instance is counted in seconds and microseconds, starting January 1, 1970 UTC. An action instance can be one of the following:

• >n : used when we enter handler number n. The description instance contains the arguments passed to the handler.
• <n : Used when handler number n is closed.
• !n : used when we left handler n due to an exception.
• ~n : used when handler number n is destroyed without a call; probably because the io_service instance is io_service destroyed too early (before n gets a chance to call out).
• n*m : used when handler n creates a new asynchronous operation with a trailing handler numbered m. After the start, the started asynchronous operation will be displayed in the description instance. The final handler will be called when you see >m(start) and <m(end) .
• n : used when handler number n performs an operation that is displayed on description (which can be a close or a cancel operation). Usually, you can safely ignore them.

Whenever n = 0, then all the handlers are executed from the outside (asynchronously), usually you see when the first operation (operations) is performed or if you work with signals and the signal is triggered.
You should pay attention to the messages like !n and ~n , which occur when there are errors in the code. In the first case, the asynchronous function did not throw an exception, so the exception must be generated by you; you should not allow exceptions when exiting your final handler. In the latter case, you probably destroyed the io_service instance too early, before all the called handlers were completed.

Example

In order to show you an example of supporting information, let me change the example from Chapter 6. All you need to do is add an additional #define before enabling boost/asio.hpp :

 #define BOOST_ASIO_ENABLE_HANDLER_TRACKING #include <boost/asio.hpp> ... 

We will also dump the console to the console when the user logs in and receives the first client list. The output will be as follows:

 @asio|1355603116.602867|0*1|socket@008D4EF8.async_connect @asio|1355603116.604867|>1|ec=system:0 @asio|1355603116.604867|1*2|socket@008D4EF8.async_send @asio|1355603116.604867|<1| @asio|1355603116.604867|>2|ec=system:0,bytes_transferred=11 @asio|1355603116.604867|2*3|socket@008D4EF8.async_receive @asio|1355603116.604867|<2| @asio|1355603116.605867|>3|ec=system:0,bytes_transferred=9 @asio|1355603116.605867|3*4|io_service@008D4BC8.post @asio|1355603116.605867|<3| @asio|1355603116.605867|>4| John logged in @asio|1355603116.606867|4*5|io_service@008D4BC8.post @asio|1355603116.606867|<4| @asio|1355603116.606867|>5| @asio|1355603116.606867|5*6|socket@008D4EF8.async_send @asio|1355603116.606867|<5| @asio|1355603116.606867|>6|ec=system:0,bytes_transferred=12 @asio|1355603116.606867|6*7|socket@008D4EF8.async_receive @asio|1355603116.606867|<6| @asio|1355603116.606867|>7|ec=system:0,bytes_transferred=14 @asio|1355603116.606867|7*8|io_service@008D4BC8.post @asio|1355603116.607867|<7| @asio|1355603116.607867|>8| John, new client list: John 

Let me analyze each line:

• We enter async_connect , which creates handler 1 (in our case, everyone processes talk_to_svr::step )
• Handler 1 is called (after successfully connecting to the server)
• Handler 1 calls async_send , which creates handler 2 (here we send a message with login to the server)
• Handler 1 is closing
• Handler 2 is called and sends 11 bytes ( login John )
• Handler 2 calls async_receive , which creates handler 3 (we are waiting for the server to respond to our login message)
• Handler 2 closes
• Handler 3 is called and gets 9 bytes ( login ok )
• Handler 3 redirects to on_answer_from_server (where handler 4 is created)
• Handler 3 closes
• Handler 4 is called, which is then John logged in to the dump John logged in
• Handler 4 starts another step (handler 5), which will write ask_clients
• Handler 4 closes
• Handler 5 opens
• Handler 5, async_send ask_clients , creates handler 6
• Handler 5 closes
• Handler 6 is ask_clients (we have successfully sent ask_clients server)
• Handler 6 calls async_receive , which creates handler 7 (we are waiting for the server to send us a list of existing clients)
• Handler 6 closes
• Handler 7 is called, and we accept a client list
• Handler 7 runs on_answer_from_serve (where handler 8 is created)
• Handler 7 closes
• Handler 8 is on_clients , and a list of clients is written to the dump ( on_clients )

It will take some time to get used to, but once you understand this, you can isolate the output that contains the problem and find the actual part of the code that needs to be fixed.

Writing handler tracking information to a file

By default, the tracking information for handlers is output to the standard error stream (equivalent to std::cerr ). It is very likely that you will want to redirect this output to another location. On the one hand, by default, for console applications, the output and reset of errors occurs in one place, that is, in the console. But for Windows (non-console) applications, the default error flow is empty.
You can redirect error output using the command line, for example:

 some_application 2>err.txt 

If you are not lazy, you can do it programmatically, as shown in the following code snippet:

 // for Windows HANDLE h = CreateFile("err.txt", GENERIC_WRITE, 0, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL , 0); SetStdHandle(STD_ERROR_HANDLE, h); // for Unix int err_file = open("err.txt", O_WRONLY); dup2(err_file, STDERR_FILENO); 

SSL

Boost.Asio provides classes for supporting some basic SSL features. Inside she uses OpenSSL . So if you want to use SSL, first download and build OpenSSL . It should be noted that, as a rule, building OpenSSL is no easy task, especially if you do not have popular compilers, such as Visual Studio.
If you have successfully compiled OpenSSL , then Boost.Asio has some add-on classes over it:

• ssl::stream : used instead of class ip::::socket
ssl::context : this is the context for starting a session
  ssl::rfc2818_verification : this class is an easy way to verify a certificate for a host name in accordance with RFC 2818 rules
  
  
  In the next few articles I want to offer translations of the first chapters of several books (three, maybe 4), which one you like more, I will continue to translate the first one.
  
  Thank you all, until we meet again!