76 lines
2.7 KiB
Plaintext
76 lines
2.7 KiB
Plaintext
[/
|
|
Copyright (c) 2016-2019 Vinnie Falco (vinnie dot falco at gmail dot com)
|
|
|
|
Distributed under the Boost Software License, Version 1.0. (See accompanying
|
|
file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
|
|
|
Official repository: https://github.com/boostorg/beast
|
|
]
|
|
|
|
[section Design Choices]
|
|
|
|
The implementations were originally driven by business needs of cryptocurrency
|
|
server applications (e.g. [@https://github.com/ripple/rippled rippled]),
|
|
written in C++. These needs were not met by existing solutions so Beast
|
|
was written from scratch as a solution. Beast's design philosophy avoids
|
|
flaws exhibited by other libraries:
|
|
|
|
* Don't try to do too much.
|
|
|
|
* Don't sacrifice performance.
|
|
|
|
* Mimic __Asio__; familiarity breeds confidence.
|
|
|
|
* Role-symmetric interfaces; client and server the same (or close to it).
|
|
|
|
* Leave important decisions, such as allocating memory or
|
|
managing flow control, to the user.
|
|
|
|
Beast uses the __DynamicBuffer__ concept presented in the __NetTS__,
|
|
and relies heavily on the __ConstBufferSequence__ and
|
|
__MutableBufferSequence__ concepts for passing buffers to functions.
|
|
The authors have found the dynamic buffer and buffer sequence interfaces to
|
|
be optimal for interacting with Asio, and for other tasks such as incremental
|
|
parsing of data in buffers (for example, parsing websocket frames stored
|
|
in a [link beast.ref.boost__beast__static_buffer `static_buffer`]).
|
|
|
|
During the development of Beast the authors have studied other software
|
|
packages and in particular the comments left during the Boost Review process
|
|
of other packages offering similar functionality. In this section and the
|
|
FAQs that follow we attempt to answer those questions that are also applicable
|
|
to Beast.
|
|
|
|
For HTTP we model the message to maximize flexibility of implementation
|
|
strategies while allowing familiar verbs such as [*`read`] and [*`write`].
|
|
The HTTP interface is further driven by the needs of the WebSocket module,
|
|
as a WebSocket session requires a HTTP Upgrade handshake exchange at the
|
|
start. Other design goals:
|
|
|
|
* Keep it simple.
|
|
|
|
* Stay low level; don't invent a whole web server or client.
|
|
|
|
* Allow for customizations, if the user needs it.
|
|
|
|
The following video presentation was delivered at
|
|
[@https://cppcon.org/ CppCon]
|
|
in 2016. It provides a light introduction to some of the earliest
|
|
interfaces of Beast (which have since changed).
|
|
|
|
[/ "Introducing Beast..."]
|
|
[block'''
|
|
<mediaobject>
|
|
<videoobject>
|
|
<videodata fileref="https://www.youtube.com/embed/uJZgRcvPFwI?rel=0"
|
|
align="center" contentwidth="560" contentdepth="315"/>
|
|
</videoobject>
|
|
</mediaobject>
|
|
''']
|
|
|
|
[include 1_http_message.qbk]
|
|
[include 2_http_comparison.qbk]
|
|
[include 3_websocket_zaphoyd.qbk]
|
|
[include 4_faq.qbk]
|
|
|
|
[endsect]
|