Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!

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

https://github.com/mefyl/elle

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 <https://cplusplus.github.io/networking-ts/draft.pdf>
> * Boost.Asio <https://www.boost.org/doc/libs/1_69_0/doc/html/boost_asio.html>
> * Standalone Asio <https://github.com/chriskohlhoff/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",
> <http://www.drdobbs.com/cpp/the-trouble-with-locks/184401930>
>
> 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:
> <https://github.com/boostorg/beast>
>
> 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:
>
> <https://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_io.html>
>
> This is also explained in my 2018 CppCon presentation:
>
> <https://youtu.be/7FQwAjELMek?t=444>
>
> 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:
>
> <https://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_io/asio_refresher.html>
>
> 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:
>
> <https://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_io/timeouts.html>
>
> 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:
>
> <https://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_websocket/timeouts.html>
>
> 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:
>
> <https://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_io/writing_composed_operations.html>
>
> There are two well-rounded examples which show you step by step how to
> write these things in a safe way:
>
> <https://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_io/writing_composed_operations/echo.html>
>
> <https://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_io/writing_composed_operations/detect_ssl.html>
>
> 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!!
>
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1322r0.html>
>
> We have an active #beast channel in the C++ Slack
> (https://slack.cpp.al) 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! <https://github.com/boostorg/beast>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users

-- 
Olivier Tristan
Research & Development
www.uvi.net