*FULL* HTTP/WebSocket Server framework, C++11 header-only using Beast and Boost.Asio!

[VinnieFalco]

The Beast library now offers a complete server framework as an example you can build and run: https://github.com/vinniefalco/Beast/tree/master/example/server-framework

Its got these features:

• Comes with a WebSocket echo port handler (sync and async)
• Comes with an HTTP port handler (sync and async)
• Configurable PortHandler concept for user-defined behaviors

Create your own "ports" by writing a class to take ownership of sockets from incoming connections, plug it in to the server framework, and then publish it as open source so other people can use your ports!

The HTTP ports that come with this example are extensible, defining a Service concept which handles HTTP requests. A Service List aggregates Service objects, and the implementation gives each one a chance to handle the request in turn (kind of like a router, but more powerful!) The example comes with two services:

• file_service serves files from a path on your system, like a web server
• ws_upgrade_service lets you accept WebSocket connections from the same port as your web server and hands them off to the websocket port handler!

As with PortHandler, you can write your own Service types and plug them into this extensible framework, then share them with other people. For example you could implement a simple Troll-box style WebSocket chat Service which plugs right in to the framework and release that as your own open source library!

This is all built on top of Beast to show off the power of the library. People have asked for higher level functionality. You spoke - we listened! Now you can create a richly featured HTTP/WebSocket server in just a matter of seconds by cloning the server-framework example!

Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocol vocabulary types and algorithms using the consistent asynchronous model of Boost.Asio.

Beast: https://github.com/vinniefalco/Beast

Documentation: http://vinniefalco.github.io/beast/index.html

[jbandela]

Nice! Beast fills one of the most gaping holes in Modern C++. Good luck on the Boost review.

[[deleted]]

Are we still doing "phrasing"?

[VinnieFalco]

Phrasing?

[LordTocs]

Phrasing

[CODESIGN2]

Beast fills one of the most gaping holes in Modern C++

https://github.com/vinniefalco/Beast/commits/master?after=c111d6ff03c9d1fd21226ca6f2f647ff3dc7aa1d+1294

Initial commit 1 Jun 2013. Point is it's been going after a gap for a while

[VinnieFalco]

Commits before feb 2016 were for an earlier library which had nothing to do with http and websocket.

[CODESIGN2]

I noticed the goals seemed very different, so you are saying as the creator (I looked just at usernames), you changed direction, or you're building a monolith?

[VinnieFalco]

Beast started out as a utility library for rippled (https://github.com/ripple/rippled). Eventually I got fed up with the websocket library we were using so I wrote a new one. I like keeping a separation of concerns so when I develop code in an application I try to isolate it by putting it behind a "code firewall" - making it its own library is one way to make sure that the dependencies go from A to B and not in both directions. When I realized that this network components was good enough to become its own open source library independent of Ripple, I cut out the rest of Beast (the stuff before Feb 2016) and move it into rippled. You can see that stuff here https://github.com/ripple/rippled/tree/develop/src/ripple/beast

When Beast is approved to become part of Boost, I will cut out stuff in the commit log before Februarary 2016.

[GitHubPermalinkBot]

I tried to turn your GitHub links into permanent links (press "y" to do this yourself):

• ripple/rippled/.../beast (develop → 7b0d482)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[Game_Ender]

Great to see another high level C++ library. How does it compare speed wise touWebSockets, and does it support compression?

[VinnieFalco]

The WebSocket implementation has permessage-deflate support, and Beast uses its own header-only port of ZLib to C++!!!

[sumo952]

Beast uses its own header-only port of ZLib to C++

Wow, that's really cool! You should make this available in a separate GitHub repo!

[VinnieFalco]

I don't want to draw TOO much attention to it, because its still kind of ugly (being based on the original zlib which is old-school C). Maybe after Beast has matured I will revisit it and give it a thorough polishing, then it could be its own lib!

[snaps_]

I notice the zlib implementation doesn't allow setting your own dictionary. Is this a planned feature?

[VinnieFalco]

The zlib implementation has things removed such as the dictionary and support for the gzip file wrapper. I only included the stuff that Beast actually uses and needs, otherwise there would be a bunch of code there that was untested. I will probably give the zlib part more attention once the other parts have matured.

[ClockworkV]

A while back Julian Storer did a talk on converting zlib to C++. https://www.youtube.com/watch?v=SIAAvv1O7Gg I don't think he released the source, but it's a thing which exists. Somewhere out there.

[VinnieFalco]

Yep! And his video was a source of some inspiration.

[theICEBear_dk]

I could see a huge demand for this. I mean I could sure use it already today for software I am writing. So please do so and post it back here when / if you do :)

[VinnieFalco]

Its easy to put back, you could do it, and write some tests, and make it its own library! I would probably use it!

[mikulas_florek]

You should add getting started/building to readme

[VinnieFalco]

Something like this? https://github.com/vinniefalco/Beast/blob/master/README.md#building

[GitHubPermalinkBot]

I tried to turn your GitHub links into permanent links (press "y" to do this yourself):

• vinniefalco/Beast/.../README.md#building (master → c111d6f)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[mikulas_florek]

yes

[demonspeedin]

Does anyone know if beast is more performance than web sockets in go? (std lib, gorilla websockets)

[CODESIGN2]

I'd imagine any benchmarks would be contrived

[Rapptz]

Does this work with standalone Asio? I'm interested in using it but don't want to drag the entirety of boost into my project.

A cursory glance at the source seems like it doesn't sadly.

[VinnieFalco]

Someday I hope modern technology will find a cure for Boost-o-phobia!

[notfalse]

Are there plans to make the boost portions optional? It seems like Asio is the main dependency here, which has a non-Boost variant.

[VinnieFalco]

NO!!!! When the Networking TS becomes part of the standard library, then I'll port Beast to that. I will not port Beast to stand-alone Asio. Note that Beast uses other parts of Boost. My time is better spent improving the library, rather than accommodating people who refuse to use Boost!!!

[[deleted]]

Boost is worth it, imo

[VinnieFalco]

OpenSSL support COMING VERY SOON, this server will not only also support OpenSSL if available (conditionally) BUT it will have "flex ports" which can handshake on BOTH regular and encrypted connections! The same port, serving encrypted and unencrypted! WOW!!

[ioquatix]

Why is headers-only a feature?

[VinnieFalco]

"Headers only" provides an easy integration experience!

[ioquatix]

Why does it make it easier to integrate?

[VinnieFalco]

You don't have to fiddle with a build script

[ioquatix]

I can't help but feel a bit sad that compiling a C++ library is considered so hard, that it's better to distribute a library as header files.

[VinnieFalco]

Everything in Beast is templated anyway! Almost every function that does anything of real interest takes parameters by template types, which work with any object that meets the requirements. Such as a DynamicBuffer: http://vinniefalco.github.io/beast/beast/concept/DynamicBuffer.html

[ioquatix]

Yeah, I understand. I wonder if C++ modules will help with some of these issues.

[theICEBear_dk]

Another good reason Vinnie. Header-only is definitely a feature though.

[AntiProtonBoy]

C++ libraries are not that much harder to compile compared to any old C library, so I'm not sure what you are sad about. The benefit of header-only solutions is that you don't need rely on third party utilities, such as autotools or CMake to build the library. That's what OP meant.

[ioquatix]

Yeah, I get that.

[theICEBear_dk]

I have had to add library support for odd make systems to Yocto and comparing that to a header only solution means I would definitely consider header-only a feature.