Reusable HTTP(S) Connections Something I am often asked by users of Boost Beast is how to code a client which effectively re-uses a pool of HTTP connections, in the same way a web browser does. The premise is straightforward - if our client is going to be making multiple calls to a web server (or several of them) then it makes sense that once a connection has been used for one request, it is returned to a connection pool so that a subsequent request can make use of it. It also makes sens...

A Coroutine Websocket Using Boost Beast This month I thought I would present a little idea that I had a few months ago. Boost.Beast is a very comprehensive and competent websocket implementation, but it is not what you might call “straightforward” to use unless you are already wise in the ways of Asio. Beast’s documentation and design makes no apology for this. There is a disclaimer in the documentation: To use Beast effectively, a prior understanding of Networking is required. This ...

Asio Coroutines in Qt applications! I started this train of thought when I wanted to hook up some back-end style code that I had written to a gui front end. One way to do this would be to have a web front end subscribing to a back-end service, but I am no expert in modern web technologies so rather than spend time learning something that wasn’t C++ I decided to reach for the popular-but-so-far-unused-by-me C++ GUI framework, Qt. The challenge was how to hook up Qt, which is an event drive...

Cancellation in Beast/Asio and Better Compile Performance with Beast.Websocket This month I will be discussing two issues. One of interest to many people who come to us with questions on the Github Issue Tracker and the #beast channel of Cpplang Slack. Compile Times and Separation of Concerns A common complaint about Boost.Beast is that compilation units that use the websocket::stream template class often take a long time to compile, and that because websocket::stream is a template, this...

Reviewing the review The review period for Boost.JSON has come and gone, and we got some great feedback on the design of the library. Glancing over the results, it appears that the general mood was to accept the library. This doesn’t mean that there weren’t any problem areas – most notably the documentation, which often did contain the information people wanted, but it was difficult to find. Other points of contention were the use of a push parser as opposed to a pull parser, the use of dou...