mirror of
https://github.com/XRPLF/rippled.git
synced 2025-11-20 02:55:50 +00:00
59 lines
2.2 KiB
Plaintext
59 lines
2.2 KiB
Plaintext
[/
|
|
Copyright (c) 2013-2017 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)
|
|
]
|
|
|
|
[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 Networking TS
|
|
(__N4588__), 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.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.
|
|
|
|
[include 9_1_http_message.qbk]
|
|
[include 9_2_http_comparison.qbk]
|
|
[include 9_3_websocket_zaphoyd.qbk]
|
|
[include 9_4_faq.qbk]
|
|
|
|
[endsect]
|