On Tue, Jun 27, 2017 at 1:30 PM, Artyom Beilis via Boost <boost@lists.boost.org> wrote:

It was pointed that ripple uses beast. What it used for? What is implemented using Beast?

Ripple implements an HTTP and WebSocket service which uses a JSON interface to interact with the Ripple network (a decentralized ledger with a built-in cryptocurrency). [1]

If it is barely HTTP headers parser what do I need it for?

Parsing HTTP messages is just one great feature of Beast. Other great features include: * An HTTP message model * Read HTTP message to stream synchronously * Read HTTP message to stream asynchronously * Write HTTP message to stream synchronously * Write HTTP message to stream asynchronously * Built-in chunked encoding codec * Obtain a serialized buffer representation of an HTTP message * Produce an HTTP message from serialized buffers * A full WebSocket implementation * Classes for implementing composed operations * Adapters for working with buffer sequences * Metafunctions to determine if a type meets a concept * New models of DynamicBuffer * static_string Some users have a need to create an HTTP message and send it, or to receive an HTTP message and process it. Sometimes it is in the context of a web server or general HTTP client but not always. Often they want to use WebSocket. A programmer who just wants to send and receive an HTTP message from within their code has to do what exactly? Link with the CppCMS framework? Include a copy of cUrl in their app? They can use Beast for that. And they *are* using Beast for that, the library is steadily growing in users and popularity. In particular, Beast's message model is quite robust with lots of customization points. Its been designed to avoid the flaws exhibited in other libraries [2]

Looking over examples I noticed that the library user needs to manage all timeouts/keep alive connections. Am I right?

Yes, and this is also stated in the documentation. With a big red WARNING sign [3]

Why should I choose to write something over beast when there quite a lot of good solutions providing much more (higher level interface)

That's a great question. There are quite a few Beast users now, the GitHub issues have been lively and I have received many emails of thanks (and even more emails asking for help!). Apparently some people are finding Beast quite useful. If you think that there are other solutions which are better suited for your purpose, I am not surprised, Beast was not written to solve all problems. Just to handle the cases for which it was written. One area where Beast has a likely advantage, is that it is more suited for standardization (inclusion in the C++ standard library) than any other library. For exactly the reason underlying your questions - it doesn't try to do too much. But what it does do, it does correctly. More specifically I am making this claim: * Beast demonstrates what a standardized, low-level implementation of HTTP should look like To put it bluntly, any program which is not sending and receiving HTTP messages in a fashion similar to Beast (and eventually, using Beast explicitly) is likely doing it wrong, to the same extent that someone who insists on implementing their own version of common objects found in the standard library are doing it wrong (granted there are some special cases).

I'm not telling this to discourage you I'm telling it because Beast looks to me more like a tiny layer above socket or an assembly language for HTTP handling.

Yes! Here comes the shocker...quite a few people prefer Beast over other libraries judging from the activity in the repository and feedback I've received. Because it doesn't impose odd choices on its users. Its exactly what you said, a thin protocol layering on top of Asio. Beast implements just enough of the HTTP protocol to get messages in and out and leaves the "odd choices" up to users. I think that's how it should be for a low level library. And I think that C++ and Boost in particular, needs this low level component.

And I'm not talking about basic higher level stuff like forms CSRF, security sessions etc.

I mean HTTP itself was tiny part of the problem, the hard problems that may interest the library/framework develop are out of Beast scope.

Well, I don't know that I agree with that. One of Beast's most important features is how closely it tracks Asio interfaces and best practices. I have gotten feedback from users that this is one of the greatest strengths. Of course, if someone is allergic to Asio then they will similarly be allergic to Beast. To say that HTTP itself was a "tiny part of the problem" is I think to disregard the enormous effort and problem solving that went into getting Beast to where it is. Even if I were to agree and say it was a tiny part of the problem, it is a part that has not been satisfied to a thorough degree and of a quality sufficient to have a chance at Boost acceptance or C++ standardization. ...and it has WebSockets :) Thanks [1] https://github.com/ripple/rippled/tree/7b0d48281049c3fec7fafcb7ce5cea045367a... [2] http://vinniefalco.github.io/beast/beast/design_choices/http_comparison_to_o... [2] http://vinniefalco.github.io/beast/beast/using_networking/asio_refresher.htm...

On 25/06/2017 22:48, Vinnie Falco via Boost wrote:

On Sun, Jun 25, 2017 at 2:36 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:

...

Where you need to consume or produce arbitrary scatter-gather buffers, use gsl::span<T> or equivalent.

As gsl::span<> is only capable of representing ranges of elements contiguous in memory, it is not capable of representing the majority of Beast's buffer sequences. Examples:

Think gsl::span<gsl::span<char>>. Actually AFIO v2 uses gsl::span<std::pair<char *, size_t>>, but that's to avoid the bounds check per buffer that gsl may do. In your case that bounds check won't be as important, so gsl::span<gsl::span<char>> makes lots of sense. Not least for all the extra automated static analysis you get for free.

...

I certainly can see that char iterators are going to get used a lot

Beast never templates on the character type. All operations on structured data (for example HTTP headers) are performed on a single contiguous memory buffer of chars. This is done for performance reasons.

Hmm. I find that highly surprising. I'd have thought that as the HTTP data comes in - in chunks - your code would work with discontiguous storage. Are you memory copying instead? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 26/06/2017 00:54, Vinnie Falco via Boost wrote:

On Sun, Jun 25, 2017 at 4:42 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:

Rarely I find the need to quote myself, this is one such occasion:

...

Using gsl::span<> effectively type-erases the buffer sequence which is inefficient, since it must be copied to a vector equivalent in order to be used.

...

Think gsl::span<gsl::span<char>>.

gsl::span<gsl::span<char>> effectively requires the callers to set aside storage for an array of std::pair<void const*, std::size_t>. The Asio equivalent is std::vector<boost::asio::const_buffer> which as you can see is inefficient as std::vector is not cheap to copy.

Asio's ConstBufferSequence concept of course includes gsl::span<gsl::span<char>> and std::vector<boost::asio::const_buffer> as models but it also includes the types I provided which cannot be modeled using gsl::span without intermediate storage. If you feel this is an acceptable tradeoff for your library, I am quite happy for you but I'll stick with the use of templates and the ConstBufferSequence concept since that is what is on track for standardization.

AFIO v2 doesn't allocate memory except exactly once per async i/o initiated. So the scatter-gather buffer list is given to the OS immediately, and therefore no copies of that list are needed as the OS takes them. Most users I should imagine would therefore build scatter-gather lists on the stack as they'll be thrown away immediately, indeed I usually feed it curly braced initializer_lists personally, least typing. In BEAST's case, I can see that scatter-gather buffers may need to be kept for longer. Except ...

...

I'd have thought that as the HTTP comes in - in chunks - your code would work with discontiguous storage.

I thought that too and built quite a bit on top of a parser that worked in chunks, until I used a profiler and did some comparisons to other implementations...

...

Are you memory copying instead?

...when I discovered it is actually much, much faster to memcpy discontiguous buffers into a new, allocated buffer so that the parser can assume the entire structured portion is in a single "span" (to use the terminology you prefer). And of course if the caller already has the data in a single buffer then there's no need to memcpy. The class beast::flat_buffer is provided for that purpose.

... you're using memcpy to append incoming chunks of TCP data anyway, obviating the need for scatter-gather. Now I personally find it quite surprising that you found that memory copying is faster than a high quality discontinuous storage iterator implementation with ring buffered page aligned DMA friendly TCP i/o. Anyone who has ever claimed that to me before, when I examined their code I found they'd been using a naive RandomAccessIterator implementation which was doing two pointer indirections per access, which is obviously going to be not quick. What they should have done was implement BidirectionalIterator only, and had it cache when it next needs to do a lookup into the next discontiguous section, thus becoming very fast indeed because we're not trashing the CPU caches and not stalling the out of order execution. This is the kind of stuff you need if you want to get a single CPU core feeding a >= 10 Gbps NIC. The question then becomes is how expensive is losing random access on your parser implementation? Cloning these BidirectionalIterators is extremely quick (three pointers each), plus parsing HTTP tends to work in offsets anyway. Any XML parser I've ever written I keep a stack of where I am in the tag hierarchy as I run forwards - so I would reckon a ForwardIterator would actually be enough in practice. But I'll grant you that HTML is not XML, it's much harder to parse tag soup. So you may be right. Nevertheless I think you are going to have to back up your claim that memory copying all incoming data is faster rather than being bad implementation techniques with discontinuous storage, as surely I am not alone here in being surprised at such a claim. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

Most users I should imagine would therefore build scatter-gather lists on the stack as they'll be thrown away immediately, indeed I usually feed it curly braced initializer_lists personally,

Thus imposing limitation on the size of the buffer sequence.

The kernel imposes very significant limits on the size of the buffer list anyway: some OSs as low as 16 scatter-gather buffers per i/o, and as low as 1024 scatter-gather buffers in flight across the entire OS. So when you initiate an async i/o, you may get a resource temporarily unavailable error for even a single buffer, let alone two. On top of that, even if the OS accepts more, the DMA hardware has a fixed size buffer list capacity. 64 is not uncommon, and that's after the kernel has split your virtual memory scatter-gather list into physical memory plus added its own scatter-gather headers. So 32 buffers is a very realistic limit, and 16 is the portable maximum. (AFIO v2 doesn't involve itself whatsoever with any of this, it sends what you ask for to the OS, and reports back whatever errors the OS does)

...

I think you are going to have to back up your claim that memory copying all incoming data is faster rather than being bad implementation techniques with discontinuous storage

I'll let Kazuho back it up for me since I use his ideas: https://github.com/h2o/picohttpparser

Here's the slide show explaining the techniques: https://www.slideshare.net/kazuho/h2o-20141103pptx

And here is an example of the optimizations possible with linear buffers, which I plan to directly incorporate into Beast in the near future: https://github.com/h2o/picohttpparser/blob/2a16b2365ba30b13c218d15ed99915763...

Ah, I see you're referring to SIMD. I thought you were claiming that linear buffer based parsers were significantly faster than forward only iterator based parsers. You solve that problem by doing all i/o in multiples of the SIMD length, and memcpy any tail partial SIMD length at the end of a partial i/o into the next buffer. This avoids memory copying, yet keeps SIMD.

Of course if you think you can do better I would love to see your working parser that operates on multiple discontiguous high quality ring buffered page aligned DMA friendly storage iterators so that I might compare the performance. The good news is that you can do so while leveraging Beast's message model to produce objects that people using Beast already understand. Except that you'll be producing them much, much faster (which is a win-win for everyone).

You're the person bringing the library before review, not me. If you have a severe algorithmic flaw in your implementation, reviewers would be right to reject your library. They did so with me for AFIO v1, so it was on me to start AFIO again from scratch. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 26/06/2017 16:46, Vinnie Falco via Boost wrote:

On Mon, Jun 26, 2017 at 7:47 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:

...

If you have a severe algorithmic flaw in your implementation, reviewers would be right to reject your library.

If you are stating that Beast has a "severe algorithmic flaw" then please back up your claims with more than opinion.

I did not state that. I did indicate surprise at the choice to use memcpy over other available techniques.

However, note the following:

* At the time Boost.Http was reviewed it used the NodeJS parser which operates in chunks [1]. No "severe algorithmic flaw" came up then.

I think I was the only person to recommend acceptance in that review? I remember people had problems with the API design and intent. So people may not have bothered thinking about implementation too much if the API design was a fail.

* PicoHTTPParser, which Beast's parser is based on, outperforms NodeJS by over 600% [2]

If used as its author intended. I didn't get the impression the author expected to you memcpy its input.

* For parsers operating on discontiguous buffers, structured elements such as request-target, field names, and field values must be flattened (linearized) to be presented to the next layer which means temporary storage and buffer copying [3, 4].

Why? LLVM doesn't do this. So why should Beast?

So buffer copies cannot be avoided. Beast makes the decision to do one big buffer copy up front instead of many small buffer copies as it goes. The evidence shows this tradeoff is advantageous.

It may be relative to the other things you've tested against. But it may not be correct. For example, another zero copy DMA friendly trick is to do all socket i/o via a file so the kernel can DMA directly to/from the kernel file cache. From your perspective, you simply need to map a view onto that kernel file cache into your process, and indeed you can get your contiguous span of chars this way without using memcpy by doing a rolling mmap() of the span you need to see. However, there are costs to that approach. TLB shootdown can be a real problem, though less than some often think. Your TCP window size needs to be big and your NIC not a toy NIC for it to be worthwhile. Most consumer PCs are fitted with toy NICs, so any benchmarking done on those won't be realistic. You also need to bypass ASIO and go direct, because ASIO's async scatter-gather buffer implementation is crap (https://github.com/chriskohlhoff/asio/issues/203). Now it may be that reviewers feel that the memory copy is not significant relative to the rest of Beast. I may feel this way too after I've studied the code, and for example I'd likely accept memcpy of the HTTP request and response headers but not accept memcpy of the message body. We'll see when the review begins. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Mon, Jun 26, 2017 at 9:15 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:

...

Why? ... LLVM doesn't do this. So why should Beast?

Answered already [2]

Apologies, footnote 2 link was incorrect, this is the proper link: [2] http://boost.2283326.n4.nabble.com/Beast-Questions-Before-Review-td4696141.h...

בתאריך 30 ביוני 2017 9:57 אחה״צ,‏ "Robert via Boost" <boost@lists.boost.org> כתב: On 6/25/2017 5:02 PM, Robert Ramey via Boost wrote:

On 6/25/17 2:02 PM, Artyom Beilis via Boost wrote:

...

Hello Vinnie Falco,

I have several design questions regarding this library before the review.

Header Only Design ---------------------------

As somebody who worked with guys who do web development, it was very clear that compilation time is an issue.

A simple build of http_server_small.cpp example requires about 6s(!) of compilation time g++ 5.4 http_server_fast.cpp takes 7s

In comparison entire message board containing templates code flow SQL and more leads to only 4s - non paralel build. (https://github.com/artyom-beilis/cppcms/tree/master/example s/message_board )

I'm certainly missing something here. Why is compile time of 4-7 seconds any kind of issue? When would a web developer compile the library. Please expand on this as I'm not getting it all.

Robert Ramey

I too am missing something regarding compilation time. A C# asp.net web site takes roughly five seconds to, "Build." Then launching it within Visual Studio adds more time, coming up to around one minute and sometimes more, until the browser completes rendering the page. Robert You aren't compared to asp.net but to php/python/rails/nodejs that are the trendiest web development tools today. Even big projects start quite quickly with java / servlet And as a reference one of the simple examples provided compiles for about 30s ! If you multiply this by complexity of normal project the times become intolerable. Considering that beast does 1/100 of what others tools provide (even if in cool asio way) the price becomes too high. All it needed is to do classic OOD instead and you'll get much wider audience. With much better error reporting by the compiler, smaller code, and easier development, consider streight forward support of HTTP / https out of the box in some code. Doing temple based solution asio style for HTTP library IMHO is a design error. Artyom