Boost logo

Boost Users :

Subject: Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
From: Olivier Tristan (o.tristan_at_[hidden])
Date: 2019-03-14 17:03:32

Hi Vinnie,

I have followed your stuff since you were on the Juce Forum (audio
plugin developer here)

and I was wondering if you ever took a look at

It's a network library that use coroutine and boost asio

I was quite impressed when I saw a demo of it at a French c++ user Group.

just my 2 cents.

Le 14/03/2019 à 17:48, Vinnie Falco via Boost-users a écrit :
> Fellow C++, Boost, and WG21 Enthusiasts, lend me your ear!
> I write to inform you about exciting developments in C++ networking.
> First, a bit of background. Networking comes in three flavors:
> * Networking TS <>
> * Boost.Asio <>
> * Standalone Asio <>
> These three are for the most part identical, except that Asio flavors
> have additional features like ssl::stream and signal_set which are not
> in the TS, but will very likely appear in a future update or version.
> We've had Asio for over a decade now, but there is a shortage of
> experts. Some people believe this shortage is because Asio in
> particular (and thus, Networking TS since they have identical
> interfaces) is "difficult to use." I believe it is wrong to blame Asio
> for this. Concurrent programs in general are hard to write. This is
> applicable:
> "Unfortunately, today's reality is that only thoughtful experts can
> write explicitly concurrent programs that are correct and efficient.
> This is because today's programming models for concurrency are subtle,
> intricate, and fraught with pitfalls that easily (and frequently)
> result in unforeseen races (i.e., program corruption) deadlocks (i.e.,
> program lockup) and performance cliffs (e.g., priority inversion,
> convoying, and sometimes complete loss of parallelism and/or even
> worse performance than a single-threaded program). And even when a
> correct and efficient concurrent program is written, it takes great
> care to maintain — it's usually brittle and difficult to maintain
> correctly because current programming models set a very high bar of
> expertise required to reason reliably about the operation of
> concurrent programs, so that apparently innocuous changes to a working
> concurrent program can (and commonly do, in practice) render it
> entirely or intermittently nonworking in unintended and unexpected
> ways. Because getting it right and keeping it right is so difficult,
> at many major software companies there is a veritable priesthood of
> gurus who write and maintain the core concurrent code."
> - Herb Sutter, "The Trouble with Locks",
> <>
> Although this was written in 2005 it is still relevant today. It is
> understandable that Asio will be the first target of anger and
> frustration when writing concurrent programs, since it is on the
> "front line" so to speak. There has also been a distinct shortage of
> *good* tutorials and examples for Asio. Articles or blog posts which
> teach you step by step, explaining everything, and giving example code
> which demonstrates best practices.
> Boost.Beast is my low-level HTTP/WebSocket library which builds on Boost.Asio:
> <>
> In the original release of Beast, the documentation stated "prior
> understanding of Boost.Asio is required." However, field experience
> has shown that users ignore that requirement and attempt to write
> complex, concurrent programs as their first-time introduction to both
> Beast and Asio. Based on feedback from committee members, and to serve
> users better, the scope of Beast has been enlarged to include
> first-time users of networking. The upcoming Boost 1.70 release
> reflects this new scope and I am excited to announce some very nice
> things which you can access today.
> First of all, Beast documentation and examples no longer use the
> "boost::asio" namespace, they the namespace alias "net::". While this
> is cosmetic, it reinforces the notion when inspecting code that it is
> equally applicable to Boost.Asio, Asio, and Networking TS (identifiers
> which are not in the TS, such as signal_set, are still qualified with
> boost::asio).
> A new documentation page explains the three flavors of networking:
> <>
> This is also explained in my 2018 CppCon presentation:
> <>
> I have added a "Networking Refresher", a complete overview of
> networking from soup to nuts. No prior knowledge or understanding of
> networking is required, everything is explained in detail so if you
> want to learn this is the place to start. I also kept it short, but it
> is loaded with hyperlinks for further learning:
> <>
> There was a recent paper in Kona, P1269R0 ("Three Years with the
> Networking TS") about difficulty of implementing timeouts. To address
> this, Beast now has a stream class which implements configurable
> timeouts for you, and callers no longer have to fiddle with timers
> manually anymore. Everything "Just Works." It achieves the P1269R0
> author's goal of having timeouts "built-in to asynchronous
> operations", but in a way that fits in with the design of the TS:
> <>
> I feel that this `beast::basic_stream` serves as an existence proof
> that the current design of Networking TS is sound - the TS offers a
> flexible toolbox which lets you build your own framework the way that
> you want it, without making odd choices for you. We are still
> discovering ways of leveraging it to maximum use. The
> beast::websocket::stream also has built-in timeouts, but they are
> enhanced to support "idle pings" (keeping client connections alive)
> and everything is fully configurable:
> <>
> All you need to do to get sensible, suggested websocket timeouts is
> add one line of code after creating your stream:
> ws.set_option(websocket::stream_base::timeout::suggested(
> beast::role_type::server));
> To address the cumbersome boilerplate of writing composed operations
> (specifically the need to propagate the associated allocator and
> associated executor, and to avoid invoking the completion handler from
> within the initiating function when the operation would complete
> immediately) Beast adds two new utility base classes, with plentiful
> documentation and examples throughout:
> <>
> There are two well-rounded examples which show you step by step how to
> write these things in a safe way:
> <>
> <>
> I have a big, new open source project which implements a server, that
> uses the `system_context`, taking full advantage of native Windows and
> Mac OS system-level execution context features. To support this use
> case and industry feedback, the examples in Beast now default to being
> always thread-safe. All examples use a "strand", and leverage P1322R0
> ("Networking TS enhancement to enable custom I/O executors"). Yes,
> this paper which was approved in Kona, is now implemented in both
> Boost.Beast, and Boost.Asio, including all of the Beast examples, so
> if you pick up Boost 1.70 (or the master branches from github) you can
> start playing with this as soon as you're done reading this message!!
> <>
> We have an active #beast channel in the C++ Slack
> ( where experienced users can help, no question
> is too small! I hope you will join me and the rest of the Beast and
> Asio community in exploring what the very powerful Networking TS and
> Asio libraries have to offer, and build something great together!
> Regards
> P.S. Don't forget to star the repository! <>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]

Olivier Tristan
Research & Development

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at